I just canceled my annual JetBrains subscription.
That would have been almost unthinkable for me a few years ago. IntelliJ and the rest of the JetBrains suite were exactly the kind of software I was happy to pay for: powerful, polished developer tools packed with features that made writing, navigating, refactoring, and debugging large codebases dramatically easier. For a long time, the IDE was where software development happened for me.
The problem is that I barely open one anymore.
It isn't because I stopped building software. If anything, I'm probably building more software than I ever have. The difference is that I increasingly don't interact with the codebase through an IDE at all. I work through Orgabot and other agent harnesses, where I describe what I want and let agents examine the repository, trace the relevant code, change files, run tests, fix failures, review the implementation, open pull requests, resolve conflicts, and keep going.
My primary programming interface has gradually shifted from a text editor full of source code to a conversation about intent. Natural language has become my coding language.
The IDE Was an Interface to Complexity
For decades, the IDE was the cockpit of software development. As codebases became larger and languages became more sophisticated, simple text editors were no longer enough. Developers needed symbol navigation, intelligent autocomplete, static analysis, refactoring tools, debugging, test runners, database explorers, version-control integration, dependency management, and dozens of other conveniences.
Products like IntelliJ became extraordinarily good at solving that problem, and when I was personally manipulating a codebase all day, those features were worth every penny. But from a higher level, an IDE is really a tool that helps a human understand and manipulate a large collection of source files.
Agentic development changes who is doing that manipulation.
The codebase is still there. The compiler is still there. Git, tests, linters, type systems, debuggers, package managers, and build systems haven't disappeared. What has changed is that I am increasingly not the one operating those tools directly. The agent is.
I Rarely Need to Look at the Code
That realization is what ultimately made me cancel JetBrains. I almost never open an IDE to "code" anymore. Sometimes I inspect a file because I'm curious about an implementation. Occasionally I make a tiny manual edit. I might look at a diff or trace something particularly strange.
But those situations are now exceptions rather than the primary workflow, and when all I need to do is inspect some text, a basic editor is perfectly adequate. I don't need several gigabytes of IDE and an annual software subscription for the handful of times I manually open a source file.
The overwhelming majority of the functionality I used to depend on inside IntelliJ still matters. I still want intelligent code navigation, refactoring, tests, static analysis, and code review. I just increasingly want the agent doing those things instead of me operating each tool myself.
The tools haven't disappeared. They've moved below the abstraction layer where I spend my time.
Natural Language Is Becoming a Programming Interface
Programming languages have always tried, to varying degrees, to make machines more understandable to humans. As we moved away from machine code and assembly, languages became progressively more semantic. We got variables with meaningful names, functions that read like actions, object-oriented structures that modeled real-world concepts, and declarative languages where we could increasingly describe what we wanted rather than every instruction required to accomplish it.
But they were still programming languages.
If you had told me 30 years ago that someday I would spend much of my day coding by speaking or typing plain English to a computer, I would have thought you were spewing science-fiction nonsense. Yet that's essentially what I do now.
Obviously English does not literally replace TypeScript, Python, Go, Java, or whatever language ultimately implements the system. My CPU isn't executing a paragraph I wrote to an agent. But that distinction is becoming less important from the human side of the stack.
Programming has always involved translating human intent into something a machine can execute, and over time we have repeatedly moved the human side of that translation upward in abstraction. Humans once manipulated machine instructions directly. Assembly gave those instructions names. Higher-level languages let us describe algorithms without caring about registers. Frameworks let us describe applications without implementing every primitive. Infrastructure-as-code let us describe entire environments rather than manually configuring servers.
Agents add another layer. Instead of expressing every implementation detail ourselves, we can increasingly express the desired outcome:
- Add OAuth support for this provider.
- Find why this API endpoint occasionally returns stale data and fix it.
- Refactor these services so they share the same authorization layer.
- Implement this GitHub epic and all of its sub-issues.
- Review the resulting pull requests for security problems and merge them when they're ready.
Those are programming instructions. The output may ultimately be thousands of lines of conventional source code, but I didn't personally write most of those lines. I described the system I wanted, established constraints, evaluated the result, and let machines translate my intent into the languages they need.
Thirty years ago, the idea that plain English could sit at the top of a software-development stack sounded like science fiction. Now it's my normal workflow. Natural language isn't replacing programming languages underneath the system; it's becoming the programming language I use.
The Valuable Skill Was Never Really the Language
There is still enormous value in having experience with many programming languages. Knowing how different languages model types, concurrency, memory, state, interfaces, errors, and abstraction gives you a much better mental model for evaluating what an agent produces. That experience helps you recognize bad architecture, unnecessary complexity, brittle interfaces, and implementation choices that are likely to become problems later.
But I think the more important skill is experience building complex systems. Languages are ultimately a means to an end.
The hard parts of software development were never just remembering syntax or knowing which library call to make. The hard parts are deciding where boundaries belong, understanding how components should interact, anticipating failure modes, managing state, designing for change, making tradeoffs, debugging emergent behavior, and knowing when a seemingly reasonable implementation is going to collapse under real-world complexity.
Those skills survive the transition to agentic development, and they may become even more important. If an agent can produce competent TypeScript, Python, Go, Rust, or Java on demand, then fluency in a particular syntax becomes less scarce. What becomes more valuable is knowing what should be built, how it should fit together, what constraints matter, and whether the result is actually good.
That is also why I don't think the future belongs only to people who can prompt well. A clever prompt is not a substitute for engineering judgment. Someone with decades of experience building systems can look at an agent's plan and recognize that the boundaries are wrong, the data model will not scale, the security assumptions are weak, or the proposed architecture is solving the wrong problem entirely.
The agent can increasingly handle the translation from intent into implementation. The human still needs to understand the system.
That feels like the real shift to me: the programming language is moving farther down the stack, while architecture, judgment, orchestration, and systems thinking move farther up.
Cursor and Windsurf Don't Solve This Either
The obvious response is that maybe traditional IDEs are fading, but AI-native IDEs like Cursor and Windsurf are the future. I don't think so.
Cursor and Windsurf are still fundamentally IDEs. They assume that the center of software development is a human looking at source files, navigating a repository, selecting code, reviewing diffs, and interacting with AI from inside an editor. That already feels like an intermediate step.
If I am working through Orgabot or another agent harness, I don't need an AI-enhanced editor any more than I need a traditional one. I am not sitting there waiting for autocomplete, highlighting a function and asking AI to rewrite it, or manually hopping between files while an assistant watches over my shoulder.
I give the agent the job.
The agent can open the files, search the codebase, inspect dependencies, run commands, read test failures, modify twenty files, spin up sub-agents, review the resulting changes, and keep iterating until the task is complete. At that point, putting AI inside an IDE feels almost backwards.
The goal is not to make humans dramatically faster at editing code. The goal is to require humans to edit dramatically less code.
That distinction matters. Cursor and Windsurf may be better cockpits for AI-assisted programming, but the direction I'm moving in increasingly doesn't require a cockpit at all. The primary interface becomes the mission, issue, specification, or conversation. Source code is still critically important, but it becomes an artifact produced and manipulated underneath that interface rather than the place where I spend my day.
So when I canceled JetBrains, I didn't replace it with Cursor or Windsurf. I replaced the IDE with the agent.
I Don't Want to Be the Programmer Anymore
Orgabot pushed this one step further for me. When I use Orgabot to create an application or organization, I am not approaching the work as a software engineer with a better set of coding tools. I am approaching it from the CEO's perspective.
A CEO does not open a source file and fix a function. A CEO defines the objective, assigns responsibility, makes sure the right people or agents are working on it, reviews whether the result matches the goal, and changes the organization when the process breaks down.
The orchestration itself can also be delegated. A CEO might tell a CTO to deliver a product, and the CTO coordinates engineering, security, infrastructure, design, and review underneath that mandate. The CEO does not need to know which file contains the authentication middleware.
That is increasingly how I build software. I might say:
- Build this product.
- Fix this epic and all of its sub-issues.
- Investigate why this system is failing and resolve the root cause.
- Have security review the implementation before it ships.
- Reduce the cost of this workflow without degrading quality.
Those instructions create work that eventually results in code, but code is several layers below the interface where I am operating.
That leads to a useful rule: if the CEO is reviewing or editing source code, there is probably a broken workflow somewhere underneath them.
Maybe the engineering agent failed. Maybe the review process is weak. Maybe the organization does not have the right role or skill. Maybe the escalation boundaries are wrong. Whatever the cause, the answer should not be to drag the CEO down into the implementation layer indefinitely. It should be to fix the system so that the organization can handle that work properly next time.
This is also why I have little interest in replacing IntelliJ with Cursor, Windsurf, or another AI IDE. Those tools make a programmer more effective inside the coding layer. Orgabot is trying to make the coding layer something I rarely need to enter at all.
The IDE May Be Becoming an Implementation Detail
This is why I think we're entering a post-IDE era.
That doesn't mean IDEs disappear tomorrow, and it doesn't even mean graphical code editors disappear. There will always be times when looking directly at source code is the best way to understand a problem. But I think the IDE is losing its position as the primary interface between programmer and software.
The agent harness is becoming that interface, and that creates an awkward strategic problem for traditional IDE companies and AI IDE companies alike. The obvious response has been to put AI inside the IDE: add a chat panel, add autocomplete, add an agent mode, let the AI modify several files at once.
Those are useful improvements, but I wonder whether they have the architecture backwards.
Maybe the future isn't an IDE with an agent inside it. Maybe it's an agent with an editor inside it.
The agent becomes the environment. The repository, terminal, browser, debugger, editor, tests, CI system, issue tracker, and deployment infrastructure are tools available to that environment when needed. Most of the time, the human stays one level above them.
I Didn't Cancel JetBrains Because JetBrains Got Worse
This distinction matters. JetBrains didn't lose me because IntelliJ became bad software. Quite the opposite. IntelliJ remains an astonishingly capable piece of engineering.
I canceled because my workflow changed so dramatically that I no longer need 99 percent of what it does, and that's a much bigger threat. The hardest competitive problem isn't when somebody builds a better version of your product. It's when the user's behavior changes enough that the product category itself becomes less important.
For years, I wanted the best possible environment for editing source code. Then I wanted the best possible environment for directing agents that edit source code. Increasingly, even that undersells where this is going.
I want the best possible environment for creating organizations of agents that can take responsibility, delegate work, review one another, escalate when necessary, and produce software without requiring me to descend into the implementation layer.
The IDE is not the center of that world. It is a tool one of the agents might use.
After years of living inside IDEs, I think I may have finally left them behind.
Top comments (0)