A few months ago I caught myself accepting a 412-line diff without reading all of it. It wasn't laziness in the classic sense. I read the first sixty lines, they looked sensible, the code compiled, the tests passed, and I hit accept. Two weeks later I found out the agent had rewritten a pagination function so that the last page always returned the first item, repeated. Nobody noticed for eleven days. Me included, and I own the place. I'm starting here because it's where the conversation about the future of the IDE should start, and rarely does. The thesis going around is that the editor dies. If most code starts life as a sentence typed into a chat box, or as an agent running on its own in a terminal while you go get coffee, then what's the point of an editor with syntax highlighting, refactoring shortcuts and a file panel? I think the question is badly framed. Typing was never the bottleneck. Anyone who has spent a few years maintaining software they didn't write knows the time goes almost entirely into reading, understanding, distrusting, reproducing a bug and understanding it again. Agents attack the cheap part of the job and leave the expensive part untouched. Which brings me to the first second-order effect, the one I think is most underrated. If writing becomes almost free, the volume of new code goes up, and what goes up with it is the surface someone has to review. The IDE of the future isn't a place where you write. It's a place where you audit. And in that world the central component stops being the text editor and becomes the diff viewer, the debugger, the test runner, anything that lets you ask "what actually changed, and what stopped being true" in under four seconds. Current IDEs are terrible at this. The Git diff in almost every tool is still a list of red and green lines that ignores semantics completely. Move a function somewhere else and it looks like a total rewrite. That said, I have no patience for people who say chat is the new paradigm. The conversation box on the right side of the editor is, honestly, a terminal with better manners. It works because natural language is flexible, but it's a horrible interface for state. I can't tell what the agent has in context, what it forgot, which files it read, whether the database schema version it imagines is yesterday's or today's. I spend half an hour reconstructing that with questions, like cross-examining a witness. When the IDE can show the agent's context the way a debugger shows the call stack, then I'll have something new. Until then it's a chat. Actually, about fifteen years ago I used to write PHP in Notepad++ with an FTP client open beside it and thought that was the peak of productivity. Save the file, hit F5, see what happened. No autocomplete, no static analysis. Curiously, I had a perfect mental model of every file, because every line had passed through my fingers. I don't miss it, but I note the trade. Because that's where the hidden cost lives, and it's the point that makes me hesitate the most. When you stop writing, you stop building the map. Writing is a slow, irritating way of memorizing a system. An agent that hands you a finished feature also hands you a territory you never walked. It works until the day something breaks at two in the morning and you have to reason about a module you only know through the description the agent itself gave of it. It happened to me with an intermittent ECONNRESET error in a task queue, and I lost a whole afternoon simply because I didn't know where the reconnection timer was. It had been generated, it had been fine, and I didn't recognize it. And here I contradict myself a little, because I also know I'm speaking as someone who likes his map. A lot of code doesn't deserve a map at all. A migration script that runs once, a CSV converter, the umpteenth contact form. For those, the agent is a blessing, and anyone who insists on writing by hand is putting on theater. My position, if I have to pin it down, is that the code that's going to wake you up at night should pass through your own hands, and the rest can pass through the agent's. The hard part is knowing in advance which is which. It's the third-order effects that really worry me. The first is training. A junior who has never written a wrong SQL query and watched it fail will never develop the nose that tells a slow query from a slow query caused by a missing index. I know this sounds like an old man yelling at clouds, and I have no proof, only the impression left by a handful of young programmers I've talked to who know how to ask but don't know how to doubt. The second is the convergence of repositories. Convention files written for agents are already appearing, with rules on how to name things, where to put tests, which libraries are banned. In a few years projects will be structured less for humans and more for whoever reads them on a token budget. Good code will be code the model can cross without getting lost, and that isn't necessarily the same as good code. The third is power. For a decade the language server protocol was the last truly open thing in the editor world. You could switch editors without losing the essentials. Now the value sits in the agent layer, in the context it accumulates about your project, in the habits it has learned, and that doesn't export anywhere. Whoever controls that memory controls the IDE, regardless of whether the window looks like a VS Code fork or a dark terminal. It's not an abstract worry, it's the reason I distrust any tool that asks me to tell it everything about my repository in a format only it can read. There's also the question of cost, which nobody mentions in the demos. A long session with an agent that reads half the repository at every step can easily cost more, in tokens, than a traditional editor cost in licenses over a year. By my count, about three times a week I'm the one tallying the model's failed attempts like someone counting coins. That changes behavior. You start hand-writing small things just to avoid spending, and delegating big things just because you're tired. Neither is a good reason. So what's left? An IDE that is smaller where it writes and much bigger where it verifies. Fewer keystrokes, more eyes. I get the feeling we'll end up measuring a tool by how quickly it lets us disagree with it. And chat, once all this settles, will probably look like scaffolding. Useful, ugly, forgotten. I still think about that repeated page. It had two tests covering it, and neither asked the right question.