I have always thought the real job of a developer was understanding a problem well enough to solve the right one. The code was how you got there, not the reason you were there. For most of my career the work was organized as if the opposite were true: you were handed a well-scoped task, you wrote the code for it, and that task was treated as the unit, the place the skill lived and where you proved you were good. I never believed it. I spent my whole career working my way toward the customer and the actual problem, pushing out from under context-free tasks, because I wanted to build things that meant something instead of executing someone else's abstraction of them.
That role has finally become the whole job. The well-scoped task, the bounded and specifiable thing, is now the first thing I hand to an agent. And the industry has broadly noticed. Ask anyone serious what a developer does in the agent era and you get some version of the same answer: less time typing, more time planning what to build and reviewing what got built.
We see this role change on every project but that story isn't quite complete. The gap between the consensus and what actually works is what this piece is about. The time spent on planning and review is the visible half of the shift. The half that feels like a more dramatic and impactful change is that each developer's scope of ownership has to grow, and the control systems that make that scope trustworthy have to grow with it. The job did not just tilt toward planning and review. It got bigger, and it stopped looking like a developer's job in the narrow sense at all.
The hours moved, but the tickets didn't
Look at what the time-reallocation story quietly holds constant: the ticket, the sprint, the backlog. The whole machinery of software delivery survives untouched. The same units of work flow through the same pipeline; we just spend our hours at different stations along it.
But those units were never laws of nature. They were adaptations to a constraint. Humans write code slowly, and adding more humans does not speed it up, so we sliced work into the smallest understandable pieces that could be independently built, reviewed, and merged. Agile and Lean are, at their core, disciplines of understanding your constraints and working with them. The small ticket was a brilliant adaptation to the constraint of human typing speed.
That constraint has dissolved, and you can watch what happens to teams that keep the old unit anyway: small changes finish faster than the machinery around them can absorb, the team floods with pull requests, product managers and designers fall behind the build, and development pushes on into a general mess of unreviewed slop. More planning meetings and more review hours do not fix that. They are more time spent operating a machine built for a constraint that no longer exists.
There is a name for this failure of imagination: the horseless carriage. We took the horse off and bolted on an engine, and now the ride is shaking apart, so we argue about how to hold the reins differently. The carriage has to change.
The task changed hands
Before rebuilding the carriage, it is worth being precise about what actually moved. The task was always a square: hard-edged, discrete, bounded. It can be fully specified, executed, and checked off, and that is exactly why it is the thing you hand to the agent.
What the agent cannot take is the circle: soft, open-ended, a concept of some work to be done. The hard part is judging where its boundary even is, and that judgment stays human. As I put it to a new hire on our team: before, there was this idea of getting a ticket or some semblance of a task to be done; now we are in an interesting, fluffy place that is just a concept of some work that's to be done. My job lives on the boundary between the two: decompose the circle into squares small enough that an agent can run them reliably.
Notice what that does to the org chart in your head. Decomposition used to be a specialized, scarce skill held by one lead, and doling out the resulting tasks was what let teams scale. Now every person on the team is the one decomposing, which means every person has to hold a broader, more holistic view of how their feature is built.
My colleague Britton Russell's companion piece settles the same question from the other side. He looked at the data on who is actually best at vibe coding and found that non-developers can drive the bounded task surprisingly well: Anthropic's analysis of roughly 400,000 Claude Code sessions puts non-software professionals at a 26% success rate against 30% for software engineers, a real but narrow gap. If the bounded task can be driven by someone who does not write code for a living, then the bounded task is no longer where a developer's value sits. The value moved into the circle.
Appetite: work one scope above
So what do you do with the circle? Here is the line I keep repeating internally. We used to break work down to the smallest understandable piece that felt like a good scope. That piece is now the agent's scope. Why would you keep working at the agent's scope? Work one scope above, at the feature those pieces fall out of, because that is where the decision making happens.
Borrow a word from Basecamp's Shape Up: appetite. In our usage, appetite is the size of problem a single person is willing to own end to end. The consensus story leaves per-developer appetite where it was and redistributes hours around it. Our take is that appetite is the thing that has to grow. Instead of one aspect of one feature, you own the whole feature and its integration with the rest of the application. Time spent understanding the work jumps. Time spent waiting on handoffs drops. The developer's context gets larger on purpose, because the decomposition into squares only goes well when the person doing it can see the whole shape.
The 850-page migration of this very site is the cleanest example I have. Migrating 850 pages is a circle no ticket could hold and no single agent should chew through linearly, so the planning work was choosing a pattern, not writing a task. Two decisions carried it. First, strangler-fig sequencing: replace the site incrementally, one slice at a time, leadership pages, then careers, then the blog, instead of a big-bang cutover. Second, batch instead of brute force: Jina Reader scraped the rendered pages into structured markdown and the Anthropic Batch API ran the conversion at half cost, roughly $16 for the whole blog. None of that appears on a task list, and that is the point. One person held the entire migration as a single appetite, and the squares fell out of it cheaply.
I am walking through this migration end to end in What's a CMS in the Era of Agents?, a live workshop on July 15: the real costs, the production gotchas, and a decision framework you can take to your own platform review. Reading this after it airs? The recording lives at the same link.
One caution before this reads as a license to build everything: when building is cheap, the discipline of not building is part of the job. Cheap iteration can lull you into shipping poorly-thought-out work at a volume nobody can absorb. A bigger appetite means owning a bigger question, and sometimes the answer to that question is no.
And appetite alone is reckless. The reason we can take bigger bites at all is the other half of the shift, the half the consensus story barely mentions.
Controls: what makes the bigger bite safe
By controls I mean the systems a builder owns that make it rational to believe the output of a scope that big. The litmus test comes from a conversation with Britton: scope the work to the point that you can put it in auto, and evaluate the result to a degree that you can actually believe what it tells you. If you can do both, your appetite and your controls are matched. If you cannot, one of them is lying.
That test also reframes the most common complaint about agentic work: that it collapses into hammering an approve button. The academic name for this is the "self-automator," and it is usually told as a character flaw. The Harvard Business School study behind the label says otherwise: the failure appears when someone cedes both what gets done and how. That is a scoping problem, not a personality problem. If you are mostly approving, the work was cut at the wrong size. Cut it right and the failure mode disappears.
The rest of the controls are built, not performed:
- Give the agent the tools to test itself. Tests, types, and lint that run as it builds, so errors surface on every change instead of in your review. Without this layer, a bigger appetite just produces a bigger pile of unverified output.
- Insist on a real preview environment. Agents need a production-approximate place to validate changes, and so do you. The absence of one is a major red flag, because "it compiles and looks right" is precisely the dangerous case. This need has been aided for us by Kilter, our platform for spinning up production-like preview environments on demand for agents.
- Review with fresh context. The agent cannot honestly grade its own work; Claude is always very, very happy with what it did. I make a habit of having a fresh-context agent review the output, and I decide which parts need hands-on human review that no agent can cover.
- Audit the inputs, not just the code. The harness is everything an agent ties itself to as it works: the context files, rules, and tools that keep it from drifting or guessing. A stale or unfounded assumption seeded in there propagates into everything built on top of it, so periodic hygiene on those files matters more than any single review.
- Keep the harness small. The popular advice is to pour everything into giant context files and keep throwing rules at the agent. It is not a good way to go. Anthropic's own guidance on context engineering is that you want the smallest possible set of high-signal tokens, because a model's attention budget is finite, and Chroma's context-rot research backs it empirically across eighteen models. Tight scoping is not a stylistic preference. It is the mechanism.
Appetite and controls move together or not at all. Raise appetite without controls and you are the flooded team from earlier. Build controls without appetite and you have beautifully instrumented busywork.
The role that comes out the other side is a builder
Raise both, and the role stops fitting the developer job description. A whole feature owned end to end pulls in concerns that used to belong to other people, and the honest name for the resulting role is closer to builder than developer.
- Product understanding becomes paramount. What we are building, for whom, why, and what they care about drives how you generate UI, structure data, and judge whether the work is done. Without it you are dependent on someone else's QA to validate anything you build.
- Design attention keeps the interface from becoming slop. Leveraging design systems, understanding brand, and caring about accessibility are now everyday concerns, not a specialist's. Not everyone has a trained eye, and AI genuinely helps as assistive tooling here, but an appreciation for good design is no longer optional.
- Research is its own phase. Evaluating approaches, building prototypes, capturing reference documents, and knowing how to ask the right questions of the right people: the learning has to be deliberate because everything downstream builds on it.
- The platform under your feet is your business. A DevOps feedback loop that lets agents interact with the running application, and the judgment to pick the right tool across languages and infrastructure, are what the testing and preview controls above actually run on. Deep technical expertise matters more here, not less. The way we work changed; the need to genuinely understand the systems did not.
There is a live conversation about whether developer, designer, product, and delivery collapse into a single builder role. Boris Cherny, the creator of Claude Code, expects the software engineer title to start disappearing by the end of this year, dissolving into something closer to builder as the designers, product managers, and managers around him ship code of their own. "I see it all blending into one thing," he says. "Call it a builder, call it an engineer, call it a product manager. I don't know what the title is, but the role is changing."
I am not sure what it will finally look like either, and roles are especially fuzzy right now. But the direction is unmistakable: broader. Each of these fields is reaching into development from the other side, and the people who thrive are the ones treating the fuzziness as room to grow into rather than a threat to their lane.
Which is the honest answer to the fear that follows this whole essay around: if I am getting good at handing well-scoped work to agents, am I optimizing my way out of a job? The judgment layer relocates; it does not vanish. However big the agent's scope grows, there is always one scope above it, and someone has to work there. The HBS study lands exactly here: the professionals who directed the AI with real expertise grew their own, while the ones who fully delegated and disengaged gained nothing and produced weaker work besides. The danger is not that the agent does the task. It is choosing not to do the thinking around it.
What compounds
The last reason to think in appetites and controls is that both of them compound, and they compound beyond one person. Kieran Klaassen at Every defines compound engineering crisply: each unit of engineering work should make subsequent units easier, not harder. My own piece on the OODA loop is the same instinct pointed at a single build loop: spend the effort up front on observing and orienting so the acting goes right the first time.
Here is what it looks like pointed at a team. This spring a colleague and I both needed booking systems on two different projects, a feature with a well-earned reputation for hidden complexity. Instead of each grinding through it alone, we worked through the domain together: calendar models, timezones and daylight saving, slot definition, reservations and approvals, rate limiting, access control. That thinking became a playbook, and now anyone on our team who builds a booking system starts from it, and so do their agents, grounding their plans in concerns that are easy to miss the first time through. What compounds is our understanding of the problem.
That is collaboration in the new shape of the job: surfacing what works for you and pushing it into the shared scaffolding so the whole team gets the benefit. A bigger appetite gives you more surface area to learn from. Controls give the learning somewhere durable to live. The compounding is the point.
What's still genuinely unsolved
I would not trust this piece if it ended on a tidy bow, because parts of this are unresolved and raising appetites makes one of them worse.
The first open problem is reviewing N parallel agents. Work no longer arrives as a steady stream of tickets; it arrives in unpredictable batches. It is 4 p.m. and suddenly there is an enormous pile of finished work to look at, all at once, and everything I said about verification assumes you can give each result real attention. Bigger appetites make the pile bigger. Nobody in the industry has settled tooling for this yet, but it is the problem we are most actively building against, and I will come back to what that looks like in a moment.
The second is vocabulary. This model holds up fine in front of other practitioners, but I still do not have good language for people who have not used these tools much. The square and the circle are my best attempt so far, and they are not enough. The naive picture, where you type a prompt and hit approve until it looks fine, is so far from the truth that it actively misleads. The real thing is closer to constant brainstorming than to dispatching, and until we have words for that, this shift will keep getting misread as either magic or laziness.
We are not waiting for perfect answers, though. Everything this essay argues for is becoming something we can stand up for a team, not just describe to one. We call it an Agentic Platform Studio: a single portal for a project that carries this whole way of working.
The circle gets a home, a per-project context lake holding the goals, constraints, and decisions agents ground themselves in. Appetite gets tooling, plans and story maps pitched one scope above the agent, and a pattern library of playbooks (the booking one lives there) so nobody starts from zero. Controls get built in rather than bolted on: harness management, fresh-context agentic review, a feedback hub that turns stakeholder requests into well-scoped work, and preview environments on demand through Kilter. Even the 4 p.m. pile is in scope; the review tooling is aimed squarely at it, and running our own projects through the studio is how the open problems above stay honest instead of hidden.
We are trialing the studio on our own work right now. If these are the ideas you are wrestling with and you want to tackle them head on with a studio inside your own company, we would love to hear from you.
So here is where I have landed. A developer is becoming a builder: the person who holds the fuzzy concept of the work, works one scope above what any agent runs, and builds the controls that make the output believable. The square moved to the machine. The circle stayed with us, and it was always the harder, more human half of the job. The task got smaller. The job got bigger.
