I’ve been using coding agents for a year and for the better part of it I haven’t written code by hand. I’ve seen a small bump in my speed and productivity but turns out I was using it wrong.

Delegating only the implementation

The way I was using it was close to the way I’ve been working all these years:

1. I start thinking about the action plan and write it to the agent in every detail
2. I ask the agent to execute it
3. I review its job just to make sure that it followed the steps exactly
4. Finally I open a PR and ask from a peer to review the code as well

Step (2) is the difference with before and it is the single point that gave me that bump. It is obvious that I wasn’t leveraging the power of agents enough and that puzzled me as to why? Why wasn’t I able to trust the agent more? Turns out it is because I remain a “Buildgineer”!

Buildgineer

I heard the term in this presentation where the speaker was explaining that in all other engineering fields, the engineering of a project and the building of it are obviously two separate things. The example that he shares is the one of the golden gate bridge. Many people helped into building it but none of them was the engineer. The engineer was at his office, 2000 miles away. His job was to make the design, to create the plans that will prove the bridge will hold, to set the processes for maintenance etc.

Software engineers on the other hand have been mixing the two aspects from the beginning. It is hard to separate them and to trust that an agent will do the building as we would.

Trusting the agent

So the goal was to reduce my evolvement while trusting that the agent will deliver what we want by maintaining the quality and conventions we have. In other words the previous steps become:

1. I think about the action plan but write nothing about the implementation
2. I ask the agent to execute it and to provide a proof of its work
3. I ask another agent to review the code based on our rules

For step (1) it is important to have a variety of skills in the project. Skills that will guide the agent to create something as you would, skills that will help the agent reason about an ambiguity just like you would, skills that will allow the agent to find the proper tools just like you would! Skills, skills, skills!
This allows the engineer to provide a simpler plan that describes what needs to be done and contains trigger words for skill discovery.

For step (2) it is important to have a rule in your claude/agents md file that forces the agent to create the proof. Depending on the change the proof will vary from a simple test to a video showcasing the feature.

For step (3) it is important to have a separate agent to do the reviewing by forcing a set of rules that help the project maintain its standards.
Tip: one thing that worked great into creating this set was to point the agent to the on-boarding guide we have. A guide that explains through examples the architecture, our conventions, the way we approach a few things. That led into a first draft that was 90% ready for use.

-50% from start to finish

I admit this -50% might not be that accurate but I feel that the truth is close to it. We adopted this way of working at the android team I work at and the numbers were quite promising.

In particular, this past week the PRs that opened and closed in the same week were 18 when the previous two weeks they were 13 and 15 respectively. Even better, the median time-to-merge was reduced 93%, from 30h to 1.88h.

I know that it is too early to draw conclusions but it is a good start especially if we take under consideration that this week the majority of the devs that adopted the POW-workflow were mostly the seniors in out team.

Moving forward

So what will we do from now on? Are we simple prompters? I say no.

We are engineers and we have to make sure that:

• we provide a solid plan
• we have laid out the rails on which the agents will work
• we created the proper feedback loops that keep the agent working as we want

That never ends, it needs constant evolvement and maintenance.