I’ve spent 25+ years building things: software, systems, teams, culture. For most of that time, getting from idea to usable product meant implementation, and implementation ate everything. That might mean learning a new framework or allocating resources or waiting six months for a budget someone else controls. Most ideas died on the vine because of that constraint.

Ancient technologists (c. Y2K) will tell you to use well-known patterns and stay away from being too clever. That usually made implementation more tedious and more likely to miss its mark. After much divining and estimation, the idea would stay just that, not because it was a bad idea, but because implementing it into something real required more time, expertise, coordination, or permission than the idea could bear.

AI is shrinking that gap. Users, domain experts, junior programmers, senior engineers all can describe a problem or outcome to an LLM and end the day with a working product. Not a wireframe or a PoC or a story in someone else’s backlog, but a genuine tool that answers a question, organizes a project, removes a tiny irritation, or teaches you enough to move to the next step.

This is easy to understate because it arrived amid so much noise. We are accustomed to hearing that new tools make work faster, that they will disrupt professions, that they may change who gets hired or what skills command a premium. Those questions matter. But they can obscure a simpler and more immediate change: more of us can act on an idea without waiting for all of the conditions that formerly stood between wanting a thing and making it. That is an expansion of agency.

Simon Sarris wrote that programming had retained a permissionless quality that much of modern life had lost: “You don’t have to ask anyone. You don’t have to get a building permit or be a professional. You can just create.”

His point wasn’t that programming was useful or lucrative, but that software let a person act on the world before an institution decided they were qualified to do so. You could begin before you were ready, and the thing you wanted to make could become the reason to learn.

The new tools widen that invitation.

They don’t erase the value of knowing how systems work, or make experience irrelevant. But they let a domain expert build a small tool instead of just describing the problem to someone else, let a curious person follow an idea past a sketch, and let a programmer chase an uncertain approach that would once have been too costly to justify.

The threshold has not disappeared. It has moved.

A structure that stands

Sarris, who designed and part-built his own house, was right that software never had a permit office. But buildings still have to stand, permit or no permit. What’s changed is that the cost of construction collapsed while the physics stayed. A building has to be safe, usable, and possible to maintain, and it has to serve the people who enter it within the constraints of money, materials, place, and time.

But nobody thinks those facts exhaust the work of architecture. We care whether a building makes sense to live or work in. Whether its form serves its purpose. Whether it helps people understand where they are and what they can do there. Whether it makes ordinary life easier or harder. Whether it can change without becoming hostile to the people who depend on it.

When anyone can raise a structure in an afternoon, the world fills with structures. The scarcity shifts from can we build it to should this exist.

Software also has a floor: it must function, and it must be secure enough, reliable enough, comprehensible enough, and possible to operate and change. A system that does not meet those obligations has failed regardless of how elegant its abstractions may be. For much of software’s history, reaching that floor consumed most of the available effort. Getting the structure to stand was an accomplishment. A conventional pattern, an adequate interface, a familiar architecture: these were often not failures of imagination. They were rational responses to the price of implementation.

There was only so much time to learn a new technique, prototype a new approach, test it against reality, and persuade other people that the experiment was worth the risk. Often the sensible choice was the approach everyone already understood.

That constraint is loosening.

It is easier now to follow a hunch far enough to find out whether it contains anything: build a narrow prototype, compare several representations of the same problem, ask whether the conventional design is carrying machinery the problem doesn’t need.

This doesn’t make every idea good, or every experiment worth keeping. What it does is make exploration more approachable.

This matters because a great deal of what we call taste develops through comparison. Comparison teaches us to see the difference between two things that both work. One introduces concepts without earning them; another makes an important constraint visible. A familiar solution turns out to feel safe because it is familiar, not because it fits. An unusual approach turns out to be simpler than the standard pattern, because it lets the shape of the problem show through.

Taste doesn’t give us the right to dismiss someone else’s work, only the habit of asking more of our own.

After the first version

Simon Sarris writes that “learning is naturally the consequence of doing.” That still feels right. These tools do not overturn that order. They make more doing possible.

They let us build a script that renames the files some vendor insists on mangling, sketch a workflow before we know whether anyone else needs it, or pursue a question too small, strange, or uncertain to justify a team, a budget, or a year of planning. They also make it possible to learn from artifacts rather than only from abstractions.

This is not a lesser form of making because the first version comes quickly. A rough artifact can answer questions that discussion cannot. It can expose an assumption, reveal an unexpected use, or turn a vague dissatisfaction into something concrete enough to improve.

The first version is not the end of the work. It is an invitation to look again. What did we actually make? What did it make easier? What did it make harder? What did it assume about the people who might use it? Which parts have the shape of the problem, and which parts merely have the shape of the tools available to us?

Those questions are where judgment begins.

Judgment isn’t the ability to hand down a disapproving verdict after the fact so much as the growing ability to see a thing in context: recognizing when a solution has answered a different question than the one we meant to ask, noticing when it has grown larger than the need, and telling a useful generalization apart from a convenient way of avoiding a hard decision.

As implementation becomes more approachable, the absence of judgment can become easier to conceal. A plausible artifact can arrive before we have decided what we wanted it to be. Familiar forms can make a needless addition feel responsible. An answer that works can appear complete before we have asked what it will ask of the people who use, maintain, or inherit it.

The point isn’t to grow suspicious of the tool or timid about making things, but to stay awake while we make them.

The work of seeing

That is where the old craft may have something important to teach the new one.

Before an experienced programmer can recognize that a change is wrong, excessive, or oddly shaped, they have usually built up a store of remembered encounters. Things that failed in production. Interfaces that seemed obvious until a second caller arrived. Configurations that made one case flexible and every other case harder to understand. Designs that looked elegant in a review and became exhausting to live with.

Some of that memory can only come from time and responsibility. We should not pretend otherwise.

But more of the practice can become available earlier than it used to be. We can learn by making an expectation visible before an artifact arrives. We can ask, before we build: what should change, what should remain untouched, what would count as evidence that this helped, and what would surprise us?

We do not need to predict every line of code. We do need enough clarity to recognize when the work has moved beyond the thing we meant to make.

That is a form of attention. It makes the difference between intention and result instructive rather than merely inconvenient.

Perhaps the artifact reveals that we misunderstood the system. Perhaps it exposes a decision we had never made explicit. Perhaps it suggests an alternative that is genuinely better than the first thought we had. Perhaps it shows us that the first thought was right after all.

Each possibility teaches us something. Learning to see the difference is the point.

The same is true of conversation. Explaining an idea to another person exposes the weak point that only appears when you make it legible. Asking a machine for alternatives helps you notice what each form makes visible and what it hides. Letting an unfamiliar strategy challenge our habits helps too, so long as we don’t assume unfamiliarity is itself a virtue.

That’s how agency becomes more than motion: a way of learning to choose.

What we do with the gift

The gap between the idea and the usable thing is shrinking. That is the gift, and the gift compounds: every cheap iteration teaches us a better question to ask on the next one. This is a real opening for anyone who builds things: make something that did not exist for you before.

Learn from things that work and especially from things that do not work. The problem you solved should make you feel a sense of accomplishment. It should make you want to dive deeper into it. Discover the next bottleneck. Show it to your friends and colleagues. Is it a minimum viable lovable product?

A building must meet codes and basic safety before anyone can live in it. But the architect’s work is not done simply by making it stand. Neither is ours. This is what we do with agency.

Afterword

This essay began as a response to Simon Sarris’s “The Most Precious Resource is Agency,” a 2021 essay he later revised and expanded as “School Is Not Enough.” His writing on programming as a permissionless culture, and on learning through doing, gave this essay its starting question.

Read the original essay and the expanded version.

This is the first in a series. Next: what writing down your expectations before the machine builds anything buys you.