My 5-part system for coding with AI
Project context, reusable skills, isolated workspaces, and evidence loops: the system I use to orchestrate coding agents.
Get the guide to build your first AI agent directly in your inbox on newsletter signup:
The model is the easiest part of my AI coding setup to replace. The moment the newest model is available, I just plug it in.
What took months was building the system around it: project context, reusable procedures, isolated workspaces, explicit task state, fast feedback, and agents that return evidence I can inspect.
That is my answer to the best AI setup for software engineers. At least, the best that I know of right now. Build an operating system around the agent that preserves your understanding
For me, it has five parts, and we’ll cover them all in today’s article
Durable project context and reusable procedures.
Isolated execution with fast feedback.
Explicit task state outside the chat.
Parallel agents with one human work item in progress.
An evidence and coordination loop around the code.
The best AI coding setup is an operating system, not a tool
Most setup guides start with the editor, model, terminal, or agent.
Those choices matter, but they are easy to change. A model is just a string in my config. I’ve gone through multiple AI IDEs until landing in the terminal as my preferred workstation. I’m sure they will keep changing.
What matters is the setup to answer five questions:
What does the agent need to know?
How should it perform this kind of work?
Where can it make changes without corrupting another task?
How does it know whether the change works?
What evidence will I inspect before I approve the result?
This is important because if one answer is missing, it’s the human who absorbs the failure.
This is why I think software engineers are too focused on code generation. Code became cheaper. Understanding the system, defining correct behavior, and proving that the change preserves it remain expensive.
Here is the split I use:
Search in code or in the AWS Account. The machine handles the search. I decide what to do with that information.
Compare code with our standards. The machine finds deviations. I choose if it’s justified or not.
Run builds, tests, and linters. The machine executes the checks and fixes the failures. I decide if the fix they did was good or not.
Watch tickets, reviews, and CI. The machine monitors the state. I take action once I can
Prepare reports and alternatives. The machine organizes the evidence. I own the final document and how I communicate it.
Humans are bad linters. Give me 2,000 code lines, and I will find performance inefficiencies, deviations from standards, and many more. The machine can check all of those every time.
My useful work starts when the findings become a decision. Should this service own the behavior? Is the new abstraction worth its maintenance cost? Did we preserve the product requirement?
I know many people were delegating those things to their seniors, and they were just writing code as told. Those people will have a harder time, so let’s start building a system everyone can use to become irreplaceable.
Give agents durable context and reusable operating procedures
The first version of my AI workflow depended on prompts.
I kept explaining the same thing all the time: architecture, the build commands, the project-specific tools, and the mistakes the agent should avoid, based on previous executions. The prompts became longer because every failure added another paragraph. At some point, I even created a prompt library (this was before having Agent Skills).
That approach made me the glue between the company and the agent. If I forgot one detail, the agent worked in the wrong direction.
I now separate the information by how long it should live and how broadly it applies.
Rules: Stable constraints that live for months and apply across many tasks. Examples include architecture boundaries, language conventions, and forbidden operations.
Skills: Reusable procedures for one type of work across many runs. Examples include investigating a ticket, reviewing a PR, or verifying a revision. I compose skills by building some broad ones that are a series of steps, each step with its particular skills. I call those SOPs.
Task prompt: Temporary context for one task. For example, fix this endpoint while preserving these two flows; this is the ticket we’re working on.
Put the project around the repository
Whether I have one package or multiple, I use a wrapper that tells the agent how the software fits into the company.
I got this idea from a Principal Engineer at Amazon, he called it the metarepo (making a local monorepo of multiple packages that are separate git repos)
engineering-system/
├── context/
│ ├── architecture.md
│ ├── coding-standards.md
│ ├── environments-and-accounts.md
│ ├── ownership.md
│ └── source-links.md
├── rules/
├── skills/
│ ├── investigate-ticket/
│ ├── review-pull-request/
│ └── verify-revision/
├── workflows/
│ └── implement-and-qa.md
└── templates/
├── saved-state.md
└── evidence-report.md
The context includes things the code cannot tell the agent:
Which AWS accounts do we deploy to?
Which service or team owns a configuration?
Where does the CI/CD pipeline live?
Which document contains the original decisions?
Which internal SDK replaces the public library that the model already knows?
Which actions require human approval?
I prefer links to original sources over copied summaries. A copied paragraph becomes stale silently. A source link gives the agent somewhere to check, and it gives the human a way to verify the claim.
I also keep credentials out of this layer. The agent can know that an AWS role exists and which procedure grants access. It does not need a secret saved in a Markdown file.
Turn repetition into a skill
The part I underestimated was the progression from rules to skills to SOPs.
My process was like this:
I perform a task with the agent.
I notice instructions I repeated or a failure I had to correct.
Stable knowledge moves into the project rules.
A repeated sequence becomes a skill.
Several skills become an end-to-end workflow.
As I keep using the workflow, I iterate and polish it
For example, “review this PR” is a prompt. It depends on what the model decides a review means that day, and how the model decides to obtain the code, what to check.
A PR review skill can require the agent to perform certain actions like comparing against the previous code, compare it actually implements what we need to implement, or giving me the comments in my expected format
Now the output is similar across runs. I keep improving the procedure when it misses something, so I know all future executions won’t miss it. This is where the results compound. I fix a workflow once, then every future task receives the same improvement.
A useful next step is this guide to turning repeated prompts into agent skills and a complete autonomous workflow:
Give every task isolated execution, fast feedback, and explicit state
Agents are more than code generators. I started generating code in a web UI chatbot like ChatGPT.
The point of agents is these 3:
Isolated execution:
Start with a Git worktree, for some situations, you may need an isolated container. I fetch origin/main, create a short-lived branch and worktree, and let one agent own that task. I follow trunk-based development (having only a single main branch and merging on top of it, so this makes every additional branch only have at most 1 commit. This reduces but doesn’t remove conflicts, and the conflicts are simple and small enough that you can solve them easily.
Fast feedback is part of the infrastructure
The agent needs a cheap way to know if the code is correct for the compiler (build), correct for the project (tests), and correct for our requirements (run some manual tests besides the automated ones)
Long feedback loops reduce the autonomy of an agent. If the correct build takes forty minutes or requires a human to click through five internal tools, the agent will either stop early or claim completion based on weaker evidence.
Put task state outside the conversation
Chat history is a terrible task database. It’s sequential, but you may go at different levels of abstraction in each chat turn.
It hides dependencies, blockers, owners, and acceptance criteria inside long paragraphs, instead of stating things in a place where you’d expect them to be. When a session ends, the state becomes difficult to inspect. When another agent starts, it has to reconstruct the task from a transcript of another agent's conversation.
I started persisting Markdown files of investigations I did in the project in an Obsidian Vault. I have a Vault fully operated by AI, and I inspect in Obsidian those Markdown files and decide what to keep and what to drop. The difference between the obsidian vault and the metarepo is that the metarepo contains the information useful for the long term, and the obsidian vault contains the information relevant for this task, such as steps done, progress, or the spec with the implementation plan
That distinction matters when agents work asynchronously. An agent may move a ticket from investigating to needs-decision Because it found two valid alternatives. It should not silently choose one and rewrite the acceptance criteria. You want to create a harness that forces your agent to write a report, and you inspect it, as an executive inspecting what their reports provide.
If you want the deeper engineering principles behind agent context, deterministic checks, and feedback loops, read this harness engineering guide:
Run agents in parallel while you stay single-threaded
Running three agents is easy. Paying attention to three agents is exhausting.
I learned this by doing the obvious thing. I started a prompt, waited, opened another task, started a second prompt, checked Slack, and after a few of these hops, I forgot what I was working on originally.
It makes me feel old. I forgot pieces of work that I had started, and I only realized it when I randomly opened that same terminal tab or browser tab.
That’s where I discovered herdr, and I’m enjoying it a lot. It’s an alternative to tmux, a terminal multiplexer, but it gives me one place to run and orchestrate agents across workspaces. I have zero affiliation, but I think it’s a very cool piece of open source software that you’ll like. It’s a great hybrid between UIs and terminals, because it runs in the terminal but clicks magically work
Herdr solves the execution side. The attention side needs a separate rule:
Agents run concurrently. I keep one human work item in progress.
It’s easier when the tool works for you instead of against you. You can have sound notifications, and the agents have a clear state, so you can filter by agents in the done/blocked state and jump into them to unblock them.
For me, there are three modes of working:
Waiting on one prompt. I am single-threaded, and I work in only one agent. We can focus deeply, but we work slowly only on one thing.
Fake multitasking. I switch between partial agent conversations and rebuild each mental model repeatedly. I’m faking productivity.
Async orchestration. Agents prepare artifacts in my AI Vault. I can know when the agents I’m running are all completed. I work on one task and workspace at a time. I let the agents do the work, and once I have finished with it, I can jump into the next workspace with agents that are pending my input.
The third mode is the one I use. I may ask one agent to investigate a ticket, another to verify whether my PR comments were addressed, and a third to implement an already approved plan. They can work in parallel because the tasks have separate workspaces, explicit state, and expected outputs.
I do not tail their conversation. I just wait until herdr marks them as done so I will check them on my next switch.
When I arrive at a workspace, I have a report with all the relevant information and the decisions required of me.
This is how executives work. They have their reports do the work and present the information. An executive who has to micromanage people won’t have great results. An engineer micromanaging the AI agents will also fail.
Save the human state too
Parallel work breaks when every paused initiative lives only in my head.
I keep a simple TODO-list of the things that I have to do and that I’m working on, so I have a bit of a bigger picture of the work I have to do.
I include here both my implementation tasks and all the other pieces of work, like reviewing someone’s code, something I have to tell someone, or an interview I have to prepare
This looks boring because it is. It also means I can return two days later and start from the next decision instead of rereading everything.
Single human WIP and saved states let me support several initiatives without pretending that my brain can reason about all of them at once.
The risk is queuing low-quality work. Ten vague tasks can produce ten vague reports and a bigger review burden. I only delegate work when I can define the boundary, expected artifact, and stop condition.
A useful next step is this breakdown of how AI waiting time turns into context switching, and how to keep deep work while agents run:
Turn engineering into an evidence and coordination loop
The greatest improvement in my workflow came from moving decisions earlier, while changes were still cheap.
My loop is simple: investigate, model the problem, challenge assumptions, choose, implement, verify, and report. A plan mode lets me inspect the reasoning before the agent creates a large diff, but only after the agent has read the code, source documentation, ticket history, and operational evidence.
For example, for an endpoint change, I ask the agent to trace the request, identify the data owner, list every consumer, and show the existing test coverage. It then explains the invariants, alternatives, blast radius, and missing evidence in plain language. The agent prepares the decision surface. I choose which tradeoff to take.
I also define verification before implementation. If the change affects an endpoint, the agent should hit that endpoint. The final report must say what ran, what behavior it exercised, what remains untested, and which risks remain. “Tests passed” is a status. The report tells me what the status means, and I can find if there are any missing tests.
I’ve saved so much time lately by letting an agent create a test plan, reviewing it, and then letting the agent run the requests, mint credentials, and write a report with the results.
The same loops continue outside the repository. My agents prepare code-review reports, check whether previous comments were addressed, update ticket states, detect new document comments, and remind reviewers if they ignored my code for a while.
I still approve of myself sensitive communication, production changes, and architecture decisions. But in many use cases, both my team and I prefer that an AI does some work rather than waiting for me to do it.
Conclusion: Build one workflow that improves itself
It’s crazy to think where we were 1 year ago. Just one year ago, I worked in an older version of a ring device. I was writing prompts in a web chatbot, copying the generated code into my IDE and running the build commands myself. I was the engineer.
Now I’m working on the next version of this same device, and I’m not writing code; I’m not running the commands. I’m an orchestrator of agents implementing. I’m not the manager of a single engineering team
If we keep going in this direction, in one year I’ll be my skip-level manager, managing multiple teams at the same time (which you can do already if you work on multiple projects). Then one year after a director of software engineering, owning a critical piece like the entire backend of a company.
Models will change. Editors will change. The durable system is the one that is tool-agnostic and evolves as the capabilities of frontier models and tools to add to our harnesses get better
Start small and keep getting these small wins.
If you found value in this post:
❤️ Click the heart to help others find it.
✉️ Subscribe to get the next one in your inbox.
💬 Leave a comment with your biggest takeaway
♻️ Share it with your peers
Today’s article will allow you to move faster through the phases of our system to become productive engineers and get promoted faster
I’m building this system below for paid subscribers. Thanks for your continued support!
🗞️ Other articles people like
If you want to improve the decision-making stage before an agent writes code, read this next.
Don’t Start Coding Yet: Here’s What Great Engineers Do First
·Get the free AI Agent Building Blocks ebook when you subscribe:
