Building Software for Agents

My key thesis is that it’s useful to think from the agent’s point of view.

We are not just building software for humans anymore. We are building software for agents.

From human-operated software to agent-operated workflows

The reason this matters is that agents are starting to complete more of the workflow that humans used to do. They can browse files, write code, implement changes, view documents, run analysis, and produce output across an entire workflow.

In theory, that sounds very powerful. In practice, at least right now, it still doesn’t always feel smooth.

One reason is that web browsing is still hard for agents to do efficiently. Even with powerful tools like Claude Code or Perplexity, browsing through pages, interpreting visual information, clicking around, and reasoning through what to do next can be slow. For example, I’ve found that when agents try to do shopping, they are often much slower than I am when I just do it myself on Amazon.

That tells us something important: the problem is not just model capability. It is also the interface.

Human Interface vs Agent Interface

The website was designed for humans. It is visual, indirect, and full of noise. Humans are good at quickly scanning pages, ignoring irrelevant information, and jumping to what matters. Agents can do this, but it is expensive and slow.

One way around this limitation is to give it tools that are designed for agents to use directly.

From imperative programming to declarative programming

What AI really needs is context. With the right context, it can solve the problem very well. So the engineering problem becomes: how do we give the AI the right context? How do we expose the right tools? How do we let the agent work in the environment it likes to work with?

This is a bit of a reversal.

Instead of saying, “Here is the context I prepared. Think exactly in this specific way,” we can say, “Here is the problem I want to solve. Go figure out what context you need and how to solve it.”

In that sense, we may be moving from an imperative programming paradigm toward a declarative programming paradigm.

The old model is: tell the computer exactly what to do, step by step.

The new model is: describe the problem, define the goal and constraints, and let the agent figure out the implementation.

This connects to a broader lesson from AI history.

There is an article called The Bitter Lesson by Richard Sutton. For almost anyone doing research in machine learning or AI, it is probably something they should read at least once. The basic idea is that over the long run, AI progress tends to come from general methods that scale with computation, search, and learning, rather than systems that rely too heavily on hand-built human knowledge.

The same pattern may be happening again with agents.

We should be careful not to over-structure the solution. Instead, the structure may need to move elsewhere: into the environment, the tools, the context, and the validation.

What if the spec becomes the main artifact?

There is a more recent idea that points in this direction: a software library with no code. The proposal is that, instead of writing implementation code, what you really need is a spec.

By spec, I mean a clear instruction of what you want the system to do. If the coding agent is powerful enough, it can read the spec and implement the solution for your particular use case, on your system, in whatever language is needed.

I think this is interesting, especially for the early stage of software or for relatively bounded tasks. But I don’t think we should take the idea to the extreme. Human language is ambiguous by nature. Code is much more rigid, and that rigidity is useful. When you are structuring important business logic, you often need that precision to make sure there is no ambiguity in the system.

So I’m not saying code disappears. I’m saying the boundary may shift. In some cases, the durable artifact may become the spec. In other cases, especially where the business logic is subtle or the system is large, code remains the better structure.

The boundary between spec and code

But the direction is interesting: people are already exploring what happens when the spec becomes more important than the implementation.

As programmers, we don’t want to repeatedly do the same thing again and again. A lot of the work around tickets is mechanical. Read the ticket. Find the repo. Understand the acceptance criteria. Pull in the business context. Make the change. Test it. Submit the pull request.

What really matters is writing the right spec and defining the right acceptance criteria. So this brings us back to the spec idea: to what extent can we write a very good spec, turn that into code, and validate whether it works?

That is the direction I’m testing.

You are not paid for lines of code. You are paid for judgment.

At this point, it is natural for people to feel threatened. If AI can do the implementation and submit the pull request, is it replacing the programmer?

I don’t think that is the right way to think about it.

You are not paid for how many lines of code you write. If a company measures programmers by lines of code, that is not a great company. You are paid for judgment.

The best programmers (and the best leaders in any domain) make better decisions under uncertainty and under stress. They know what should be built. They know which trade-offs matter. They can tell when something is technically correct but strategically wrong. They can navigate ambiguity.

That is a very human-level ability and I don’t see AI replicating it.

Especially when you push things to the highest level, the difference becomes very clear. AI can help with implementation, repetitive workflows, reading context, and generating pull requests. But humans still matter for judgment, taste, prioritisation, ambiguity, and knowing what should be built in the first place.

The future engineering skill is not just coding. It is designing agent-ready systems.

That means writing better specs, building better tools, creating better context, designing better validation, and knowing where human review needs to happen.

We are not just building software with AI.

We are building software for AI.