Something weird is happening in software development right now. Coding agents are getting genuinely good at writing code. Claude Code, Cursor, Codex. They can read your codebase, make multi-file changes, run tests, iterate. Cursor's cloud agents are already producing 30% of their own merged pull requests, running autonomously on VMs. The code part is increasingly solved.
But here's what keeps nagging at me: these agents are building software meant to be used by humans, and they can't perceive their own work the way a human would.
Your agent writes a checkout flow. It can read the HTML it generated. It can verify the DOM structure matches what it intended. It can run Playwright tests against the page. What it can't do is look at the checkout flow and notice that the button color is wrong, the loading spinner feels sluggish, or the layout breaks on mobile in a way that makes users hesitate. The agent is blind to the experience it created.
The agent is building software meant to be used by humans, and it can't perceive its own work the way a human would.
This wasn't a big deal when agents were autocomplete tools living inside your IDE, suggesting the next few lines while you watched. You were right there. You could see what was happening. But that era is ending fast.
Agents are leaving the IDE
It's already happening. Cursor shipped cloud agents running on isolated VMs in February. Zed merged headless mode for programmatic AI control. Claude Code runs in terminals, CI pipelines, and cloud environments. The agent doesn't need your laptop anymore.
Which means the agent is building in one place and you're reviewing in another. The work happens in a cloud VM. You get a preview link and a pull request.
And here we arrive at the actual problem. Not the code. The conversation.
The middle loop has no language
People are starting to notice. Simon Willison built Showboat so agents can create executable markdown documents that demonstrate their work, mixing commentary, code blocks, and captured output into a single verifiable artifact. Rodney, his companion tool, gives agents a CLI for browser automation so they can actually drive what they built and take screenshots. He's cataloging what works in his Agentic Engineering Patterns collection.
Agentation attacks it from the human side: you click elements on your page, add notes, and it generates structured output that helps agents find the exact code you're pointing at. Version 2.0 added an MCP server so agents can fetch your annotations directly.
And now there's data to back it up. Annie Vella ran a six-month longitudinal study with 158 professional engineers across 28 countries and found that 82% are spending less time writing code — but the freed-up time isn't flowing upstream into design and architecture the way everyone assumed. It's compressing across almost every task category. What's growing instead is what she calls "supervisory engineering work": directing AI, evaluating its output, correcting it when it's wrong. The creation-to-verification shift was statistically significant across her study period. Engineers are more productive (84% reported gains), but the proportion reporting negative developer experience nearly doubled, from 14% to 27%. She calls it the productivity-experience paradox. The work changed, but the tools didn't change with it.
These tools and findings all circle the same insight: agents need to show their work, and humans need better ways to point at what's wrong. I think both are right, and I think the problem is bigger than any single tool can solve.
There are three loops in agent-assisted development, and the middle one is broken.
The inner loop is the agent writing and testing code. This works. Live browser, browser automation, test runners. The agent has tools to build with. The outer loop is production feedback coming back to development: bug reports, session replays, analytics. This mostly works, if slowly.
The middle loop — a framework Steve Yegge and Gene Kim introduced in Vibe Coding, and that Thoughtworks' Future of Software Development retreat later called its "strongest first-mover concept" — is where a human decides whether what the agent built is actually right before it ships. Right now, the tools for this are embarrassing. You get a preview link. You click around. Something feels off. You switch to chat and type "the animation on the second step feels janky" or "I think the spacing is wrong on the pricing card." The agent reads your words, guesses what you mean, tries again. You go back and forth four or five times. Maybe you take a screenshot and annotate it. Maybe you use Agentation to point at specific elements. Better than chat, but still a lossy translation of what you actually experienced.
This is the communication layer for the fastest-growing workflow in software development, and it's screenshots and chat messages and annotated DOM elements.
Sessions as language
This is why we built Subtext. But first, what do we mean by "session"?
A session is the captured experience of someone (or something) using your application. Every click, scroll, navigation, pause, and error, recorded with full visual context and structured so that both humans can watch it and agents can read it. It's the lingua franca of digital interaction. If you've used Fullstory, Datadog, or any session replay tool, you know the concept. What's new is making sessions the communication layer between agents and humans, not just an analytics artifact.
Sessions are the native language of human-agent collaboration.
When your agent builds something and deploys it to a preview, instead of you describing what's wrong, what if you just used the app? Your clicks, your pauses, your path through the interface, your annotations at specific moments. That's structured, timestamped, contextualized feedback. The agent doesn't have to interpret "the spacing feels off." It can see exactly where you stopped, what you looked at, and what you did next.
And it goes both directions. When the agent finishes building, it doesn't just hand you a link. It captures its own session: driving the app, testing the flows, annotating what it did and why. "Fixed the re-render bug. See 0:34." You watch the replay. You see what the agent saw (or rather, what it would have seen, if it could see).
The session becomes the shared artifact. A full, replayable, annotated record of interaction with the actual application. It captures everything chat can't: timing, hesitation, the path someone actually took versus the path you assumed they'd take.
Where this goes
We built Subtext to give agents that shared artifact. It's session replay built for agents, a category we call Agentic Session Review. Your agent opens a real session the way it opens a file: the screenshots, the DOM and its diffs, the console, the network, the accessibility tree, read as tools and reasoned over. Not a video to watch. Not a summary to skim.
Right now, a human reviews every agent-produced change before it ships. That's correct; we're early, and trust needs to be earned. But every session an agent reads is evidence, and every session you capture of the real thing going wrong is context it could never have guessed. The more the loop runs, the less there is to explain.
And then there's agent-to-agent. When one agent hands off to another, a building agent to a QA agent, a frontend agent to a backend agent, the session becomes the handoff. Not API calls. Not structured messages. The actual experience, replayable, that the receiving agent can read for itself.
We're not building agents that write code faster. We're building the layer that lets them see.
Subtext is out today. Start free, or point your agent at a real session:
npx @subtextdev/subtext-wizard