Working on the market project with a teammate comes down to a shift schedule. I have time in the morning until midday, he takes the afternoon and evening, and a coding agent does the typing in between.
This post is about how that held up, and where I think it would crack.
Splitting the Work#
At first we split tickets by availability: whoever had time started the agent on the next ticket. That worked fine for the MVP. Once we moved on to refining features, we wrote an individual spec per feature and told each agent what was being worked on in the other branches, so the spec could be shaped to stay out of the other’s way.
The course calls this kind of thing a guardrail: you limit which parts of the code an agent may touch, so parallel work doesn’t collide. Ours is a soft one. It depends on the agent respecting it and on me describing the other branches correctly.
The One Conflict#
In practice we had almost none. The one real conflict came from the email feature, which needed stallholder info, while the agent working on it named a few variables differently from the rest. The two features were otherwise separate, so it was small. We let the agent run a merge-conflict skill and moved on.
That’s fine while the conflicts stay small. Parallel work clashes where it shares something, and an agent can resolve the text of a conflict cleanly while still getting the meaning wrong. The tests are what tell me whether the merge actually holds together.
Nobody Reads the Code#
Merging is also done with a skill, and neither of us reads the code. As long as the tests are sound, reading every line seems redundant. I still think that’s a defensible position for an MVP, and it’s also the weakest spot in the setup, so I’d rather say it myself.
Tests only cover what someone thought to test, and when the agent writes the tests too, a misread spec can end up in both the code and the tests with everything green. Security holes, GDPR slips and code that works but is painful to change are things tests rarely catch, and this app handles real stallholder data.
Everything we rely on is a soft guardrail: specs, branch notes, tests run locally. The course points to hard ones, like CI on pull requests, branch protection on main and CODEOWNERS on sensitive paths. We have none of them. For production there’s too much black box in there for my taste.
If this were going live, the first thing I’d check is that personal data is safe, then the admin login and the protection of the REST endpoints. That part leans on libraries, because writing your own JWT or CSRF handling is far too risky. But “a library handles it” is not the same as “it’s set up safely”, and that’s a check I’d want to do myself.
What the Agent Hands Back#
Every ticket is closed with a commit message that says which files changed, what was done, and, just as importantly, what wasn’t done, in case something needs refining later. When something needs a human, the agent is told to create a sub-issue labeled for human review instead of guessing.
That paid off on a bookkeeping issue. The agent wasn’t sure how much should happen automatically, so it built the input fields and the saving of data and stopped there. Things like VAT and what’s needed to apply it had earlier been left to the agent to handle, but it made a separate ticket instead. That’s the right call. A confident guess about VAT is worse than no answer.
The agent can only flag what it knows it’s unsure about, though. The silent assumptions, where it designs something because I forgot to say, won’t show up as a flag. That’s still on the spec and on me.
Between us, the plan for who does what goes over text, and the specs and tickets are open for the other person to read before starting work.
What I’d Change#
Only the first spec was partly written by both of us, because of time constraints and real life. Thinking of extreme programming, where one person drives and the other navigates, the agent is effectively the driver, so we could have been two navigators during the spec. Two people catch different assumptions, and that’s the cheapest place to catch them.
It’s easier said than done in a school project where we aren’t together every day. Having the other person review the spec asynchronously is an option, but then the review becomes a bottleneck: you either can’t get work done while waiting, or you need to be on the same schedule. Usage limits make that tighter still.
Wrap Up#
Being the one who directs the agent is not the same as the code being secure. When an agent does it all, someone still has to decide which parts of the code are worth a human’s attention, and for us those are the personal data and the login.