Code creation is the interface
When people say “agents,” a lot of them are imagining chat as the product.
A box where you type what you want, the model replies with a plan, and maybe it clicks around in a browser or calls a tool. It feels like the next UI paradigm, because it looks like the UI.
But that view mostly describes the entrance, not the engine.
The leverage shows up later, when the agent stops narrating and starts producing executable artifacts, running them in a constrained environment, and updating its approach based on what happened. That is code creation plus sandboxed execution plus feedback-driven reasoning.
This is not a speculative take anymore. Lenny Rachitsky () summarized a conversation with Alexander Embiricos (), OpenAI’s Codex product lead, and one of the takeaways is blunt: writing code may become the universal way AI accomplishes tasks, because models perform best when they can write small programs on the fly instead of clicking through interfaces or relying on bespoke integrations: .
That combination is the tell. People close to the frontier are converging on a practical design: the agent’s real “hand” is code.
Why chat is a weak control surface
Chat is great for one thing: negotiating intent.
It’s a good way to ask follow-up questions, clarify constraints, and get humans aligned on what “done” means. It’s a good place to start.
It’s a bad place to finish, because language is slippery. It can sound correct while drifting away from reality. It can claim progress without touching state. It can hide uncertainty behind confident formatting.
The world pushes back in ways chat does not. The world has permissions. The world has schemas. The world has partial state and race conditions. The world has irreversible actions.
So an agent that lives primarily in chat will often top out as a very articulate planner. Helpful, sometimes impressive, occasionally dangerous. A system that lives in code is forced to be accountable. It has to compile, run, and face error messages.
That is the difference between “agent as conversation” and “agent as execution.”
Codex is a clue because it sits in the execution path
OpenAI’s own write-up on shipping Sora for Android with Codex is useful because it’s concrete. They describe shipping an internal build to employees in 18 days and launching publicly 10 days later, while keeping a high bar for engineering practices and reliability. Regardless of how you feel about the story, notice what the interface was: diffs, tests, code review, and the normal lifecycle of real software. Not a browser puppet doing interpretive dance on a UI.
This matches another detail from Lenny’s takeaways: early Codex was “too far in the future” when it ran asynchronously in the cloud, and adoption changed when it moved back into the developer’s editor on their own machine.
That is a product lesson. Putting “agent-ness” in a separate place is fun for demos. Putting it inside the execution loop is how it becomes default.
The agent loop that matters
Once you stop treating chat as the interface, the core loop becomes simple:
- Produce the smallest executable artifact that can advance the task.
- Run it somewhere safe.
- Inspect the results, including failures and side effects.
- Revise and rerun.
That is what “reasoning” looks like when it is tethered to reality. It is not a monologue. It is choosing the next step correctly given constraints and feedback.
This is also why the “small programs on the fly” point matters more than it sounds. Most work is not a single tool call. It is a chain: pull data, normalize it, validate it, enrich it, apply policy, write updates, notify stakeholders, and record an audit trail. A UI can cover the top 20 percent of flows. The remaining 80 percent lives in glue code.
A capable agent can synthesize that glue quickly. It can write a query, a transform, an API call sequence with retries, a diff plus tests, a workflow config, a transaction bundle. Tiny artifacts, but runnable and inspectable.
That becomes a universal adapter for the messy real world.
Sandboxes are where the real product work is
If code creation is the interface, then the next question is not “how good is the model at planning,” but “where does the code run, and under what constraints?”
This is where most agent products either get serious or stay a demo.
A sandbox worth trusting has a few properties:
- Constrained authority. Least-privilege permissions, spend limits, rate limits, network allowlists, and explicit approvals for high-risk actions.
- Auditability. Every run produces artifacts: diffs, logs, traces, receipts. You can answer what changed, when, and why.
- Reproducibility. The same code can be rerun. Inputs and outputs can be replayed and compared.
- Cheap failure. Dry runs, staging environments, test wallets, canaries. The agent needs a safe place to be wrong.
This is why “UI clicking agents” are fragile in production. Human interfaces are high entropy. Buttons move. Layouts change. A/B tests and locale variants break flows. You can make it work, but you are building on sand.
Programmable surfaces are lower entropy. APIs and schemas break too, but they break loudly and in ways you can test and gate.
The practical implication is that the hard part of agent product is not chat. It is building the execution harness around program synthesis.
Humans become the bottleneck, so review becomes the interface too
Lenny’s episode framing is about humans as the bottleneck, and the discussion around Codex repeatedly points at a shift where generation gets cheap and review throughput becomes the constraint.
This is another reason code is such a good substrate. Code creates a review surface.
You can build a UI for approvals that actually works:
- Summarize intent, not just syntax diffs.
- Run the right tests and present evidence in the right order.
- Highlight blast radius and risk, then offer safe defaults.
- Make rollback and scoped re-runs painless.
- Stop automatically when invariants break.
This is how you scale trust. Not by making the agent sound more confident, but by making it easier for a human to say yes or no with good information.
In other words, the interface shifts again. First from screens to code. Then from code to review tooling that compresses decision-making.
What builders should optimize
If you want an agent that interacts with the world in a way that compounds, the roadmap starts looking less like “add more tools” and more like “treat the agent as a generator of runnable artifacts inside a governed runtime.”
That means investing in:
- Stable programmable surfaces (APIs, schemas, event streams)
- Execution harnesses (sandboxes, idempotency, retries, policy enforcement)
- Verification (tests, simulations, invariants, staged rollouts)
- Review UX (evidence, approvals, rollback)
- Observability (logs, traces, audit trails)
That’s why the Codex perspective is so revealing. Embiricos put it plainly in his own words: one of the best ways for models to use computers is simply to write code.
Chat will still be the front door, because humans prefer language. But the alpha is in what happens after the front door. The agent that matters is the one that can generate the program, run it safely, learn from the result, and present evidence that makes approval easy.
Want to publish your own Article?
Upgrade to Premium