If you're still coding like it's 2022 (or even 2025) then you're likely bottlenecking your SDLC (Software Development Life Cycle).
- Agents read and write faster than us
- Agents can validate faster than us
So everytime we have a human in the loop of a change, we typically end up bottlenecking these agents.
Here's my hypothesis for how we speed up our SDLC such that we get the best of all worlds: make the code disposable and the context durable.
- Speed of AI agents
- Quality of human systems
- Understanding of the system as if we were in the loop the whole time
What are we bottlenecking on?
I think we first need to agree on what the bottleneck is in our agentic cycle.
For my agentic engineering loop, my cycle roughly comes out to:
- Set Direction - Align on the problem, outcomes, and constraints.
- Create Plan - Choose an approach to implement the Direction.
- Code feature - Implement the Plan.
- Review Code - Review direction and implementation.
- Ship feature - Review in prod.
So far I've found that agents typically can crush the code if you get the direction, plan, and guardrails right. Where us humans typically bottleneck is in the review - understanding what was done, why we did it, checking all the edge cases. The Direction + Plan are also a bottleneck but largely I see that as a necessary bottleneck - aligning on the What we want to build. For Review though I'm thinking the agents these days are probably good enough to do this for us (assuming you have a refined agentic code review process).
hamytodo - link my agentic code review skill post
That said, I don't think review happens in a silo nor do I think the outcomes review sets out to achieve is smth we want to get rid of. In code reviews we're trying to:
- Ensure understanding of intent and outcome
- Validate the intent and outcome match up
- Think through alternatives and if one might be better
I think these are good things!
- If we don't understand the system -> we don't build long-term intuition and end up creating short-sighted solutions, fragile systems
- If we don't validate intent and outcome match up -> we build things we don't need and build a ball of mud
- If we don't think through alternatives -> We end up with suboptimal solutions that compound into worse systems
This is all still very important! I just think we're going about it inefficiently.
Code is not the source of truth
To get away from the need to read all the code (which humans are very slow at!) I think we need to reframe the source of truth of our system from the code to the context.
- The Durable Context is the source of truth for what the system should do (its DNA)
- The Disposable Code is a build artifact of it - what's currently happening (its current body)
This may seem weird at first because for a long time we've considered the code to be the source of truth. It is what runs the system after all.
But now that we can generate code cheaply I think we should instead be focused on what the system should do rather than what it does today. And that's where the context comes in.
Another way to think about it is that you can take any given app and swap out all sorts of implementation details and it's still the same app.
- Rewrite it from Ruby to Rust
- Use Svelte instead of React
- Unity instead of Unreal
- A list or a map
- Hosted on my home computer or on a VPS or in the cloud
And it kind of becomes a ship of Theseus idea - if we rebuild everything with other materials is it still the same ship? Well in the context of a product if the product gets the same outcomes then largely I think it is the same product. The code then is an implementation detail and the context / rules about how the product works is actually the source of truth.
By doing this we gain a lot:
- There's less text required to define a product's behavior so humans can think about the high level ideas without bogging down in reams of text
- The same is true for changes to this behavior - much easier to review!
- Agents can go wild on the code - writing and rewriting what they need as we figure out what the behavior should be
- We can be less precious about the code because it's not trying to also serve as organizational memory the Durable Context is the source of truth for what should happen, the code is just how it does that today.
- This unlocks all sorts of speed / velocity when it comes to doing large scale migrations
Durable Context for System Integrity
The idea is to pull out the essence of the artifact (its DNA) and focus on that, allowing the other systems to generate from there (like the body).
What is durable context? The requisite context to rebuild that system from scratch.
Context I think is useful:
- Foundation - Why our system exists. What, for who, so that.
- Requirements - What our system needs to accomplish from an end user perspective
- Architecture - High level how we want to approach this along with decisions and some details about clever approaches, tricky areas, or non-obvious tradeoffs we've made
- Verification - How we check this is working as expected in a BDD (Behavior Driven Development) style - Acceptance, contract tests, architectural checks. Allows us to build enforceable guardrails from the Durable Context.
And sometimes some other things:
- Decision records - For big decisions or directions we've already explored and decided on to prevent endless exploration of areas we've already tried.
- Glossary - So we can speak the same ubiquitous language
- Designs - If we're tied to a certain experience / flow similar to the requirements
That's it. If we have this then I think for the most part we can get an 80% representation of what our system should do with much less text. At least 20% perhaps even 1-2%.
And each review / implementation / alignment meeting on this context has a 10x impact on the resulting system allowing humans to do the slow, deep thinking we're good at while keeping up with the agent's speed.
Humans align on the Durable Context then we spin up agents to generate the Disposable Code from it.
Change Context for updating Durable Context
A useful system solves a problem so it must change as the problem and our understanding of it changes.
At a company there will be hundreds / thousands of changes going on all at the same time. So to update the system we need to update the context but we also need a way to manage concurrent and sometimes overlapping context updates.
To do this I think we use Change Context which are ephemeral project context we use to plan a change and then merge into the Durable Context as the system changes.
A Change looks very similar to our Durable Context:
- Foundation - What we're doing and why. Gets merged into Durable Foundation.
- Requirements - What the new system must do. Gets merged into Durable Requirements.
- RFC - How the system will work technically. Gets merged into Durable Architecture.
- Design - Any details about how we think the system / flow should work. Gets merged into Durable Design.
- Stories - In markdown or tracker of choice to facilitate coordination / progress tracking.
At the end of a project / as we update the system, the Change Context is merged into the Durable Context and then deleted when no longer needed.
System Guardrails for staying on the rails
Now we're really trying to find a minimal representation of context to describe the entire system (kind of a minimum spanning tree). But obviously there's going to be edge cases and areas to tweak.
I think from here we get into the messy gray area where agents aren't quite good enough to build code / systems that perfectly "just work". At least not yet.
So for these cases we lean into our guardrails to help ratchet up the code quality so we still focus on the Durable Context of the system via guardrails but also can control lower level things like coding standards and review items to ensure the code quality is up to par.
Together this gives us a pretty good set of boundaries:
- Durable Context for what we're building towards / trying to accomplish
- System Guardrails to keep us on track, avoid common pitfalls
A deep dive into these areas is beyond the scope of this post but my current strategy for this is to shift left as much as possible towards fast, deterministic guardrails.
From fastest and most deterministic to least:
- Structural Guardrails - Guardrails that provide 1 clear paved road and make invalid routes unrepresentable.
- A clean codebase, types that make invalid states unrepresentable, clear APIs and abstractions
- Mechanical Guardrails - Guardrails that can be run to give clear, deterministic feedback on rule breaks.
- Linters, compilers, CI, git hooks, CLI tools for verification, tests
- Judgement-based Guardrails - Guardrails where a reviewer interprets the result and determines if the result is valid.
- AI code reviewers based on CODE_STANDARDS / CODE_REVIEW, CLI tools for common operations that must still be checked
- Guidance Guardrails - Guardrails providing context for agents to follow.
- Things like skills and style guides. Useful to have written down but far harder to deterministically discover and enforce.
Next
So that's how I'm currently thinking about moving faster with agents while staying connected to the system.
- Humans set Direction via Durable Context - this allows us to focus on the outcomes we want to achieve which is a fraction of the text the full system requires, allowing us to do the deep thinking we're good at and skip the parsing we're bad at
- Agents do the footwork of generating the resulting system - allowing them to use their full speed on building the features and products we've planned
- Ratchet up quality using System Guardrails to create a pit of success for agents and wipe out classes of errors and gotchas
As always this is a process so we have to crawl then walk then run. My advice remains to start hands on, improve the context, and speed up as your agents gain trust by producing better work within your system.
Thank you to my Haminions members for supporting my work and making free posts like this possible. Members get access to dozens of example projects including a monthly snapshot of my full AI Dotfiles.
If you liked this post, you might also like: