Fewer Developers, More Builders (Part 4): When Speed Creates Friction

The first three parts of this series documented our shift from different vantage points. Why we started AI-first. What the first week actually felt like. How a UI designer went from mockups to a working product in days.

I am the tech lead on this project. My vantage point is a little different. I am not watching one feature come together — I am watching the whole team move, and looking for the places where we move against each other.

That is where this part of the story begins.

When Parallel Agents Work Against Each Other

Multiple developers. Multiple AI agents. All moving fast, all in the same codebase.

In the first iteration, I built an approval flow integrated with Power Automate. It was functional — what remained was a configuration adjustment on the Power Automate side. Clean handoff, work in progress. When the second iteration began, one of the developers had a different vision for how that integration should be structured. Their agent rewrote the function. Mine disappeared. The delivery was affected, and I had to revert my own work to get the project back on track.

No one was careless. The developer had good intentions. The agent followed instructions correctly. What was missing was a shared understanding of what already existed, why it was built that way, and what should not be touched.

This is what speed exposes when it scales. The AI did not cause the conflict. The lack of coordination did. And AI made it happen faster.

Rules Are the Memory the Team Shares with the Agent

This is when I stopped treating Cursor rules as a nice-to-have and started treating them as infrastructure.

We wrote rules that encoded our architectural decisions, naming conventions, and integration boundaries. The rules told the agent what patterns were in use, which functions were established, and what the expected behavior was in specific parts of the system. In practice, the rules became the shared context that no one was maintaining before.

The difference was immediate. Agents stopped proposing solutions that contradicted existing patterns. Developers had a common reference point. When something was out of alignment, it surfaced at the rule level before it reached the codebase.

If I had to name the single most impactful change across both iterations, it would be this: making rules explicit. Not just for the AI — for the team.

Prompting Is Thinking, Not Typing

Something else shifted between the first and second iteration. My prompting style changed.

Early on, I was giving instructions. “Generate this function in this way. Refactor this module in that way. Fix this bug.” The agent delivered. But the results were often technically correct and directionally narrow — useful for the task, not for the system.

I started prompting differently. Instead of asking for execution, I asked for reasoning. Given this integration pattern and these constraints, what would you recommend and why? The responses became more considered. Trade-offs appeared. Edge cases surfaced. The agent stopped feeling like a script runner and started feeling like a collaborator worth questioning.

Prompting is not a communication shortcut. It is a thinking skill. The quality of what you ask reflects how clearly you understand the problem. If your understanding is shallow, the agent will produce something fast and shallow. If your understanding is deep, the agent will meet you there.

That clarity is not a technical skill. It is a judgment skill.

Engineering Fundamentals Did Not Go Away — They Went Up

The longer we operate this way, the clearer it becomes: AI handles execution, not direction.

Knowing the flow matters more than I expected. If a developer does not have a clear picture of how data moves through the system — where state lives, what depends on what — the agent will still produce code. But that code will produce surprises. Sometimes bugs that are hard to trace because neither the developer nor the agent realized something was missing in the design.

We also saw that the longer we stayed in AI-assisted development, the more issues accumulated if the foundational thinking was loose. The AI will take you 80% of the way fast. The remaining 20% still belongs entirely to the human: catching what the agent missed, evaluating whether the architecture will hold, and making the call that no amount of prompting can substitute.

What’s next?

We are entering our third iteration. The speed question is settled — we know it is real. The question now is reliability. How do we keep parallel agents aligned without creating bottlenecks? How do we build systems that last beyond the sprint that created them?

AI gives us speed. Rules give us stability. Human judgment gives us direction.

The builder mindset is not less engineering. It is engineering at a higher level. And the higher you go, the more the fundamentals matter.