As I have been learning and building with AI, most of my discoveries and improvements have been around the concept of solo developer + agent.
Recently I had the opportunity to work with a small team on a new build and brought the approach that works for me to the team. While my flow worked, it blocked the team for too long and wasted precious time that my teammates could have spent building more meaningfully.
Here I want to explore the approach that works well for me solo and what I think changes when you apply that same approach to a team on a greenfield build.
I am not presenting this as the correct workflow. This is more an exploration of a failure mode I hit, the tradeoff I now see more clearly, and the experiment I would run differently next time.
Note: You will notice reading this that I do not share the specific build. This project was for a CodeTV episode that has not yet been released. I will update this once it is out.
How I build
When I start a new project with an agent, currently my focus is spending most of the time writing out a plan for the agent to follow up front. Something that gets me to a working application within the boundaries I set that I can then refine.
In essence I create a detailed plan across a few files for the agent to follow: a spec, a runbook, and a checklist, with an AGENTS.md that functions more as the high level order and file map. It covers scope, architecture, features, tech choices, and what is out of scope.
The goal is simple. Give the agent enough structure to move with confidence and produce a coherent first pass.
What happened when I applied this to a team
Naturally I brought this approach to my team with the theory that we could give the agent our requirements, have it spin us up a working starting point, and then divide and iterate from there.
We had a 6 hour build time and this felt like a good way to get the boring scaffolding out of the way so we could all apply our expertise and creativity where it mattered.
As a team we briefly reviewed the spec docs to make sure we agreed on the decisions and I gave it to the agent to build. In this case I used Codex 5.4.
Did it work? Sort of.
The result was a fully working baseline. It wasn't pretty but, it met the requirements and the logical flows needed very little refining. We only replaced one technical decision, not the agent's fault in this case, but one area where we needed to change direction. At this point my team focused on UI/UX and adding some creative flows.
The problem was that the first pass took over an hour and for a 6 hour build that meant the rest of the team was effectively blocked for a meaningful portion of the project timeline.
This is what failed. The agent produced good work, the spec was fine but the artifact created was too complete when we could have moved with a more minimal scaffold.
By the time we had the baseline we had lost too much of the build window for refinement, UI/UX creativity, and the kind of decisions we need humans to be able to make early.
Why this breaks in a team setting
As a solo developer, a highly complete first pass is often useful. You are optimizing for coherence and momentum.
On a team build especialy with a compressed timeline that same instinct can backfire.
What I didn't consider is that the first artifact does not just need to work or be super complete, it simply needed to give other people something stable to build against immediately.
A strong spec and a strong team start are not the same thing.
What I would try next time
If that first pass had taken 5 to 10 minutes, I would probably still think this was a great workflow.
But once the first pass starts taking a meaningful chunk of the total project time, the question changes:
What should an agent build first so the rest of the team can start contributing right away?
For a short build, I do not think the answer is "the whole MVP."
I think it is something closer to a shared scaffold that gives the team a coordination surface after the first agent pass.
This could include:
- app shell
- route structure
- shared types
- schema or model shapes
- API contracts
- page shells
- placeholder states
- mocked data
Jusr enough structure that people can work without inventing their own versions of the system. As we've all seen, an agent given the same instructions can produce different results.
Instead of this
Team writes spec
- one agent builds the full working MVP
- everyone else waits or does non-code tasks
- team reviews and divides the remaining work
Perhaps it looks like this
Team writes spec
- one agent builds the minimum scaffold
- team splits work immediately
- one stream pushes logic, one stream pushes UI/UX
In a little more detail, the division of work becomes:
- one agent generates the shared scaffold
- one human + agent builds the core interaction flow against mocked data
- one human + agent works UI/UX and page feel
- one human + agent focuses on integration edges like auth, persistence, and deployment
In our case the point of failure was that the first pass already included things like fully written API routes, test suites, authentication, notifications, and almost every requirement needed for the final product.
All examples of things that should have come later.
What I took away from it
I had spent so much time optimizing as a solo developer that I did not have the right mental model for a team build.
For a short build like ours, my thinking has definitely changed.
The first generated artifact should optimize for parallel human contribution, not maximum autonomous completeness.
That sounds obvious in hindsight, but it does not always feel obvious when you are staring at a capable model and a good spec and thinking "why not just have it build the whole thing now?"
Final thoughts
I do not think I have the perfect answer for what workflow is best in every scenario.
There will be projects where one developer plus agents gets to a strong MVP so quickly that bringing the rest of the team in later is the right move.
There will also be projects where everyone should start moving early, but against minimal shared artifacts like types and page shells instead of a full application.
What I am convinced of after this experience is that this should be a deliberate choice based on the constraints of the team, the project, and the shared goals you have.
Just because your agent can build the whole working application does not mean that is the best place to start.
A better question to ask might be...
What is the smallest useful thing we should generate first so that nobody spends the best part of the build waiting?
Top comments (2)
a really good lesson! everyone is trying to figure out what AI workflows work for THEM and very few are considering how that workflow holds up in team settings.
also makes you wonder how much of software development will continue being a team sport, in a relay race kinda way. honestly, if you and your agent built an MVP in 1 hour with 5 hours left to refine, is that an argument that you didnt need more than one person on the team? 🤔 things that make you go hmmm
Very true! I went back and forth on this as well. Is the issue building a flow for teams or changing the idea even further to where a solo dev + agent is the correct first pass only bringing in more humans as needed for specific expertise.
I'm sure as always, it depends.