Programming in the Agentic Era

The Current Shift

For those who recognize the inevitable future of technology, it is no surprise that the role of a software engineer (computer scientist, programmer, whatever you want to call it) has shifted dramatically towards being a manager, rather than an implementer.

Bart Butler, the CTO of Proton, summarized this shift perfectly in his Engineering Manifesto:

“Your job has fundamentally changed. It is no longer to write code, and LLMs are not here to help you write better code faster. Your job is to help the LLM write better code faster.”

This naturally raises the question: how?

A Brief History

As the agentic ecosystem has developed, 3 pieces have become the answer: the harness, skills, and MCPs.

Cursor

When LLMs became capable generalists, for developers there was still something missing. Surely copy/pasting out of the browser was not the future, and of course it was not. Solutions such as Cursor provided the foundation for LLMs interacting with code directly, whether it be through tab-autocomplete or entire multi-file generation. Cursor was the first popular “harness” for an LLM; an interface for the model to interact with your code.

Model Context Protocol

Once models became reliable with tool calling, more users wanted ways to interact with their existing services through their LLM interface. Of course, consumer LLM platforms could write endless lists of custom tools for each product or service users wanted to interact with, but this method was slow for developers, service providers, and end users alike. Developers were required to build out custom tooling, and even custom libraries, to support the services the users wanted. This sluggish pace was annoying for users, and third-party service providers could do nothing about it; the onus was on the consumer LLM platforms.

MCPs solved this problem by establishing a standard. By creating a shared responsibility between consumer agent platforms and third-party services, each party was only responsible for “their part” of the work. The LLM platform developers only needed to make their platforms work with MCPs, the third-party providers only needed to create the MCP for their own services, and the end users reaped the rewards much more quickly. It was a true win-win-win.

The New Harnesses

As models progressed, developers gained a certain level of trust in the code output of LLMs. Cursor’s tab-autocomplete was too slow, and it didn’t make sense for most of the screen real estate to be covered by the code when the user was mostly interacting with the agent.

Boris Cherny (Anthropic) released Claude Code, and a new paradigm was born.

The new harnesses, such as Codex, Claude Code, OpenCode, Pi, and countless others, provided an interface to allow LLMs to interact with computers while keeping the developers’ attention on managing the work. Whether the computer is your laptop, a Mac mini you have tucked under your desk, or a cloud sandbox living in a remote data center, the harness provides the tools required for an LLM to interact with the terminal, edit files, and ultimately create tangible results.

Skills

Now that users could interact with their services and developers could interact with their code, many repeated patterns emerged. Some users would have copy/paste prompts on standby for workflows, conversational methods, or preferences for how they wanted their LLM to perform something.

Skills were introduced as a way to streamline this process. By keeping these repeated prompts on standby for an LLM to access, users no longer had to re-explain the exact way they wanted something done. The combination of skills and MCPs enabled repeated, multi-step workflows to be easily kicked off from any platform with support for the standards, instead of forcing the user to create complex deterministic rules or entirely custom software.

People started creating their own skills, but they also started sharing them with others. Skills.sh became an extremely popular way to share skills you liked, and to find skills that others used to improve their LLM output.

This is where we live today. The ecosystem of harnesses, skills, and MCPs is well established, and it is expected for developers to embrace them. Going back to Bart Butler’s manifesto, these tools enable developers to “help the LLM write better code faster.”

The State of the Art Problem

However, there is still room for improvement.

New models are released all the time. The benchmark scores nearly always increase, and new benchmarks must be developed to test the difference in capabilities. Many times, a skill works great with one model, and gets average results with another.

This difference is exacerbated with harnesses. Benchmarks have expanded to not just cover models, but harnesses too. Comparisons like this show that even with the same model, harnesses impact performance, cost, and speed.

What can we do about this? Currently, it seems the answer is to “just use Opus 5.5.” It is an extremely capable model, and with a Claude Code subscription, you can feasibly use it as a daily driver. Opus is fantastic at an extraordinary number of things, but the API pricing reflects that. What happens when frontier labs stop subsidizing plans like Claude Code and Codex?

For many tasks, smaller and cheaper models can achieve the same result when given enough direction. With the right instructions and verification steps, you can replicate the output of Opus with Sonnet, Haiku, Sol, Terra, Luna, or any number of open-weights models that are currently available. It just depends on the task.

Enter the Workbench

A workbench is a snapshot of your agent configuration: the model, harness, skills, MCPs, environment, instructions, verification tests, and anything else your agent needs to fulfill its responsibilities.

This enables several things: sharable agent configs for teammates or the public, the flexibility to run your agent anywhere, and the ability to create cheap specialists that achieve the same results as expensive generalists.

Workbenches allow you to adjust the levers of token spend, output quality, verification, and security while benchmarking your results, so you know if your output is improving.

Industrialization

For businesses, developing workbenches for your codebase and developers ensures consistent results that meet your quality expectations.

For open source projects, public contributions can meet the quality bar to be seriously considered.

For everyone, we can build systems with outputs we trust.

Throughout history, the biggest gains in efficiency have come from specialization. Be it the assembly line with human specialization, or the industrial revolutions with machine specialization.

Workbenches are here to deliver that efficiency with AI.