How I run development with a coding agent

In short. I use a coding agent to investigate, implement and check changes, while I review the proposal and accept the result. In one completed change, the agent’s device check exposed consent selections being cleared. I chose the system browser, and the agent verified that returning preserved the selections without weakening the consent requirement. Seven months of logs show how the workflow developed. I would next test it with a team.

I decide the direction before the agent changes the code

In March I started using Claude Code every day while working alone on a product with a mobile app, a web dashboard and a backend. By October my logs held 867 sessions across my projects on two machines. I analysed them through 29 October to see which parts of my intended process appeared in the work. The work itself had changed gradually, whenever repeating an explanation or checking an assumption became enough of a problem to fix.

The first problem was context. Decisions were scattered across conversations and documents, and the agent would start a new session without knowing why something had been built that way. I gave it a searchable knowledge base and an instruction to consult it before changing code. I also made the trust boundary explicit: a note can describe an old decision or contain an old mistake, so the agent has to check it against the current code.

A composite example shows the process better than the list of tools. Suppose a field on a form becomes required for one category of trip. The agent searches the notes and finds both the form’s design and an older note saying the field does not exist. It checks the code, finds the field as a dropdown and treats the older note as wrong. That check matters before implementation: otherwise a plausible explanation in the notes can become the basis for the wrong change.

The agent then proposes the validation rule, the affected categories, the error message, the matching server validation and the implementation tasks. I read the proposal before code changes begin. That is where I check the intended behaviour and the boundaries of the change, while a mismatch can still be fixed in a sentence. The agent handles investigation and implementation, while I review the direction it is about to take.

From August, I began recording change proposals in specifications under version control. When I later read the logs, I found that planning before editing had already been happening since March. The change was the document: a proposal I could review and retain after implementation. It gives a later reviewer somewhere to start when asking what the change was meant to do. I wrote about the knowledge layer separately in How I stopped re-explaining the project to every AI agent.

Acceptance includes the running product

Once I have read the proposal, the agent edits the code and runs the tests. For the form example, the next check is to open the app, try the invalid case, inspect the error, then try the valid case. If the change affects the dashboard, it checks the record there too. The agent runs the emulator checks and operates a physical phone for checks that need it.

Passing tests is one piece of the acceptance decision. The product check asks whether the changed behaviour is visible and usable in the actual interface. If that check finds a problem, the work goes back to the code. I remain responsible for accepting the result, and the agent performs the checks and brings back what happened.

In one completed change, I added document links to a consent screen. The first implementation opened them inside the app. During the agent’s device pass, the registration guard sent the user back to the unfinished registration step, which caused the screen to remount and clear the checked boxes. I chose the system browser instead of relaxing that guard. The agent then checked on the emulator that the document opened, returning preserved the selection, a link tap did not toggle the checkbox, and submitting without consent still showed the error. The agent repeated the relevant checks on a physical phone. The completed change let users read the document and return with their selection intact, while keeping the consent requirement in place.

The intended record includes the proposal, test output, screenshots and a ticket comment explaining what was verified. When something surprising turns up, a note can carry it into the next session. Those are useful materials for another engineer reviewing the work.

I also changed how I use extra agents. Early on I sent them to read code for the main session. More focused code-navigation tools took over that work, and I kept a separate agent for reviewing a diff without the history of the conversation that produced it. I want that reviewer to inspect the change without inheriting the main agent’s explanation of why it must be right.

The logs show which checks became more common

I counted actions and their order in the session transcripts. The graph follows two parts of the process: searching the notes before the first code edit, and checking the running product after a test command. The search tool first appears in June, and browser checks first appear in July.

Checks recorded in agent sessions

Share of all sessions, March–October 2026

• Knowledge-base search before the first edit
• Product check after a test command

Data

Month	Knowledge-base search before the first edit	Product check after a test command	n
Mar 2026	0.0%	0.0%	55
Apr 2026	0.0%	0.0%	70
May 2026	0.0%	0.0%	168
Jun 2026	16.5%	0.0%	194
Jul 2026	43.9%	2.3%	132
Aug 2026	53.6%	18.2%	110
Sep 2026	55.7%	29.5%	88
Oct 2026	58.0%	34.0%	50

In October, through the 29th, a knowledge-base search before the first code edit appeared in 29 of 50 sessions (58%). Across the broader window from 14 September to 29 October, it appeared in 60 of 111 sessions (54%), while a product check after a test appeared in 30%. The graph shows the monthly trend.

The logs record actions and their order. They do not establish the quality of each result, and I have not yet linked sessions by shipped change to check whether the complete verification record exists for each one.

The methodology contains the definitions, detailed measurements and token figures. I cannot yet calculate a monetary cost per completed change because the work is not linked across sessions.

The search worked while one of its components was broken

The knowledge base has a second model that ranks search candidates and trims the result list. That component failed for two months without stopping search. Results still came back, and the health check stayed green.

I found the failure in the audit log. The ranking configuration had been stored in a file while the relevant code read from the database. It fell back to a hosted service I had no key for. The first search stage continued to run, but the second stage could not rank and trim its results. Correcting the setting took one command, but noticing the failure took much longer.

For this component, a successful response and a green health check had failed to expose the problem. I needed to inspect what the search returned and whether its ranking stage actually ran. The response-size chart is in the methodology, alongside the measurements behind it.

This is maintenance work I took on by adding the layer. Permission prompts still interrupt runs, device automation still needs supervision, and the code graph remains a trial whose additional value I have not established. Each addition gives me another component to keep working and another reason to check whether I still need it.

In a team, I would start with shared checkpoints and named owners

I have used this setup alone. The following is how I would try it with a team, rather than a description of a rollout I have already done.

I would start with a small change and agree on the checkpoints: what belongs in a proposal, who reviews it before implementation, which checks the change needs and who accepts the result. Shared instructions and specification templates would carry those decisions into the agent’s sessions. A new engineer would have written expectations to inspect and challenge.

I would put the proposal and verification record beside the change in the review process, with links back to the ticket. My first test would be whether another engineer could follow what was requested, what was agreed and what was checked. Connecting those records would also let us measure coverage by change, instead of trying to infer it from session sequences.

Each supporting component would need an owner and a way to check its actual work. For retrieval, I would include inspecting returned results and checking that ranking runs. The reranker incident is the reason I would make that responsibility explicit. The team would also need to decide which tool problems should stop work and which have an acceptable fallback.

Before expanding the setup, I would review the trial against three criteria:

• Another engineer can take an agreed change through the process without my continuous involvement.
• A reviewer can reconstruct the expected behaviour and completed checks from the change’s records.
• The team can account for the effort spent maintaining the tools, accepts that effort and knows who owns each component.

I would use the results to decide with the team whether to continue, simplify or stop the experiment after trying it on an actual change.

If your team is working out where to put these checkpoints, I would like to hear what you keep with a change and who owns the tools. LinkedIn is where I am easiest to reach.