There is a specific muscle memory that every developer acquires. Ghost text appears at your cursor — a gray suggestion hovering just ahead of where you are — and without thinking, you hit Tab. The AI guessed right, or close enough, and you accepted it and moved on. The whole transaction took less than a second. You barely noticed it happened.
That reflex was the beginning of something. It was also, I now think, a kind of ceiling.
The story of LLM-assisted coding over the last few years is usually told as a story of capability — models getting smarter, context windows getting bigger, tools getting faster. All of that is true. But there is another story nested inside it, one about how the design of the harness shapes the engineer using it. Not the model. The wrapper. The interface. The place you sit when you work.
I've been paying attention to that story, and it has led me somewhere I didn't expect.
// Four Phases, One Address Bar
The first serious LLM coding assistance most engineers encountered was ghost text — an autocomplete that had read most of the internet and could, with uncanny frequency, finish your function before you did. It felt like IntelliSense had gone to graduate school. You typed a comment describing what you needed, and the model suggested an implementation. Sometimes it was exactly right. Sometimes it was subtly wrong in ways that cost you twenty minutes to trace. Sometimes it was confidently, elaborately wrong in ways that were almost impressive.
It was clunky. Anyone who has tried to write a SQL query manually with this generation of tooling still active knows what I mean — the ghost text chasing your cursor through a JOIN clause, offering completions that are structurally plausible and semantically broken, interrupting your train of thought more than it helps it. The muscle memory of Tab-acceptance trains you toward a particular kind of passivity. You're not writing; you're approving or rejecting a stream of suggestions.
The next phase was chat. A panel appears alongside your editor, and you can ask it things. Explain this function. Why is this test failing. Write me a method that does X. It's incremental help — the AI as a rubber duck that talks back, as a Stack Overflow that returns one specific answer instead of seven contradictory ones. This was genuinely useful. It was also reactive by design. You wrote the code; the AI responded to your code. The directionality was fixed.
Then came edit mode. The AI stopped waiting to be asked and started making changes directly in your files. You described what you wanted, and the diff appeared, and you accepted or rejected it. The engineer became a reviewer rather than a typist. This was a meaningful shift in the interface — now the default state was that the AI acted and you evaluated, rather than the AI responding and you implementing.
After that, agent mode: the AI spans your entire solution. It opens files you haven't mentioned, traces dependencies, makes coordinated changes across a codebase, runs tests, reads the failures, and tries again. The scope exploded. What had been line-by-line suggestions became something closer to a junior engineer executing a feature ticket.
Each phase was a genuine leap. And every single one of them happened inside the IDE. The editor was always the address. You and the AI shared a workspace, and you were always sitting right next to each other.
// The Co-Authoring Bet
VS Code, Cursor, and antigravity all make the same fundamental wager: the engineer belongs in the editor, working alongside the AI. The tools evolved in place — new capabilities layered onto a familiar spatial arrangement. Same window, same file tree, same split panes. The AI grew more capable; your chair didn't move.
This is a genuinely smart design choice. It meets engineers where they are. It's additive. Autocomplete doesn't ask you to change how you work; it just makes typing faster. Chat doesn't require a new mental model; it's a conversation you can ignore. Edit mode and agent mode escalate the AI's role incrementally, giving engineers time to adapt to each expansion before the next one arrives. The natural on-ramp of that progression is part of why adoption happened so quickly and so broadly.
But there is a subtle tax embedded in the co-authoring model, and I didn't see it clearly until I stepped out of it.
The tax is this: when the AI's output is visible in your editor, and your hands are on your keyboard, and the code is right there in front of you — you will fix it yourself. Not always. But often. Often enough to matter.
You see a wrong variable name and you correct it. You see an inefficient pattern and you refactor it. You get impatient waiting for the agent to work through a problem you already know the solution to, and you type the solution. The keyboard is right there. Your hands know what to do. The cost of intervening is nearly zero, and so you intervene.
Every one of those interventions is rational in isolation. Together they constitute something: a steady gravitational pull back toward doing the work yourself. The IDE keeps you in IC mode — individual contributor mode, the posture of someone who writes the code — even when you're nominally directing an agent. The architecture of the workspace quietly resists the architectural role.
// The Abstraction School
On the other end of the spectrum, platforms like Lovable and Replit went the opposite direction. They pulled the technical details out of frame entirely. You describe what you want to build, and an application appears. No file tree, no terminal, no merge conflicts. The AI handles everything below the product level.
For non-engineers, this is transformative. For engineers, it's something else — a trade that gives you speed while asking you to give up the understanding that makes the speed meaningful. Your debugging instincts go dark because you can't see what you're debugging. Your architectural judgment can't engage because the architecture is hidden. You gain access to output; you lose access to craft.
There's a real and growing use case here. Not everything needs an engineer. Not every engineer needs to care about every layer. But for someone who has spent years building that judgment and wants it to compound, full abstraction is its own kind of ceiling.
// A Third Position
I've been writing this blog using Claude Code — which is, to be precise about it, the platform I use for most of my serious technical work now. It lives in your terminal. It talks to you in prose. The code is happening somewhere on disk, and Claude is reading it and writing it, but you are not looking at a file in a split pane. You are describing intent in a chat window, and then — when Claude is done — you review what changed.
The first few sessions, I kept wanting to pull up the files myself. Old habit. But the design doesn't fight you on this; it just doesn't encourage it. There is no file tree to click. There is no diff sitting in front of you waiting for a quick keyboard fix. There is a conversation, and then there is a result, and the gap between them is where the AI is working.
That gap turns out to matter a great deal.
// What Distance Does to Your Thinking
When you cannot see the code while the work is happening, you think differently about the work. You have to. The only way to influence what gets built is to describe it clearly, in advance, at a level of specificity that makes your intent legible to something that will take it literally. You can't rely on a quick correction mid-stream. You can't catch an issue and type over it. You have to have thought about it before you sent the message.
This forces a shift in cognitive posture that I suspect willpower alone would never have produced. I spent years being told to think more architecturally, to be less precious about implementation details, to trust my team to execute rather than doing it myself. Good advice that I absorbed intellectually and largely ignored in practice, because the cost of doing it myself was always low enough to rationalize.
The harness changed the cost structure. Grabbing the keyboard to fix a variable name now means interrupting a multi-step plan, adding a manual edit outside the agent's context, and creating a state the agent doesn't know about. The friction is real. So instead I write a better description. Instead I think through the problem far enough that the output is right the first time, or close enough that one round of correction closes the gap.
What you describe, when you have to describe carefully, is not the code. It is the behavior you want, the constraint you care about, the reason this matters, the thing you'll check to know if it worked. You are talking about the system, not the syntax. That is architect mode. The harness put me there, and the incentives kept me there.
// Scope Expands When Your Hands Stop Typing
The most unexpected consequence of this shift was what happened to the scale of what I was willing to attempt. In the IDE, my sessions had a natural shape: a feature, a bug, a refactor of a specific module. Concrete, bounded, executable in an afternoon. I was thinking at the horizon of my hands.
Working through Claude, sessions started sprawling in a different direction. I'd start with an intention and find myself designing the next five PRs worth of changes in the same planning conversation. I'd be thinking about dependencies between systems I hadn't opened yet. I'd be writing descriptions that were closer to specifications than prompts — here's what we're trying to achieve, here's why the current structure makes it hard, here's the order in which these pieces need to move.
The planning and iterating flow isn't just more efficient. It's qualitatively different. You're not constrained by what you can type; you're constrained by what you can articulate and what Claude can execute. Both of those ceilings are, in practice, much higher than they first appear. The ambitions I'm willing to put on the table have gotten meaningfully larger, because I'm no longer unconsciously limiting them to what feels manageable for one engineer with a keyboard.
There's a version of this that is just leverage: more output per unit of time. That's real. But the more interesting version is scope expansion: thinking about what you're building at a different grain size entirely. The transition from musician to conductor, which I've written about before, happens more completely when you aren't holding an instrument. The podium enforces the role.
// What the Harness Is Actually Designing
I don't think most tooling teams are thinking explicitly about this. The choices that produce cognitive distance — text-based interaction, no file tree, working in prose rather than diffs — are probably made for practical and aesthetic reasons, not because someone decided to deliberately reshape how engineers think about their work.
But that's what's happening. Every harness is a set of affordances and constraints, and those affordances and constraints shape behavior, and behavior over time shapes cognition. The IDE that puts a keyboard next to the agent's output is training you to intervene. The platform that hides the code entirely is training you to describe. The tool that makes the gap between your words and the result deliberately wide is training you to think at a higher altitude.
Harness designers are making choices about developer cognition whether they realize it or not. The engineers who will be best positioned to take advantage of the next wave of model capability will be the ones whose tooling has been training them to work at broader scope, longer time horizon, and higher level of abstraction — not because they're smarter, but because the constraints of their environment have been shaping them in that direction.
// Where This Goes
I think we're still early in understanding what the right harness design looks like. The IDE-adjacent tools are excellent at what they do, and the co-authoring model will continue to improve. The abstraction-first platforms will keep opening the door to people who couldn't build before. And the text-based, spatially-separate approach will keep producing the specific cognitive shift I've been describing.
What I'm curious about is whether the next generation of tools finds a way to blend these. The contextual richness of IDE integration — knowing exactly what files you have open, what tests are failing, what the diff looks like — combined with the cognitive-distance benefits of working in prose rather than diffs. Maybe the "editor" becomes a detail the tool manages rather than an interface the engineer inhabits. Maybe the spatial metaphor changes entirely.
I don't know what that looks like. But I know the variable that matters: where the engineer is sitting, relative to the code, when they're doing their most important thinking. The harness that gets that right will produce something new — not just faster engineers, but engineers thinking about fundamentally different kinds of problems.
The thing that unlocked bigger thinking for me wasn't a smarter model. It was getting out of the place where the old habits lived.
Everything else followed from that.