The Engestofte project is moving along well. In the previous post, I described how my teammate and I planned to divide the work across the API, Web, and CMS. Now we’re doing it, and working in parallel has been going better than I expected.
This week’s topic was collaborative agentic development: several people and AI agents contributing to the same project. For us, the useful question is how to keep that work aligned while several tickets are moving at once.
We do the grilling together#
For a large implementation, we both take part in the grilling before the agent starts writing code. We’re using Matt Pocock’s workflow to work through the feature, settle the decisions, and turn them into a spec and tickets.
Having both of us there matters. We can hear the same questions, challenge the same assumptions, and agree on what the feature should do. If one of us expects something different, that is the time to find out. It is much easier to change the plan during the conversation than after both sides have been implemented.
The agent writes down the new feature slice as we work through it. That gives us a shared reference when we split up again: what we decided, what each ticket covers, and what depends on something else being finished first.
The writing helps, but the conversation is doing a lot of the work. We both need to understand the feature well enough to notice when an implementation starts heading somewhere we didn’t agree on.
Several tickets can move at once#
We can’t build everything in a single queue and still reach a useful demo. Several tickets need to run in parallel, across our own work and the agents helping us implement it.
The module boundaries make that manageable. We can move different parts forward without constantly touching the same files. Where the modules meet, we need an agreed contract and a clear understanding of the dependency. A frontend ticket can only move so far if the backend behaviour it needs is still undecided.
Good communication is what keeps this working. We need to tell each other what we’re working on, what has changed, and what the other person needs to do after pulling the latest code. The agent has the context we give it; it doesn’t replace that conversation between us.
So far, the combination has worked well: decide the larger feature together, write it down, then implement the parts in parallel.
The friction has been small#
We had one small merge conflict while working on two large features over two or three days. It was in CSS. That was encouraging: several days of parallel implementation came together with only a small overlap to resolve.
It also showed where module boundaries stop helping. Two features can be separate in their behaviour and still touch the same styling. Shared files remain shared files, however neatly the tickets are divided.
The other small issues involved local database updates. New seed scripts had been added, and the other developer needed to run the project’s seed command, using npm or pnpm, to bring their local data up to date.
Pulling the code wasn’t the whole update. The local database needed attention too. That’s a useful detail to include in the handover: if a feature requires new seed data, say so when sharing the change. It saves the other person time wondering why something works on one machine and looks incomplete on theirs.
What is working for us#
The progress so far makes me more confident about the way we’re building. Shared grilling gives us a chance to agree before the work branches out. Specs and tickets carry those decisions into implementation. Module boundaries give us room to work in parallel, and regular communication keeps the pieces connected.
There is still a demo to put together. The test will be whether the features we’ve developed separately work as one application Johan can use. But so far, collaborating with each other and the agents has felt practical, and the small integration issues have been manageable.
This is part eight of my posts on this semester’s AI-driven applications elective.