I keep thinking about a strange kind of software demo.
An agent is given a blank voxel world and a few actions. It can place a block. It can place a box, a cylinder, or a sphere. It can inspect the space, choose from a small material list, clear the world, and mirror a shape.
Then someone asks it for a castle.
The result is not a single pre-programmed castle. The agent plans towers, walls, arches, windows, and a central keep. Ask again and the shape changes. Ask for a bridge or a pavilion and it starts composing those instead.
The obvious reaction is that the model is doing something magical.
The more useful reaction is quieter.
The application did not contain a castle algorithm. It contained a small world and a small vocabulary for acting inside it.
That difference matters because it points to a change in what builders need to get good at.
The spectacle hides a small interface
The visual result looks complicated, but the interface behind it is almost boring.
A coordinate.
A material.
A few higher-level shapes.
A way to clear the workspace.
A way to inspect what exists.
That is the point.
The agent is not allowed to reach into the renderer and do anything it wants. It is given a set of handles. Those handles are simple enough to understand, but expressive enough to combine.
A box is more useful than asking an agent to place thousands of blocks one by one. A mirror operation is more useful than making it reinvent symmetry every time. A world-info call is more useful than hoping it guesses the scale of the environment.
These are not glamorous decisions. They are interface decisions.
But they determine whether the agent can do useful work or only produce an impressive-looking mess.
I think this is where a lot of AI coding discussion gets confused. We see the output and talk about prompting. We see the model produce a page, a workflow, or a prototype and assume the skill is learning the right sentence to ask for.
Prompting matters. But the deeper leverage is often upstream.
What can the agent observe?
What actions can it take?
What does each action mean?
What is impossible by design?
What feedback tells it whether it is making progress?
That is the system.
The code did not disappear
There is a seductive story about AI coding: soon there will be almost no code, because the model will write everything.
The voxel demo contains a small truth inside that story. The custom code can get surprisingly small when a capable model supplies planning, pattern recognition, and composition.
But the engineering does not disappear. It changes location.
Instead of spending every hour encoding a specific outcome, you spend more time deciding what the environment should make possible.
You define primitives.
You choose the level of abstraction.
You decide which operations are cheap, which are forbidden, and which need confirmation.
You build a feedback loop so the agent can see the consequences of its actions.
You decide what a successful result looks like before the system starts improvising.
This is not less responsibility. In some ways it is more responsibility, because a bad primitive gets reused at scale.
If the only tool available is a raw database write, the agent will eventually make a raw database mistake. If a tool has broad permissions and a vague description, the model will make the most plausible interpretation it can. If success is never checked, a fluent explanation can hide a broken workflow.
The shorter codebase can create a larger design surface.
Skills are the taste layer
The most interesting layer in this kind of system is not the renderer. It is the skill layer.
A skill can be a plain Markdown file that says how a particular kind of result should feel. A dragon might need a long arcing neck, wings wider than its body, and visible flame. A castle might need slender towers and a clear central keep. A world-building skill might say: inspect the world first, build the big mass first, then add detail, and use higher-level shapes before individual blocks.
None of this gives the model new intelligence in the abstract sense.
It gives the model a clearer standard inside a particular environment.
That is why I think of skills as a taste layer.
Tools answer: what can I do?
Skills answer: what does good look like here?
The distinction matters outside of demos too.
A content workflow can have tools for reading a source, drafting an essay, creating an image, and preparing a post. Without a skill layer, the system may still produce plenty. It may not know what should be cut, what must be verified, what belongs in private notes, or what would embarrass you in public.
An infrastructure workflow can have tools for creating resources and reading logs. Without a skill layer, it may not know the order of operations, the rollback rule, or the evidence required before calling a deployment safe.
Capability is not judgment.
More tools do not automatically produce better work.
The new bottleneck is legibility
When people say that code is getting cheap, I do not hear that software is getting easy.
I hear that legibility is becoming more valuable.
A good agent environment should be easy for a human to reason about as well as easy for a model to use.
A person looking at the tool list should understand what each action changes. They should understand the scope of the permissions. They should be able to predict the cost of a loop. They should know where the result will appear and how it will be checked.
That is not bureaucracy. It is how you keep speed from becoming hidden risk.
The more capable the model is, the more important this becomes. A weak tool can only do limited damage. A powerful tool with a vague contract can create a large, confident failure very quickly.
So the goal is not to give an agent every possible action.
The goal is to give it the smallest set of actions that let it do the job well, then make the consequences visible.
That is a much more demanding design problem than adding another integration.
Five questions before you add another agent tool
When I look at an agent workflow now, these are the questions I want to ask before I add more capability.
What is the smallest useful primitive?
Do not begin with the most powerful endpoint. Begin with the smallest action that is safe, understandable, and composable. A narrow tool is often easier to evaluate and harder to misuse.
What does the agent need to observe first?
Good action depends on state. Give the agent a way to inspect the relevant world before asking it to change that world.
What should be a higher-level operation?
If the same sequence appears again and again, turn it into a stable primitive. Do not make the agent rediscover basic batching, symmetry, validation, or rollback in every run.
Where does taste live?
Write down the preferences, order of operations, quality thresholds, and exclusions that define a good outcome. Keep them close to the tools so they guide work instead of becoming a forgotten document.
How will failure become visible?
A tool call succeeding is not the same as the task succeeding. Decide what evidence the system needs before it reports completion.
These questions sound less exciting than asking an agent to build a castle.
They are also the questions that survive after the demo ends.
What I want to learn next
I do not think the lesson is that builders should stop learning how software works.
I think it is the opposite.
When an agent can write the local implementation, the surrounding system becomes easier to ignore and more important to understand. Permissions, state, interfaces, costs, observability, and evaluation stop being background details. They become the work that makes an agent useful in the real world.
The builder of the next few years may write fewer lines of application logic by hand.
But they will need a sharper eye for the world they are creating around the model.
The best agent systems will not be the ones with the longest tool lists.
They will be the ones where a human can point to every primitive, every boundary, and every quality rule and say: this exists for a reason.