From Code Complete to Code Missing: Software Without Source

The evolution of software development has been a steady march away from raw machine mechanics toward human-readable abstractions. We moved from punch cards to assembly, from assembly to structured C, and from C to managed languages like Java and Python. Each step systematically sacrificed a layer of raw hardware control to satisfy a single, non-negotiable requirement: human readability — the ideal codified by Steve McConnell's Code Complete (1993), the canonical guide to writing software correctly and completely by human hand, to be read and maintained by other humans.

The Cargo-Cult Trap

When large language models and autonomous engineering agents entered the field, our immediate instinct was cargo-cult. We treated these probabilistic neural engines like hyper-fast human typists, assigning them to write standard file-based source code, submit pull requests, and patch repositories line-by-line.

Moving beyond the code triggers a cascade that propagates through the entire software development lifecycle. Every practice that was built on the assumption of human-readable source — review, testing, observability, security auditing — must be completely rebuilt on agentic primitives. There is likely no satisfying middle ground: a post-textual runtime with source-era engineering processes is not a hybrid.

But forcing agents to simulate human coding habits is probably doing a disservice to the outcome. A large-scale 2026 empirical study by Sawada et al., "To What Extent Does Agent-generated Code Require Maintenance?", revealed a devastating paradox: when agents write traditional code files, human developers are still forced to step in and handle 83% of the long-term maintenance commits. Moreover, as Li et al. show in an Environment-in-the-Loop study of LLM-based code migration, agents systematically miss environment-specific dependencies and configuration requirements — hidden architectural misalignments that quietly rot production stacks. So, maybe instead of being human-like, but better, a higher path is to consider a post-textual alternative.

The Post-Textual Provocation

If we take agentic development to its logical extreme, we must abandon text-based source files entirely. As argued in Cao's 2026 arXiv position paper, "Agentic Software: How AI Agents Are Restructuring the Software Paradigm," treating LLMs as text-bound file typists is an unscalable holding pattern. Software is shifting toward a model where language models treat code merely as a temporary, instrumental resource to be generated, executed, and discarded on the fly.

The behavioral shift is already visible in day-to-day practice. Kieran Klaassen, writing in Every in January 2026, described what happened when a 1,000-line, 27-file pull request landed in his queue: he stopped reading the code entirely and spent fifteen minutes interrogating AI agents about the change instead. "By the time I had asked my questions, I'd already hit merge."

What began as a shortcut hardened into a discipline — if the behavioral signals are clean, the code text is beside the point.

Peter Steinberger, creator of PSPDFKit, put it plainly when interviewed by The Pragmatic Engineer: "These days, I don't read much code anymore. I watch the stream and sometimes look at key parts, but I gotta be honest, most code I don't read." The pattern repeats across the industry: skimming diffs, then glancing at diffs, then abandoning the diff altogether in favor of asking what the code does. The code is still being written; almost nobody is reading it. If that is where practice has already arrived, the honest architectural response is not to demand more code review discipline — it is to stop producing human-readable code at all.

When the human is no longer in the loop quite as much, we could eventually be transitioning to a regime of post-textual software engineering — an era where human-readable source code is largely removed from the pipeline — indeed, bytecode or machine code can be produced. There are varied options for how — and whether — the model and harness interact with a subsequent compiler.

He-Who-Shall-Not-Be-Named

When source code is removed from the pipeline, something less obvious vanishes alongside it: the entire internal vocabulary of the system. In the source era, every entity inside a program had a human-assigned name — a function, a class, a module boundary, a stack frame. These names were not just documentation; they were the cognitive handles through which developers oriented themselves and exercised control. A post-textual runtime has none of them. The compiled binary has no parseHeaders(), no UserRepository, no line 247. From the outside, the internals are unnameable — present and executing, but beyond human address. Call this the epistemic gap: the runtime can be observed and probed at the boundary, but its internals cannot be pointed at, named, or reasoned about directly.

This is architecturally double-edged. The upside is real: because humans have no handle on the internals, the runtime can mutate its execution binary continuously — merging paths, rewriting memory layouts, re-optimizing across the whole program — without breaking any human-facing contract. The behavioral predicates the Intent Architect specifies remain stable even as the compiled structure underneath evolves. Opacity, in this context, is a feature.

The downside is hard to overstate. When a behavioral anomaly appears, is there a useful enough stack trace or a code path to show to a senior engineer? The forensic understanding that a senior engineer builds over years of reading production code has no equivalent here. It must be rebuilt entirely on agentic primitives: behavioral probes, invariant witnesses, causal reconstruction from telemetry streams. That rebuild is necessary, not optional — and it is where some of post-textual engineering's most difficult problems live.

01 The Opportunity: Reclaiming the Raw Hardware Tax

In a traditional engineering environment, up to 80% of a codebase's structural complexity exists solely to satisfy the cognitive limitations of the human brain. We enforce strict object-oriented boundaries, write verbose architectural boilerplate, implement clean API layers, and break programs into modular files so that a human engineer can hold the mental model of the system in their head.

Three Ways to Make Things Faster

Preserving these human-readable interfaces levies a crushing, continuous tax on runtime execution. Decades of systems optimization research quantify this exact burden across three compounding vectors:

• The Layered Abstraction Tax. Empirical performance modeling shows that while a single abstraction boundary may seem minor, overheads compound exponentially across stacked multi-tier applications, bloating overall instruction counts by 3% to 5% per layer. Deep modular boundaries break CPU hardware optimizations like branch prediction and speculative execution by introducing indirect jumps and dynamic virtual method tables. Compilers are forced to emit optimization blockades simply to keep code files cleanly separated for human reviewers.
• The Serialization Penalty. Object-Relational Mappers are built entirely to shield human eyes from raw database languages. Comparative benchmarks show that stripping away universal abstraction wrappers and replacing them with format-specific, bare-metal access routes can drop endpoint latency from 850ms to 120ms — an immediate 7× performance gain — while concurrently slashing database processor loads by 40%.
• The Dynamic Dispatch Overhead. Quantitative tracking at the compiler level shows that generic interface call wrappers introduce a 2× latency overhead compared directly to static dispatch execution pipelines. High-level language modules run at less than half the execution speed of flat implementations because the CPU must constantly pause its pipeline to dynamically resolve memory addresses. Bilokon & Gunduz's rigorous benchmarking of low-latency C++ design patterns confirms this: replacing virtual dispatch with constexpr static resolution is among the highest-impact single techniques available to a latency-sensitive system, delivering measurable improvements in both throughput and cache utilisation.

When code is generated, maintained, and verified purely within an autonomous machine-to-machine pipeline, the requirement for human readability vanishes. PerfCodeBench (Jing et al.) has demonstrated that when LLMs are asked to optimize code under traditional human constraints, their outputs consistently fall short of human-expert efficiency, particularly on tasks involving parallelism, dynamic execution, and lower-level GPU or memory bottleneck handling.

By completely breaking away from human code representation, an agentic compiler loop can execute absolute, cross-cutting whole-program optimizations. The compilation layer can fluidly merge components, flatten call stacks, eliminate dynamic interface tables, dissolve data serialization layers, and mutate memory layouts on the fly — without worrying about breaking a human developer's mental model.

The Hardware-Software Co-Design Unlock. There is a fourth vector that source-code constraints have historically made invisible: the software and hardware components of a system cannot co-evolve when the software must remain general-purpose enough for human engineers to read. Hardware-software co-design — concurrently shaping both the execution logic and the physical architecture it targets — has been limited to narrow specialist domains precisely because it requires abandoning human-readable generality.

Post-textual runtimes dissolve that constraint entirely. In molecular dynamics, co-designing a simulation algorithm directly with purpose-built hardware — as exemplified by the Anton supercomputer (Shaw et al.) — achieves performance scales that no amount of general-purpose software optimization can replicate.

In resource-constrained edge and mobile environments, partitioning computation between software and hardware accelerators such as FPGAs and DSPs allows systems to meet hard real-time constraints while slashing power consumption. Studies on edge-based recurrent neural network training demonstrate that an optimized hardware-software co-design approach can yield an 8.2-fold reduction in memory usage with only a marginal latency penalty compared to traditional non-partitioned approaches — gains that require the compiler to have free rein over both the execution binary and the hardware allocation layer simultaneously.

SIMD — Single Instruction, Multiple Data — is perhaps the most direct illustration of what co-design demands in practice. Exploiting SIMD requires structuring data layouts, memory alignment, and computation graphs in ways that bear no resemblance to human-readable code. AlDBaran (Kauer, Petrosyan & Livshits), an authenticated data structure engineered for high-throughput blockchain state commitments, achieves 48 million Merkle tree updates per second — 19× faster than QMDB (Quick Merkle Database, a human-readable authenticated data structure for blockchain state), the closest comparable implementation — by co-designing its algorithm around SIMD parallelism, aggressive prefetching, and cache-line-aware memory layout.

This is a long-standing problem. A naively human-readable implementation of the same Merkle tree cannot approach this figure even remotely: the performance is inseparable from the hardware-aware design.

02 The Debugging Paradox

Removing human-readable source code yields massive performance and security advantages, but it introduces an acute operational challenge: how do you debug a system that has no source code?

When a post-textual system encounters an edge case, a state-space explosion, or an unexpected behavioral failure in production, there is no file to open, no line number to inspect, and no variable name to print. The runtime is an opaque, hyper-optimized mathematical web. This creates a fundamental paradox: if a human cannot read the software's internal architecture, a human cannot manually fix it.

For internal execution-layer debugging, triage must be outsourced entirely to automated agent-to-agent pipelines. Modern autonomous frameworks show exactly how this machine-to-machine loop operates. TraceCoder (Huang et al.) bypasses binary execution feedback by deploying a collaborative multi-agent architecture that instruments runtime code with diagnostic probes to capture fine-grained trace streams, performing causal analysis over intermediate execution states to locate root errors.

DebugRepair (Lyu et al.) replaces outcome-level failure symptoms with simulated instrumentation and conversational repair loops, contrasting observed runtime values against expected behaviors to progressively refine patches. Debug2Fix (Garg & Huang) establishes specialized subagent architectures where a dedicated Runtime Oracle directly interacts with JDB/PDB debuggers — setting breakpoints, stepping through execution paths, and inspecting variables to isolate logic faults without any human intervention.

When a bug or violation is detected via the observability layer or reported by users, an automated triage loop isolates the issue and proposes a fix. A key challenge is how not to let this process create an iterative patchwork of patches — a familiar failure mode even at the source-code level.

However, is that still an issue when there is no human-readable code? As long as the fix generalizes enough, we are probably in good shape.

03 Specification Checks Replacing Source Code Audits

Traditional code review assumes a human can read a diff, evaluate logic, and flag errors. In a post-textual world, there is no diff to read — the compiled output is an opaque binary. Review must move entirely upstream: engineers review and approve the intent specification and invariant constraint set before compilation, not the resulting runtime artifact.

This changes the character of review fundamentally. Instead of asking "does this code correctly implement the spec?" reviewers ask "is the spec tight enough to prevent the runtime from ever entering a dangerous state?" That question requires machine assistance to answer rigorously — and the empirical record makes clear why. Pearce et al.'s large-scale audit of GitHub Copilot found that roughly 40% of outputs in security-sensitive scenarios contained at least one exploitable vulnerability, generated without any syntactic signal that something was wrong. The code looked correct; the spec it satisfied was simply incomplete.

Agents cross-check specification versions for consistency, flag newly added constraints that conflict with existing invariants, and generate counterexample witnesses that expose ambiguity in policy descriptions before the spec is compiled into enforcement. A pull request becomes a specification delta, and the reviewer's job is to approve the intent — not inspect the implementation.

But this is where the edifice has its weakest joint. A specification can be internally consistent and still produce unpredictable runtime behavior — because the agentic compiler that interprets and executes it is a probabilistic model, not a deductive one. Trusting an LLM to honor a specification faithfully is structurally different from proving that it does.

The right answer is not a tighter spec; it is a neurosymbolic enforcement layer that treats the agent's execution as the probabilistic half of a hybrid and enforces behavioral invariants as the deterministic half — invariants the agent cannot reason around, alias through, or outweigh with downstream context. A forthcoming post — Enforcing Security Invariants in the Post-Zero-Day Era — develops this argument in full: why the specification-as-trust model collapses under adversarial pressure, and what a runtime enforcement architecture that actually holds looks like.

04 The Testing Problem: From Unit Tests to Invariant Fuzzing

Unit tests are designed to verify internal implementation details — a specific function returns the right value for a given input. Post-textual runtimes have no functions, no return values, no internal state that a test harness can inspect. Plugging a traditional test suite into an opaque runtime yields only one signal: did it crash? That is too blunt to catch the subtle behavioral regressions source-era tests were designed to surface.

The replacement is a two-layer approach. The bottom layer is formal: a symbolic proof assistant verifies at compile time that the invariant set is internally consistent and sufficient to guarantee the API behavioral contract — a mathematical certificate that no possible execution path can produce a forbidden output.

The top layer is adversarial: fuzz agents hammer the API surface with inputs synthesized to probe edge cases the invariant set might not have anticipated. When a fuzz agent finds a gap, the result is not a failing test but a proof obligation. The specification is demonstrably incomplete, and the Intent Architect must harden the constraint that allowed the breach before the next compilation proceeds.

That unnameable quality creates a specific challenge for the testing layer: bugs cannot be reported by pointing at code, and tests cannot assert properties of named functions. The bridge is behavioral naming. The Intent Architect names behavioral predicates — WRITE-VISIBILITY-GUARANTEE, LATENCY-P99-CEILING, AUTH-BOUNDARY-ISOLATION — and these invariant identifiers become the stable vocabulary the entire system shares. When a fuzz agent finds a gap, it files the result against a named invariant, not a source location. When telemetry detects an anomaly, the incident report is indexed by which predicate was breached. The invariant name is the symbol — and it is more durable than a function name, because it names intent directly rather than implementation.

The mechanics of this shift — from test suites to formal invariants, and the failure modes that expose the gap — are explored in two previous posts: The Specification Spectrum: Narrowing the Guesswork traces the progression from property-based testing through refinement types to dependent types. Stubbornly Under-Specified shows exactly what happens when agentic projects skip this discipline: CCC shipped 19 silent miscompilations after passing every test; FastRender deadlocked under real CSS the test suite never assembled.

05 The Observability Problem: Behavioral Telemetry

Traditional observability relies on source-level artifacts: stack traces, line numbers, variable dumps, function names in log entries. A post-textual runtime can produce none of these. When a behavioral anomaly occurs, there is no log line pointing to a specific code path, because there are no code paths — only execution state transitions across a mathematical graph.

Observability must shift from source-level instrumentation to behavioral telemetry: streams of API call patterns, latency distributions, invariant probe results, and state-transition signatures. When these streams diverge from their expected behavioral fingerprint, an AI monitoring agent performs causal reconstruction — identifying which sequence of interactions preceded the anomaly, generating a hypothesis about which invariant boundary was stressed, and routing the failure signature to the synthesis agent as a structured proof obligation. The output is not a stack trace. It is a behavioral incident report that feeds directly into the debug pipeline described above.

This makes behavioral telemetry not a nice-to-have monitoring layer but a load-bearing component of the agentic loop itself. Without it, the debug agent has no signal to act on, the performance optimization loop has no regressions to chase, and the security audit layer cannot distinguish an invariant breach from normal operation. Every downstream capability in the post-textual stack — debugging, performance, security — is contingent on the observability layer producing structured, machine-readable signals. Instrument it poorly and the entire agentic loop goes blind.

06 The Performance Engineering Problem: Continuous Autonomous Optimization

Traditional performance engineering is a deeply human craft. Engineers attach profilers to production systems, read flame graphs, identify hot functions by name, and hand-tune critical code paths — shaving nanoseconds from serialization loops, rewriting memory access patterns to improve cache hit ratios, restructuring thread pools to reduce contention. Every technique depends on the engineer being able to read the code they are optimizing.

In a post-textual runtime there are no named functions, no call stacks, no line numbers in a profiler output. Performance engineering must therefore become a fully autonomous optimization loop: behavioral telemetry surfaces performance regressions as structured signals — latency percentile shifts, throughput drops, cache miss rate spikes — which performance agents receive as optimization obligations. Instead of opening a source file, the agent re-runs the agentic compiler with updated optimization objectives, generates a new runtime variant, and validates the performance gain against the behavioral invariant set before hot-deploying.

SysLLMatic (Peng et al.) already demonstrates what this looks like in practice: by coupling LLMs with runtime profiling diagnostics and a structured catalog of 43 optimization patterns, it achieves a 1.54× latency improvement on large-scale Java systems — surpassing both compiler optimizations and prior LLM baselines — without any human involvement in the tuning cycle.

In the long run, the deeper opportunity is that future models are not constrained to optimize for just functional correctness. A human engineer optimizing a hot path makes one change at a time, reasoning locally. An agentic compiler operating over a full-program intermediate representation can simultaneously co-optimize across latency, throughput, memory bandwidth, energy efficiency, and cache topology — exploring a combinatorial space no individual engineer could navigate.

The evidence for today's ceiling is unambiguous: Yi et al., studying 65 tasks mined from performance-critical open-source Java projects, find that LLM-proposed optimizations suffer extreme volatility and still lag behind human developers on average — primarily because models cannot autonomously pinpoint hotspots without direct profiling access. PerfCodeBench (Jing et al.) extends this finding to GPU workloads and parallelism tasks, confirming the same pattern: LLMs reliably underperform humans at the systems level when operating under the readability constraint.

PerfCoder (Yang et al.), however, shows that training on real optimization trajectories with strategy-aware supervision breaks past that ceiling: a 2.50× speedup with a 33% effective optimization rate — outperforming GPT-5 with a 7B open-source model. In a two-step workflow where PerfCoder guides GPT-5 as executor, the gain reaches 4.82× with an 80% effective optimization rate. The lesson is that performance optimization requires strategy awareness, not just scale. Lift the source-code readability constraint entirely and the optimization space expands to a regime no single-threaded human optimizer can match.

In a post-textual system, performance is no longer a phase of engineering — it is a continuous property of the compilation process and the runtime, autonomously maintained across every recompilation.

07 The Security Audit Problem: Red-Team Agents at the Boundary

Static analysis security tools — SAST scanners, taint trackers, vulnerability pattern matchers — all operate by parsing source code. Eliminate the source and you eliminate the entire SAST toolchain. Human penetration testers who manually audit code paths for injection vulnerabilities or privilege escalation vectors lose their primary working surface along with it.

Security auditing in the post-textual regime operates entirely at the API boundary. Formal invariant verification establishes information-flow policies — specifying exactly what data may cross the API surface, in which direction, and under which conditions — and the symbolic checker proves these policies hold regardless of internal execution paths. Adversarial red-team agents then probe the API surface for behavioral violations: inputs that satisfy the formal spec in letter but produce unintended information flows or privilege escalations in practice. The threat model shifts from "find bugs in the code" to "find gaps in the spec," and closing those gaps before compilation is the new security engineering discipline.

08 The API Caveat: The External Contract — and the MCP Exception

At first glance, the external API surface looks like an absolute limit on the post-textual programme. A system that has optimized every internal abstraction into oblivion is worthless if the outside world cannot communicate with it. For human-consumed APIs — REST endpoints, GraphQL schemas, gRPC contracts with typed client libraries — this is simply true: the syntactic contract is load-bearing, and breaking it silently breaks every downstream caller. The verification engine must prove that no matter how violently the agentic compiler shatters internal modules, globalizes state variables, or inlines loops across the execution, the deterministic behavior at the external interface remains intact. The API surface becomes the absolute anchor of human intent.

But this constraint is contingent on who is on the other side of the boundary. The Model Context Protocol (MCP) changes the calculus entirely when both parties are agentic. MCP exposes capabilities rather than fixed endpoints: a consumer agent asks the server what it can do, and the server responds at runtime. There is no frozen schema to break. Tool signatures, parameter names, and response shapes can evolve without breaking callers, as long as both sides speak the same protocol envelope. Capability negotiation replaces versioning.

In a fully agentic stack — where every caller and every service speaks MCP — the external contract degrades to the protocol version only: a surface small enough to be machine-maintained indefinitely. The post-textual optimization loop can extend past the API boundary.

The real duality is no longer internal versus external; it is human-facing versus agent-facing. Human-consumed surfaces remain non-negotiable. Agent-facing surfaces served via MCP are fluid, and the path toward a fully post-textual engineering stack runs through making more of the world agent-facing.

09 Conclusions

The post-textual transition forces us to confront a foundational truth: source code was never a fundamental requirement of computing. It was merely a user interface designed for the human brain.

When we remove text files from the engineering pipeline, software stops being a static document and becomes an ephemeral, dynamically synthesized resource. The traditional boundaries of software engineering largely dissolve. We no longer write programs; we design specifications, boundaries, and validation properties.

By liberating the machine from the mandate of human readability, in the limit we transition software into its ultimate form: an ultra-optimized, self-healing, and mathematically flawless runtime that operates entirely beyond the human cognitive ceiling.

Although we argue for the performance optimization upside, the three layers that make this viable and safe are the same three layers the preceding posts in this series have built toward: an intent specification precise enough to compile into invariants, a formal verification layer that checks behavioral invariance at the external boundary, and agent-to-agent debugging loops that close the gap between invariant breach and hot-patched resolution — with no human required inside the repair cycle.

Maybe source code was the scaffold. Maybe the scaffold is coming down.

References

• McConnell, S. (1993). Code Complete: A Practical Handbook of Software Construction. Microsoft Press. (2nd ed. 2004.)

• Sawada, S., et al. (2026). "To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study." Proceedings of the 30th International Conference on Evaluation and Assessment in Software Engineering (EASE '26). Available at: arxiv.org/abs/2605.06464
• Li, X., et al. (2026). "Environment-in-the-Loop: Rethinking Code Migration with LLM-based Agents." arXiv:2602.09944. Available at: arxiv.org/abs/2602.09944

• Cao, Z. (2026). "Agentic Software: How AI Agents Are Restructuring the Software Paradigm." arXiv:2606.05608. Available at: arxiv.org/abs/2606.05608
• Yang, J., et al. (2026). "ProgramBench: Can Language Models Rebuild Programs From Scratch?" arXiv:2605.03546. Available at: arxiv.org/abs/2605.03546

• Bilokon, P., & Gunduz, B. (2023). "C++ Design Patterns for Low-latency Applications Including High-frequency Trading." arXiv:2309.04259. Available at: arxiv.org/abs/2309.04259

• Shaw, D. E., et al. (2009). "Millisecond-scale molecular dynamics simulations on Anton." Proceedings of the Conference on High Performance Computing Networking, Storage and Analysis (SC '09), Article 39. ACM/IEEE.
• Kauer, B., Petrosyan, A., & Livshits, B. (2025). "AlDBaran: Towards Blazingly Fast State Commitments for Blockchains." arXiv:2508.10493. Available at: arxiv.org/abs/2508.10493

• Jing, H., et al. (2026). "PerfCodeBench: Benchmarking LLMs for System-Level High-Performance Code Optimization." arXiv:2605.15222. Available at: arxiv.org/abs/2605.15222
• Yi, L., Gay, G., & Leitner, P. (2025). "Do AI Models Dream of Faster Code? An Empirical Study on LLM-Proposed Performance Improvements in Real-World Software." arXiv:2510.15494. Available at: arxiv.org/abs/2510.15494
• Yang, J., et al. (2025). "PerfCoder: Large Language Models for Interpretable Code Performance Optimization." arXiv:2512.14018. Available at: arxiv.org/abs/2512.14018
• Peng, H., et al. (2025). "SysLLMatic: Large Language Models are Software System Optimizers." arXiv:2506.01249. Available at: arxiv.org/abs/2506.01249

• Pearce, H., et al. (2022). "Asleep at the Keyboard? Assessing the Security of GitHub Copilot's Code Contributions." Proceedings of the 43rd IEEE Symposium on Security and Privacy (S&P '22). arXiv:2108.09293. Available at: arxiv.org/abs/2108.09293

• Huang, J., et al. (2026). "TraceCoder: A Trace-Driven Multi-Agent Framework for Automated Debugging of LLM-Generated Code." OpenReview Preprint.
• Lyu, X., et al. (2026). "DebugRepair: Enhancing LLM-Based Automated Program Repair via Self-Directed Debugging." arXiv:2604.19305. Available at: arxiv.org/abs/2604.19305
• Garg, S., & Huang, Y. (2026). "Debug2Fix: Can Interactive Debugging Help Coding Agents Fix More Bugs?" arXiv:2602.18571. Available at: arxiv.org/abs/2602.18571