A Genuinely New Way of Building. Not an Evolution of the Old.

This isn't the next version of how software gets made. It's a different model wearing the same name. The temptation is to call it agency-with-AI, agile-with-AI, modernized dev practice. Each of those names keeps the old model intact and adds tools on top. None of them describes what's actually happening.

A prospective client described us, accurately, in language that didn't fit. "So you're like an agency, but with AI?" He wasn't being dismissive. He was trying to map us onto something familiar. We'd just spent an hour walking him through how a real engagement runs. The artifacts we share. The way his expertise stays in the build. The cadence of working alongside agents in the same room as our team. He understood every piece individually. He couldn't quite hold the whole thing in his head, because the available shape for it in his head was "agency."

That's the moment the new way of working becomes visible: when the available vocabulary fails to describe it.

This is the last post in the manifesto series. The first one was about the biggest shift in human creativity happening now. This one is the answer to the question that's been implicit underneath all of them: is the shift big enough to actually require a new way of working, or is it the same way of working with better tools?

We think it's the first one. Here's why.

What does "evolution of the old way" actually mean?

There's a polite version of the AI-in-software story that goes like this. Developers are getting more productive. Tools are getting better. The same teams build the same products faster. It's an evolution. It will compound. Be patient and steady.

That story isn't false. It's also not what's happening at the most important level.

The polite story keeps the model intact. There's still a team that builds. There's still a client who briefs the team. There's still a handoff. Every role in the old model survives, with AI added to it. The org chart is the same. The artifacts are similar. The vocabulary works.

What we've watched happen, across hundreds of engagements, is a different thing. The roles aren't being made more efficient. They're being restructured. The role of "client" used to mean someone who described what they wanted and waited. Now it means someone who's in the room shaping the product as it takes shape. We wrote about why in clients are co-creators. The role of "team" used to mean the people who built. Now it means the people who shape how the collaboration runs, with the building distributed across humans and agents. The role of "tool" used to mean something you operated. Now there's a category of participant that isn't quite a tool and isn't quite a person, and pretending it's the former is what produces the worst version of working with AI.

When the roles change this much, the model has changed. Calling it an evolution gives people permission to keep working the way they've always worked and add some AI to it. That's the most common way the shift gets missed, and we've watched it miss in real time on a lot of teams.

What is structurally different about how we build now?

A few specific shifts, named plainly.

The domain expert is in the build continuously. Not as an interview subject. Not as a stakeholder who approves milestones. The expert is in the room as software takes shape, applying judgment in the moments where it matters. The structure of an engagement is built around this. We described why this matters in the closest to the problem should be closest to the build and what it looks like in practice in the expertise pillar.

Humans and AI agents collaborate as peers, not as operators and tools. The language is precise. Treating agents as collaborators changes what you optimize for, which changes the work itself. The pillar on this goes deeper. The practical version is that the team makes different decisions when it thinks of agents as part of the team.

Three layers of collaboration run at the same time. Human-to-human conversation about what to build. Human-to-agent collaboration on how to make it real. Agent-to-agent orchestration handling the work agents do best. The mistake is running these as phases. The advantage is running them as layers. We dedicated a whole pillar to this because it's where most teams get it wrong.

Aim matters more than speed. The amplification of AI cuts both ways. Right direction or wrong, it gets there faster. The premium on clear intent went up the moment the cost of building went down. We argued this in the amplification pillar. The teams that win this era are deliberate about what they're building, not maximally fast at building.

The methodology gets learned, not declared. This is the move that signals whether a team is actually in the new model. The new model is too new to be theorized in advance. The teams doing it well are also the teams figuring out how to do it well. The pillar on this is about the posture, not the practices.

None of these is a tweak. Each of them is a structural change to who participates and how. Together they describe a model that doesn't map cleanly onto agency, consultancy, dev shop, freelance, or any other label that was working two years ago. That's the signal that the shift is real.

What does the new model actually produce that the old couldn't?

A fair question, and the one prospects ask most often. If this is genuinely new, what does it produce that the old way couldn't?

Software that reflects the domain expert's knowledge more fully than the expert could have produced on their own, and more accurately than any team without them in the work could have produced. The Civitas immigration platform was an early case in point. A Yale student with limited technical background, working with our team for eight hours of collaborative discovery, ended up with a deployed application running real workflows. The old model would have given him a quote for $150,000 and six months. The version that would have come back at the end of six months would have reflected six months of degraded translation of his original intent. The version that came back at the end of one day reflected his intent directly, because he was in the work the whole time.

Speed is a byproduct of that. Quality is a byproduct of that. The point isn't either. The point is that software finally reflects the person closest to the problem, because they were finally close enough to the build to shape it directly.

The old model can produce decent software faster than it used to, with AI tools added to it. We don't dispute that. The new model produces software the old model couldn't produce at all, which is a different claim and a different competitive position.

Why does naming this matter?

Because the words people reach for shape what they do.

A team that thinks of itself as "an agency with AI" will run engagements like an agency, with a brief, a build, and a review. They'll get faster at the same shape of work. They won't get a different shape of work, and the clients who needed a different shape will go to teams that figured out how to provide it.

A team that calls what we do "agile with AI" will run sprints, hold retros, and call it modernized. They'll improve at the existing practice. They won't notice the practice has changed underneath them, and the gap between their work and the work being done by teams that did notice will widen quietly for two years before it becomes obvious.

We've watched both versions play out. Naming this as a genuinely new way of working isn't about us. It's about giving anyone who's in this work the right vocabulary to do it well. The word evolution is a comfortable word. It implies continuity. It lets people keep their current practice and call it updated. That's exactly the move that loses you the era.

We call it Human + Agentic Collaboration. It's how we build now. We didn't theorize it. We learned it by doing. It's still evolving in real time, and that's a feature, not a problem.

Not an evolution of the old way of working. A genuinely new way of building together.

That's the manifesto. The work follows from it.