The AI coding dream
How do we maximise the efficiency gains of coding agents, while managing their limitations? That depends on what we care about:
Speed, Efficiency and Autonomy:
- The demand for (good) code has often exceeded supply (just look at a popular project’s issues page, or a SWE’s salary), and any help in this area is always welcome
- Agents alone provide these in abundance: concurrent sessions, subagents, agents in the cloud, etc. Developers have become extremely cheap and fast, eliminating the execution bottleneck
Quality and Performance:
- Generally, we would like our software to be reliable and fast
- Running agents in loops and swarms have led to incredible improvements in optimisation, refactoring and reverse engineering, but the result is only as good as the definition of the goal (as a contrived example, “make this webpage load as quickly as possible” is trivialised if you delete the page’s content)
Control over Outcomes:
- Building on the last point, AI needs careful guidance and direction to execute your intent (also true of humans), hence the evolution of prompt engineering, context engineering, spec driven development, etc.
- This is how human “taste/judgement” is exercised, so we build something we actually want
But why do we engineer prompts, context and specifications? Ultimately, these serve as proxies to communicate the decisions we make, that shape our mental model of what we are building.
What’s in our code?
A codebase is some sequence of decisions, that are related in a vaguely hierarchical way
- You start with high-level decisions (I want to make a todo app)
- Gradually, you refine those decisions (What features should this app have? What platforms should it support? What language/framework should I use?)
- You refine them further (How does the “mark complete” feature work?)
- And further (When I mark an item as complete, what happens to the item?)
- Then you translate those into implementation decisions (schemas, data structures)
- And finally into actual implementation (code)
Even in writing the code (step 6), you are likely performing an approximate, scoped version of the process (and if you aren’t, you probably should)
State of the Art
Now let’s look at what AI and vibe coding do to this process:
- You start with a prompt
- (optional) You make a plan together with your agent
- Agents turn it into implementation
If you use the standard, widely-used chat-like interface, the planning process might look something like this:
- The agent thinks for a few minutes and generates a long plan, tens to hundreds of lines long and with many implicit and explicit decisions it made for you
- You review the plan and correct the decisions you deem necessary
- Repeat as many times as needed
Often, the agent makes further decisions upon your corrections, or leaves some decisions out, or doesn’t realise some decisions need to be made. Sometimes agents change decisions between sessions, or make different decisions when modifying code they previously wrote
The Future
This is not a criticism of agents (we do many of the same things), but of the way we work with them:
- It’s unrealistic to expect an agent to correctly predict every single decision you make (they don’t read minds yet)
- Often, decisions are changed during development, but the impact of that change is not well known
- Reading vast quantities of text across many plan/spec documents and having to figure out how new decisions relate to decisions in the past (or even with one another) is difficult and tedious, for both humans and agents
- Code may be a spec, but it does not encode intent
- The feedback loop is slow and exhausting, and the amount of text produced is overwhelming
So communicate those decisions directly, and persist them as context that agents and humans can both navigate, manage the decisions that you make and how they relate to one another and focus on deciding what to do and why, leave execution to the agents.
We’re building the interface that bridges decisions and execution, so humans and agents can each focus on what they do best.