When Code Becomes Free, the Codebase Becomes the Prompt

Ryan Lopopolo (LinkedIn, X, GitHub), a Member of Technical Staff at OpenAI, argues that implementation is no longer the scarce resource in software engineering. Coding agents produce code at scale; the bottleneck has moved to human time, human and model attention, and the model's context window. The engineer's job, he says, is to restructure code, processes, and tooling so agents can do the work -- not to write the code. He has banned his team from touching their editors.

FIGURE 2 ⋅ Three-card thesis slide: "The models are good enough." / "Code is free." / "Your role is to unblock your team."

"Code is free, and I know this is maybe a scary thing to hear because code carries maintenance burden, but it's free to produce, free to refactor, and it is not a thing to get hung up on anymore."

What Changed and What's Now Scarce

Lopopolo dates the shift to late 2025. He claims a recent generation of coding models was the first that could do the full job of a software engineer end to end, not just produce snippets. He calls himself a token billionaire and says each engineer in the room has access to "5,000 engineers worth of capacity, 24-7" -- a rhetorical figure, not a measurement.

If implementation capacity is effectively unbounded, three things become scarce: human time, the attention of both humans and models, and the context window the model can hold while it works. Every engineering decision after that has to be made against those three constraints.

FIGURE 3 ⋅ Three-card slide listing the new scarce resources: "Human time." / "Human and model attention." / "Model context window."

Refactor Constantly, Because Code Is Disposable

The instinct to minimize churn is wrong, Ryan argues, because code is now cheap to produce and cheap to throw away. Migrations that used to stall for six months can be done by firing off fifteen agents in parallel. Sameness across a codebase becomes a feature rather than a smell: consistent code produces more predictable model output and stretches the context window. He wants one ORM, one language, one CI script style, one lint pattern -- maximum uniformity so the tokens the model has to reason over are predictable.

His own project grew from a single Electron repo into 750 PNPM packages organized by business domain and stack layer. The directory tree itself is a way to scope agent context: file-system structure gives the agent hooks for what to load and what to ignore.

Everything in the Codebase Is a Prompt

Code's purpose, in his view, is to feed the model context. File structure, lint rules, error messages, tests, and directory layout are all forms of prompt injection -- ways to surface instructions to the agent at the moment they are needed.

"Fundamentally, the models are trained to follow instructions. All the harness should do is surface instructions to the model at the right time."

The surfaces his team treats as load-bearing:

agents.md files in the repo
Skill files and rules files
Custom ESLint rules wired into every package
Lint error messages that suggest remediation, not just identify problems
Reviewer agents that comment on PRs as part of CI
"Wholesome tests" that assert structural properties of the code itself -- package privacy, dependency edges, Zod schema deduplication, canonical async helpers
A file-length test that rejects files over 350 lines, to keep context manageable

He also built a meta-skill: he pointed his coding agent at his company's prompting cookbooks and had it synthesize a skill for writing prompts, which he then uses to write prompts.

"I use the skill to write prompts that I wrote with the agent looking at the prompts to write the prompts."

FIGURE 4 ⋅ Single-statement slide: "You can just prompt things."

Code Review Redesigned Around Agent Throughput

On a team of three producing three to five PRs per engineer per day, human review becomes the bottleneck and merge conflicts pile up. Ryan's team adopted what he calls "garbage collection day" -- one day a week where engineers categorically eliminate classes of slop across the codebase.

Review moved through three phases: human comments, then repository documentation, then automatic prompt injection via failing tests or reviewer agents primed on persona documents (front-end architect, reliability engineer, scalability). PRs don't block on review. Participants can accept, defer, or reject feedback, and the bias is toward acceptance.

"You can just simply say, do not produce slop. Don't accept slop. You won't get slop in your code base."

LLM as Fuzzy Compiler

If code is disposable and the prompt is load-bearing, the relationship inverts: the spec becomes the source, and code becomes the build artifact. Swapping models is then analogous to swapping LLVM for Cranelift in the Rust compiler -- different backends producing the same output from the same source. He calls the mental model "LLM as fuzzy compiler" and flags it as a mental model, not a product claim.

The operational implication: every time he has to type "continue" to an agent, the harness has failed to provide enough context for the model to run the job to completion. The harness's job is to make those interruptions disappear.

Takeaway

Lopopolo's argument is that the engineering job has moved up one level of abstraction: from writing code to operationalizing an environment so agents can do the full job. The work is in the structure, the rules, the tests, and the prompts that surface instructions to the model at the right time.

"Humans no longer need to concern themselves with implementation. The important thing is not the code, but the prompt and the guardrails that got you there."

FIGURE 5 ⋅ Closing slide: "You can just build things."

Ryan Lopopolo spoke at AI Engineer Europe 2026. Member of Technical Staff at OpenAI.

Watch the full talk | Harness Engineering article | Latent Space episode | LinkedIn | X