Project, Agent, Person: The Missing Axis of AI Coding Tools

Introduction

A few months ago I wrote about the missing levels between juggling coding agents and building your own orchestrator. That post ended on an uncomfortable note: at some point the tooling runs out, and you are told to build the orchestrator yourself.

This post is about why. Why, with dozens of well-funded AI coding tools shipping every month, the one that would coordinate your work across every project, machine, and inbox is the one you still assemble by hand.

The reason has little to do with the market lagging. Almost every tool is built around something other than you: the project, or the session, and rarely the person.

Autonomous vs assistive AI coding agents: the axis everyone measures

Almost every framework for AI coding tools measures the same thing: how autonomous is it?

Steve Yegge's eight levels run from no AI at all to a custom orchestrator. Dan Shapiro's five go from spicy autocomplete to the Dark Factory. Sourcegraph and Swarmia each ship their own. Addy Osmani recently split the ladder into two axes. But both, as I will come back to, are still about autonomy.

I am not going to re-teach the ladder here. My previous post tried to fill in its missing rungs, and the ladder itself is real, useful, and thoroughly mapped. It answers one question well: how much can I trust the tool to do on its own?

That is not the only question worth asking.

The axis nobody names: a tool's center of gravity

Here is a second question the ladders never ask: what is the tool built around?

Not how autonomous it is, but what sits at the center: the thing every feature is quietly designed to serve. I think of it as a tool's center of gravity, and three answers keep showing up. Sorted that way, AI coding tools fall into three kinds: project-centric, agent-centric, and person-centric.

• Project-centric: the unit is the repository and the issue. You hand over a task and an agent works autonomously toward a pull request.
• Agent-centric: the unit is the session. You live inside one tool's cockpit and run your agents from there.
• Person-centric: the unit is you. The tool coordinates your work across the repositories, trackers, and machines your name touches.

Two clarifications first.

This is a different "agent-centric" than you may have met elsewhere. It is not Sonar's Agent-Centric Development Cycle, a code-quality governance loop, and it is not UX's user-centered design. Here it means one thing: the tool is built around the agent session as the place you live, and the cockpit is the product.

And these are centers of gravity, not boxes. Real tools straddle. GitHub's Copilot coding agent is a project-centric workhorse that also ships a personal dashboard; Cursor is an agent-centric cockpit that also runs background jobs. I am naming what each tool leans toward, not sorting them into sealed compartments. The mappings that follow are my own analytical lens, not how these vendors describe themselves.

One caveat on that word "missing": it is missing from how we usually talk about these tools, not from the market. Autonomy gets all the frameworks; center of gravity gets almost none. And the two are not the same measure in a different coat. A dependency-bump bot that opens one small, pre-approved kind of pull request is deeply project-centric and barely autonomous. Autonomy and center of gravity tend to travel together, but nothing forces them to. Set autonomy aside and sort tools by their center of gravity, and the space takes on a shape of its own: three worlds side by side, with one corner still conspicuously empty.

Project-centric: the repository is the unit

The most crowded, best-funded corner is project-centric.

The pattern is familiar: you describe a change as an issue, an agent picks it up in the cloud, and a pull request appears for you to review. Devin is the flagship. Cognition has marketed fleets of them migrating repositories in parallel, and in 2025 it bought the Windsurf IDE, one project-centric vendor absorbing an agent-centric one. Google's Jules, OpenAI's Codex cloud agent, and GitHub's Copilot coding agent all run the same play, with Factory's Droids and the open-source OpenHands rounding it out.

This is the vendor-built road to the top of the autonomy ladder, and it is genuinely good. For bounded, well-specified, high-volume, team-owned work, made of dependency bumps, CVE patches, and mechanical migrations, it is the right answer; a human in the loop is friction, not safety.

The momentum is real enough that I see it inside my own company. fullsend is a public design-doc exploration of fully autonomous engineering: triage, implement, review, and merge, with a human pulled in only for the risky changes. It is an effort from engineers I know at Red Hat, where I also work, an independent open-source exploration, not a Red Hat product or roadmap. I mention it because this direction is not a fringe bet; it is where serious people are pointing.

Some argue this is the only corner that will matter. OpenAI's Thibault Sottiaux calls scaffolding "coping, not scaling," and a lot of the money is behind it. It is a bet, though, not a settled result: across teams, the bottleneck has moved to verification, and context, coordination, and oversight still gate what raw autonomy delivers.

Agent-centric: the session is the unit

Start with what this corner gets right.

A single, opinionated cockpit is the best environment we have for focused work. Claude Code in a terminal, Cursor in an editor, Sourcegraph's Amp: deep in one hard change, living inside a single well-designed tool beats hopping between five. The local orchestrators built on top of this, like Conductor, Claude Squad, and Vibe Kanban, inherit the same virtue. Each agent gets its own git worktree, and you conduct them all from one place: the one machine they run on. The tell of the category is that coordination happens around the agent.

Cursor is multi-model (Claude, GPT, Gemini), so the lock-in was never really about the model. It was about the cockpit. The same gravity that makes a cockpit great also draws it toward a closed edge: the more a tool optimizes for the session you live in, the more it wants to be the only session you live in. Read one way, you can watch that edge harden. When the third-party client opencode tried to use Claude subscription credentials, it got back This credential is only authorized for use with Claude Code and cannot be used for other API requests. Anthropic had restricted those credentials to its own tool, pushing other clients toward a metered API key. Cognition buying Windsurf is the same physics at a larger scale.

None of this is villainy. It is what happens when the session is the center of gravity: the tool is the product, and the product wants you inside it.

Person-centric: you are the unit

This brings us to the empty corner. I should be upfront here: I build a tool that lives in this corner, so if the case only works because it flatters my own project, it does not work. I have tried to write the version that survives deleting it.

A person-centric AI coding tool takes you as the unit of coordination. Not this repository, not that session, but you, and the whole spread of work that carries your name: repositories across several orgs, issues in two trackers, a review waiting in Slack, agents on a laptop and a workstation. The center is the person, not the project or the platform. Acting on your behalf is a trait that follows from that, not the axis itself.

Two properties make it categorically different. It is cross-surface: it reaches past any single repo, IDE, or platform into your actual working day. And it is rooted in your environment: it coordinates whatever agents you run, Claude Code or anything else, wherever you run them, not only the ones a vendor hosts inside its walls. It is the corner the human-as-operator camp keeps pointing at, from Willison's "agentic engineering" to Swarmia's caution that higher autonomy is not always better, usually with no developer-grade tool to name.

So, to put the claim in a way you can push back on: person-centric coding tools are not unserved, but they are badly underserved. Consumer assistants already act on a person's behalf across their messaging apps, and "AI chief of staff" tools do it for knowledge work, but none of them touches code, repositories, or CI. The closest thing in our world is GitHub's Agent HQ, whose mission-control view already gathers agents from several vendors into one pane. But it orchestrates only the agents GitHub hosts, on GitHub's own surfaces. It does not reach the sessions you run on your own hardware, or the work that spills into your inbox and your other trackers. Others feel the same pull. Cursor gathers its own agents into one window, and a few small cross-brand tools route agent approvals to your phone; the first is a single vendor's garden, and the second is a thin slice of the job. As of July 2026 I still cannot find a professional-grade tool that is vendor-neutral, spans your projects and surfaces, keeps you as the operator, and coordinates the actual work rather than one seam of it. A few of the tools inching toward that corner are not mine, and I would genuinely like to be wrong here. If you know one that already qualifies, point me to it and I will add it.

That empty corner is the shape I am building toward with ai-beacon: the agents on all your machines in one web view you can reach from anywhere, Claude Code and opencode alike. It grew out of the coding-agent dashboard I wrote about earlier this year, and it is early and experimental. The category matters more than my attempt at it.

The plumbing for this corner is half-built. There is a standard for each seam: Model Context Protocol (MCP) between agents and tools, Agent Client Protocol (ACP) between editors and agents, A2A between agents, AG-UI between agents and interfaces. What none of them provides alone is the cross-context layer that would tie your work together above all of them. That layer is missing precisely because no vendor is incentivized to center it on you.

The person-centric approach has a real weakness of its own. It lives at the mercy of the very boundaries it crosses. A control layer that rides on top of every vendor inherits none of their guardrails: no CI, no review gates. And any vendor can starve it with a credential restriction, the closed edge from before. That is not a reason the category should not exist. It is the reason it is hard.

What is new here, and what isn't

Let me be careful about what I am and am not claiming, because the prior art deserves credit. The project-versus-agent distinction is not new; it relabels things people already say. OpenHands has written about the inner loop versus the outer loop, accelerating the individual versus handling whole tasks over Slack and Jira, which maps almost exactly onto agent-centric versus project-centric, though OpenHands straddles both. Osmani's two-axis model splits autonomy into agency and orchestration, but his second axis is how many agents you run, which is still a question about autonomy.

What is actually new is small but load-bearing. It is choosing center of gravity, what the tool is built around, as the axis, instead of the degree of autonomy, and then naming the person-centric category, at professional developer grade, as the one that is missing. Neither Osmani's orchestration axis nor OpenHands' outer loop leaves a seat for the person. That seat is the whole point.

How to choose between project-, agent-, and person-centric tools

None of this is a fight to the death. The future I expect is a composition, with a clear boundary between the parts: a control tower over a factory floor. The factory floor is project-centric: many autonomous agents turning well-specified issues into pull requests while you sleep. The control tower is person-centric: one person's single pane of glass over all of it, across projects, surfaces, and machines. They are not rivals; they are different altitudes of the same operation.

That leaves a decision rule I can use day to day.

• When the work is depth on a single change, reach for the cockpit (agent-centric).
• When it is a specced unit you can hand off and walk away from, reach for the factory (project-centric).
• When it spans projects, surfaces, or machines and needs your judgment routed across all of them, reach for the control tower (person-centric).

The uncomfortable part is that the third tool is the one the market is least likely to hand you. My previous post said you would probably have to build your own orchestrator. I now think the deeper reason is structural. Every vendor's center of gravity is the project or the platform, because that is where the business is. Almost none of it is you. AI coding tools differ less by how autonomous they are than by what they are built around, and the human is the one center nobody has quite built for yet.

If you are somewhere on this map, I would like to know which corner. I am collecting notes in the ai-beacon discussions, the same place as last time. Thanks, too, to my colleague Václav Vančura, whose UX thinking helped sharpen how I see all of this. The more corners we compare, the sharper the map gets.