For a long time, extensibility was a feature for power users.
Most people used software as it was shipped. A smaller group customized it through settings, scripts, plugins, themes, macros, or configuration files. An even smaller group went further and treated the program as a platform: something to inspect, bend, and extend until it fit the way they worked.
That last group was always limited by the cost of programming. Even when an application exposed a beautiful extension system, using it still required time, skill, documentation, patience, and a willingness to maintain the result. If you wanted your editor to show some extra type information, your browser to add a button to a page, or your desktop to display a small custom widget, you had to write the code yourself. For many people, the friction was too high. The idea stayed an idea.
Agentic coding changes that.
The important shift is not that everyone becomes a professional programmer. The shift is that a much larger number of people can now describe a small piece of software they want and have a coding agent build a first version. That matters most when the target program is already designed to be extended.
Want a browser extension that summarizes the comments on a Reddit post? That is now a reasonable personal project. Want a small GNOME widget that shows French verb conjugations while you study? Also reasonable. Want a command in your editor that gathers the current project state, opens the right worktree, and starts an agent with a structured prompt? Reasonable.
These are not startup ideas. They are not products. They are the sort of tiny, personal, context-specific tools that would usually die before implementation because the payoff did not justify the setup cost. Coding agents lower that cost dramatically.
Coding agents lower the cost of small personal extensions, making more niche tools worth building.
This makes extensible programs more valuable, not less.
If software is a sealed box, the agent can only work around it. It can automate the UI, generate files from the outside, or write glue code that sits nearby. Sometimes that is enough, but it is fragile. The best results come when the program exposes a real surface for extension: documented APIs, stable hooks, scriptable commands, readable state, configuration, events, and conventions that make local changes feel native.
Agents are most useful when software gives them real extension points instead of forcing them to work from the outside.
The more a program can explain itself, the more useful an agent becomes inside it.
This is why Emacs feels newly modern to me.
Emacs is old enough that it should, by normal software fashion rules, feel like a museum piece. Instead, its core idea looks better every year. Its famous description is: "The extensible, customizable, self-documenting real-time display editor."
That sentence is almost a specification for the kind of software that works well with coding agents.
Extensible means the program expects to be changed. Customizable means users are allowed to make those changes serve their own workflow instead of waiting for a product team to bless a generic version of the feature. Self-documenting means the system carries enough information about itself that a user, and now an agent, can discover how to interact with it.
The last point is easy to underestimate. Documentation is not only for humans reading a manual in a browser. It is also material for tools. If commands, variables, functions, keymaps, modes, and hooks are inspectable, an agent has something to grab onto. It can ask the environment what exists. It can generate code that follows local conventions. It can connect a new behavior to the program in the way the program expects.
I have felt this contrast directly.
Years ago, when Facebook's Flow type checker was still common in JavaScript projects, I wanted Emacs to show Flow type information through eldoc. The idea was simple: put the type near the code while I worked. Implementing it was not simple. I had to understand the editor integration, the Flow command-line interface, the shape of the responses, the timing, the display behavior, and the Emacs Lisp needed to connect it all. It took far longer than the feature felt like it should.
Recently, I had a different problem. Agentic coding had made git worktrees part of my daily workflow, and I wanted an Emacs interface for managing several parallel agent tasks. I wanted to see which worktrees existed, which branches they were on, which agents were running, and which tasks were waiting for review. I did not want to leave Emacs for a separate app if the rest of my workflow already lived there.
So I built this:
The difference was not that I had suddenly become a much better Emacs Lisp programmer. The difference was that I could use an agent to help design and implement the tool inside an environment that was already meant to be extended. In a day, I had something useful enough to become part of my daily routine.
That is the future I find interesting: not only AI-generated applications, but AI-assisted adaptation of the applications we already use.
This suggests a different standard for software design. A program that wants to age well should not only ask, "What features should we ship?" It should also ask, "What can users and their agents safely build here without asking us?"
That means extension points should be treated as first-class product surfaces. APIs should be stable and documented. Configuration should be inspectable. Internal concepts should have names. Commands should be composable. State should be available in structured forms. Plugins should be easy to create, test, and share. The program should make small local changes cheap.
This does not mean every application needs to become Emacs. Many users still want software that works out of the box and never asks them to think about extension points. Most should get exactly that. But the presence of coding agents changes the economics around the long tail of personal needs. Features that were once too niche to build into the product can now be built by the people who need them, if the host program gives them a place to stand.
The winners, I think, will be programs that expose enough structure for agents to help without requiring users to become experts in the whole codebase.
In the pre-agent world, extensibility mostly rewarded the rare user who had both the desire and the ability to program their tools. In the agentic world, that group gets much larger. More people will be able to say, "I wish this program did one small thing differently," and then make it true.
That makes extensibility less like a power-user luxury and more like a core property of durable software.
Agentic coding is changing the unit of software production: the developer increasingly designs, supervises, and improves a factory of connected build, audit, deployment, and operating systems.
Agentic coding changes the developer's job: less uninterrupted implementation, more dispatching, reviewing, and switching well between parallel streams of work.
Why the next phase of AI development is less about perfect prompts and more about designing systems that plan, validate, recover and iterate.