We’ve started a handful of greenfield projects over the last few months, all of them built with AI from the ground up. And the first thing that changed wasn’t the speed, it was the shape of the team. It’s smaller now, two people where we’d once have staffed five, and each person covers a lot more of the delivery than they used to. The same developer holds the architecture, builds it full-stack, and carries enough business understanding to know what the client actually needs. Fewer specialists handing work between them, more generalists who each own a deliverable outright, sitting close and talking often.
The way we run those projects has drifted just as far, fewer calls and barely any ceremonies. But the more meaningful shift is structural. The unit of work a developer commits to moved up a level, and the detailed planning moved from before the work into the middle of it. That quietly rearranges most of what our project management used to focus on.
One developer now owns the whole screen
A senior full-stack developer can now sit down in the morning and commit to having an entire screen finished by the end of the day: the data model behind it, the API endpoints, the UI, and the automated tests that keep it working. The commitment is to finish it, not just to start.
A year ago that same screen was a whole feature story. We’d refine it together, split it along the seams of the system (someone takes the endpoint, someone takes the table, someone takes the frontend), and hand the pieces out. We broke it down because no single person could carry the whole thing inside a day, so we cut it into parts small enough to schedule and pass around.
The ticket didn’t get faster, it got denser. A single developer-day now holds what we used to break into five subtasks across a few people.
AI absorbed the layer underneath. The SQL, the endpoint wiring, the boilerplate, the test scaffolding: all the stuff we used to decompose a story into is now the cheap part. It gets done in the same sitting as the thing it supports, so the sensible size of a ticket rose to match it. What we track now looks a lot more like a product deliverable than an engineering task, and one person owns it end to end instead of assembling it from parts owned by five.
Detailed planning stopped happening before the work
The old rhythm put planning first. You’d refine a story, argue out the approach, write the acceptance criteria, and only then would anyone open an editor. The plan was the contract, and the build was that plan carried out.
That order has flipped, as now we talk about the product and the deliverable first: what this screen is for, what the customer will do with it. Then someone builds, and the plan firms up as the build shows us what the work really is. Planning didn’t disappear, the high-level product thinking still comes first. What moved is the detail: the cheapest place to work out the breakdown is now during the build, not before it. You prompt your way through an approach, and the model surfaces a decision you didn’t see coming (do this other thing first, then circle back).
The real shape of the work only shows up in the doing. Trying to pin all of that down upfront in a perfect spec is slower, and less accurate, than just building a version and adjusting.
One of our developers put it plainly, from the management side. He wants one product story, defined well from the product side, and that’s the commitment he’s willing to make. He doesn’t want to spell out the ten subtasks underneath it in advance, and we agreed he shouldn’t. A breakdown written before the build is mostly guesswork, and the build outdates it within the day. The planning and the implementation have fused together, and prying them back apart just to produce a pre-agreed spec is busywork.
Splitting the work costs more than it saves
Here’s the part that’s easy to gloss over. Everything above makes a single capable person dramatically faster, but it doesn’t mean five of them ship five times as much. If anything, splitting one deliverable across two people now often costs more than just keeping it with one.
To hand a slice of work to someone else, you need a clean seam between planning and implementation: a spec complete enough that another person can build against it without you. But the speed of the AI-first flow comes from fusing those two together. Pull them apart to parallelize, and you’re back to writing the exact upfront spec that AI let you skip. Then you hand it to someone who waits to be told what to do, instead of finding it in the build. You pay the old coordination tax right back, and get a more passive builder for it.
It’s worst at the start of a project. When each person owns a whole screen, you’ve got two people making big changes at once. And there’s no solid core yet, no firm boundaries to keep them apart. Everything still touches everything, so the blast radius is high and their changes collide. Once the architecture settles and the seams harden, parallel work gets safer. Early on, a second person mostly just creates conflicts to untangle.
Guardrails help, but only so far. We keep architectural oversight on the core decisions, and we lean on spec-driven development to hold the boundaries in check. Even then, the detail is where it bites: when each person’s PR solves its problem locally, inside its own module, the same logic ends up built in three places when it belonged in the core. Keeping that DRY across parallel work is troublesome.
Smaller teams drift toward Kanban on their own
So the teams got smaller - not in spite of the speed, but because of it. One or two people on a project is the comfortable default now, and the developers themselves push in that direction.
“Fewer calls, drop the rituals, shorten the loop, let me just talk to the one other person on this build directly when something comes up.”
Below a certain size, all that coordination machinery is pure overhead. The whole point of process was to tame the entropy of a large group, and a group of two doesn’t have much of it to tame. So the pull is toward Kanban: short cycles, continuous flow, very little ceremony.
The risk sits at the far end of that pull. Kanban with no committed horizon slides very easily into a black box, where work is happening and the developer is heads-down, but nobody outside can say where it stands or when it’ll land. That’s the exact thing we spent two decades building process to avoid, and moving fast isn’t a good reason to walk back into it.
The layer that survived is the product layer
If that’s the risk, what’s actually left to steer? A product backlog and an engineering breakdown were always two different things. The product layer (this screen, this flow, a checkout here) changes slowly and stays readable. The breakdown beneath it, the part that always bloated the board, is exactly what AI now handles inside the build. So what’s left to manage is the product layer, which was always the part that stayed manageable anyway. That’s why this doesn’t feel like project management getting harder. It gets narrower, and clearer: you steer what the client wants and whether it’s landing, not how the work breaks down under it.
It also moves the scarce skill. The bottleneck isn’t the person who can slice a story into schedulable parts anymore. It’s the person who can shape the deliverable from the product side, which is a lot closer to a product owner than a project manager. The administrative half of the old role, tracking and distributing all those parts, is most of what AI took off our hands.
Predictable delivery still needs an owner
A couple of things didn’t change at all, and the speed only raises the stakes on them.
The client still needs a commitment they can rely on. You can drop the word “sprint” and you can drop the ceremonies, but you can’t drop the predictable interval that someone owns: a window where the team commits to what’ll be done, ends it with something the client can actually see, and takes responsibility for the gap when it misses. The value of a sprint was never the ritual, it was the predictability and the reflection it forced. That survives AI completely intact. A client can’t hear “it’ll be done when it’s done” from us any more happily than we’d hear it from a contractor redoing our kitchen.
You delegate responsibility for an outcome, not a decomposed list of tasks. The list is the cheap part now. Owning the result is the actual job.
And someone still has to hold the product clearly enough to define the deliverable and judge whether it landed. That was always the hard part. AI stripped away the busywork that used to disguise how hard it is. There’s less to manage now, but what’s left is the part that was never really administrative in the first place.
One caveat before you run with any of this: we’ve only worked this way for a few months. Take it as a field report, not a finished method. A lot of teams are pushing the same pace right now, and I’d expect the playbook to look different a year from now.