Building with agents
DevX is dead. Long live AgentX.
AgentX is agent experience: the agent does the actual work now, so you design every project around its access and its flow, not the developer’s.
I build software that an agent operates instead of a person. The strangest part is not the speed. It is that the chair in front of the keyboard is empty, and everything we built for the human who used to sit in it is quietly coming apart.
For about thirty years, one assumption sat under every developer tool ever made: a person is driving. The documentation, the dashboards, the review step, the onboarding, all of it was shaped around a human who arrives with context in their head and produces one thing at a time you can look over. Pull that human out, put an agent in the seat, and the assumption does not bend. It snaps.
The real shift is easy to miss. It is not that AI writes code faster. It is that the tools are no longer for us. They are for the thing now doing the operating. We moved up a floor, to deciding what should be built, judging whether it is any good, and owning the result. The agent moved into the seat we just left, and it needs the work designed around it.
Built for the wrong user
Once you accept that the agent is who you are building for, the cracks show up everywhere.
Start with documentation. Every manual ever written assumed a reader who skims, builds a mental model, and remembers it tomorrow. An agent does not read your docs, it calls them, mid-task, one piece at a time. The question stops being whether the writing is clear and becomes whether the agent can find the right piece, use it without tripping, and recover when it fails. Most docs have never been tested that way.
Then there is review. We built our whole idea of quality around checking one output: one pull request, one design, one thing to look over. An agent does not hand you one thing. It takes forty small steps to get there, and by the time you see the result the decisions that mattered are buried turns back.
And access. This is the one people underestimate. A developer arrives already holding the keys: logins, permissions, the right to touch the database and call the service. The agent arrives with none of that, and it cannot do the work you orchestrate until it can actually reach the systems. Designing for AgentX means designing that access on purpose, scoped and revocable, instead of bolting it on afterward.
You orchestrate, the agent executes
For most of software history one person did both jobs: decide what to build, then build it. The real change an agent brings is that it splits those two jobs cleanly apart.
You keep the half that needs judgment. What is worth building, whether the result is any good, what to do when the agent gets it wrong, who owns the outcome when it ships. The agent takes the half that is execution: the file edits, the calls to the service, the retries, the dozens of small steps in between.
This is not a productivity tweak. It is a different shape of work, and I am not the one who noticed it first. Anthropic’s 2026 Agentic Coding Trends Report puts it plainly: the engineer’s job is moving from writing code to orchestrating the agents that write it. I think of it as going from musician to conductor. The same reframe keeps surfacing elsewhere, drawn by people who are not talking to each other. When the picture keeps repeating, it is usually because the picture is real.
The catch is that the execution half only works if you have designed for it. An agent that can think but cannot reach the database is a very expensive intern who can only give advice. The whole point of AgentX is to close that gap: give the agent a clean, safe way to actually do the thing you decided should happen.
What designing for AgentX actually means
None of this is abstract. When the agent is the one you are building for, the same project quietly gets designed differently. Access was the point of the last section; the move that follows from it is to stop slipping the agent your own logins and give it an identity of its own, with permissions you can scope down and pull back. “Give it access” stops being a shrug and becomes a decision you can defend.
Memory is the next thing to move. A person carries context from one day to the next without thinking about it. An agent starts every run from nothing unless you build it somewhere to remember, so you write down what it worked out last time, put it where the next run will find it, and it stops solving the same problem twice.
Then there is the way actions behave when things go wrong, which they will. An agent does its work in long chains of small steps, and nobody is watching each one. Anything that touches the real world has to be safe to retry and safe to interrupt, so that a crash halfway through a task leaves something you can recover rather than a mess you untangle by hand.
Do all of this and the agent stops being a clever assistant that hands you suggestions. It becomes something that carries a task from the decision you made to the thing actually done. That is the whole game.
The part I don’t get to skip
If I stopped here it would sound too easy, so here is the hard part.
Giving a job to an agent does not just move the old risks around. It adds new ones. Once agents can talk to each other and act on what they hear, things can break in ways they never could before. One agent can pretend to be another. A bad instruction can be slipped into the middle of the work. Someone can fake being a step in your own system. And the memory I liked so much a minute ago works both ways. If a lie gets saved into an agent’s memory, it does not go away when the session ends. It stays, and the agent believes it again every time it runs.
The bigger problem is one no clever design can fully fix. We are giving agents the keys faster than we are making the locks. It even has a name now, the accountability gap: agents act faster than anyone can answer for, so the person who has to explain a failure is often not the person who actually held the wheel. That gap is the thing to worry about. The problem was never that the model is too dumb. It is that we gave it real power before we were honest about who takes the blame.
What it comes down to
For years we made software nicer for the person using it. That person is still here, but they moved up a chair. Now they decide, they judge, they own the result. The agent sits where they used to sit, and it does the work.
So the real question for your next project is not how smart the model is. The models are already good enough to surprise you. The question is whether you built the thing so an agent can actually use it. Can it get in. Can it remember. Can it act without breaking something. Can it find its way back when it slips.
DevX made software good for people. AgentX makes it work for the thing that now does the doing. The winners will not be whoever has the smartest agent. They will be whoever built for it first.