For the past few weeks I’ve been building my own development environment, partly because I wanted to solve some frustrations I’d been having with Claude Code and Codex, but mostly because I enjoy building my own tools. The original plan was fairly modest. Better context management. Somewhere permanent for project memory to live instead of watching the model rediscover the same information repeatedly. Better tracing so I could see what the agent was doing while it wandered off to edit half the repository. Nothing particularly revolutionary.
Somewhere along the way, though, I realised I wasn’t really building another IDE.
Typing
I’d been using the word ‘IDE’ without thinking very much about what it meant. Integrated development environment. We’ve all been saying it for years, and like many names that survive long enough, the description becomes the thing. Visual Studio Code is an IDE. PyCharm is an IDE. Eclipse was an IDE. We all know what one looks like: file tree on the left, editor in the middle, terminal at the bottom, tabs across the top, extensions down the side. That’s just what software development looks like.
Except that’s only what software development looked like when the job of the developer was to type.
Almost every feature inside an IDE exists because someone assumed there’d be a human sitting in front of a keyboard writing code one line at a time. Syntax highlighting exists because humans read code, autocomplete because humans type slowly, linters because we make mistakes, and search because we forget where things are. Even something as ordinary as indentation guides assumes there’s a person staring at a screen trying to keep track of nested code blocks.
Every improvement we’ve made to the IDE over the last thirty years has really been an improvement to typing.
But I don’t think typing is the job anymore.
Intent
I realised this a few days ago while recording a voice note describing a feature I wanted to build. I wasn’t anywhere near my computer. I wasn’t looking at the repository, nor even even thinking about code. I was describing a problem in plain English, the way I’d explain it to another engineer over coffee, and by the time I got back to my desk the model already had a plan, knew which files it wanted to inspect, had suggested a few implementation approaches, and was waiting for me to decide between them.
At no point did I write a single line of code.
That’s becoming surprisingly normal. Some days I barely touch the keyboard apart from approving changes and nudging the model back on course. The implementation, searching, editing, refactoring, running tests and fixing lint errors increasingly belong to the machine. I now spend far more time deciding what should exist than I do deciding how to write it.
Which is how it should be.
Context
The things I now find myself adding to my own environment would have made very little sense in an IDE designed twenty years ago. I’m thinking about persistent project memory, decision logs, reusable skills, execution traces and structured rules because those aren’t things that help a human type. They help an AI reason. If an agent is going to make changes to a system, the most useful thing I can give it isn’t another way to search the repository. It’s context. Why does this feature exist? Which decisions are already settled? Which parts of the application are fragile? What happened the last time somebody changed this workflow? Which files were touched when this button was clicked? An execution trace answering those questions is infinitely more useful than asking the model to grep another hundred files and hope it stumbles across the answer.
The same thing has happened with documentation. People often assume AI makes documentation less important because the model can simply explain the code to you. I think the opposite is true. As code becomes easier to generate, understanding becomes the scarce resource. Repositories are going to grow faster than any team can keep in their heads, and unless the reasoning, architecture, constraints and trade-offs are written down somewhere permanent, every new model is going to waste time reconstructing context that already existed yesterday.
Newbies
All of this changes how we learn coding. A junior developer used to build intuition for how software breaks by wrestling with a broken loop until it made sense, trying to visualise the problem, maybe scratching out thoughts on a whiteboard. If the agent writes the loop, runs it, and fixes it before that junior developer has even opened the file, where does the intuition come from now? Nostalgia for debugging by hand isn’t the answer. The instinct has to form somewhere else instead, in reading an agent’s execution trace and spotting the exact moment its reasoning went wrong, in catching a contradiction in a spec before it becomes six hundred lines of confident, incorrect code. That’s a different skill from the one my generation learned on, and the curriculum hasn’t caught up.
I spent years teaching cohorts of a hundred, sometimes two hundred undergraduates web design, programming, networking, databases, and OS design, and a huge share of every semester went to syntax: semicolons, indentation, the difference between a for loop and a while loop. Very little of that prepares anyone for the job I’ve just described. A computer science curriculum built for an AIDE would spend far less time on how to write a for loop and far more on how to specify one precisely enough that a machine can’t misread it, how to read an execution trace like a native language, how to hold five agents’ worth of output to a single architectural standard. Somebody’s going to have to write that curriculum.
Then there’s collaboration, which I think changes even more dramatically.
Collaboration
Today’s workflow assumes software is largely an individual activity with occasional moments of teamwork. I work in my editor. You work in yours. We push our changes to GitHub, review each other’s pull requests, merge them, and repeat. That works because humans are relatively slow. The amount of code produced each day is manageable enough that review becomes the coordination mechanism.
That assumption doesn’t survive contact with AI.
Five developers no longer produce five developers’ worth of code. They produce whatever five developers and their agents can generate together, which could easily be ten or twenty times as much. Suddenly the bottleneck isn’t implementation, but coordination. It’s making sure everyone is building towards the same product, sharing the same context, and making compatible architectural decisions before thousands of lines of perfectly valid, thoroughly tested, completely incompatible code appear in the repo.
That’s why I don’t think the next development environment will be centred around the editor at all. I think it’ll be centred around the planning workspace sitting above it. The editor becomes one panel inside a much larger system that captures intent, stores context, records decisions, coordinates agents, surfaces traces, updates documentation and gives both humans and machines a shared understanding of what they’re building together.
AIDE
At some point I stopped calling what I was building an IDE and started calling it an AIDE: an artificial intelligence development environment. Or maybe an augmented intelligence development environment. Not just because it has AI built into it; every editor will eventually have that. The difference is an AIDE starts from a different assumption: the person sitting in front of the screen is no longer there primarily to type. They’re there to think, plan, review, coordinate, and exercise judgement while increasingly capable agents take care of the mechanics.
The IDE solved the problems of human code production remarkably well. The AIDE solves the problems of human and artificial intelligence working together.