I Love Making Things. I Just Don't Particularly Enjoy Making Them.

The distinction between creation and construction is becoming much more important than I ever expected.

I've been thinking about that contradiction for a while. It sounds ridiculous coming from someone who has spent more than twenty-five years building software, much of it as a hands-on engineer. I still consider myself a builder, and I don't expect that to change.

I did build a game once. I didn't start it from nothing. I pulled down a starter game and built on top of it, because constructing one from the ground up was more than I could afford. That is how most of my ideas went. I had products I wanted to create and problems I thought were worth solving, and the limiting factor was almost always the same. I only had so much time available to do the construction.

This year my kid and I are making games, and I am not constructing them. She is the creative director, which means she decides what is fun. A software factory does most of the building. I'll come back to the games, because they are where I worked out what the sentence at the top means.

The more I've worked with AI, particularly over the past year of building software factories, the more I've realized that two things I always considered inseparable are quite different. There is the creative act of deciding what should exist, discovering its shape, and seeing it become real. Then there is the labor required to construct it. For most of my career, the second was simply the price of admission for the first.

I enjoyed plenty of that labor. Solving a difficult problem can be deeply satisfying, and so can watching a system finally behave the way you intended. But those moments were mixed into a great deal of work that wasn't creative at all. Most of the hours went on wiring things together, chasing integration failures, and translating decisions I'd already made into thousands of lines of code.

I've begun to suspect that what I loved most about being a software developer was never the act of writing software. It was the ability to make something exist that hadn't existed before.

Construction was the constraint

We have spent decades treating creation and construction as the same activity. If you wanted to create a software product, you needed people who could write software, and the more ambitious the product, the more of them you needed. We organized teams, funding and delivery around that. Even small ideas had to justify the expense of implementation.

That constraint shaped which ideas survived. Internal tools never got built because the engineering team had more important things to do. Small businesses went on operating around spreadsheets because custom software wasn't economically reasonable for them. I wonder how many product ideas were abandoned because the cost of finding out whether they would work was too high.

We became very good at prioritizing scarce engineering capacity. Every team I have been on had a backlog longer than it could finish, and backlogs, roadmaps and estimates were how we decided which fraction of it could be constructed. Some of those practices were necessary for coordination and quality. Others existed because human implementation was expensive and slow, and we treated them as properties of software engineering when they were adaptations to the people doing the work.

That matters now because the constraint is changing. A capable model already understands a great deal about software construction. Its output is not automatically correct, and there are still real problems around integration, verification and long-term coherence. But the cost of producing an implementation has changed, and the models continue to improve.

My own response was at first the same as most developers'. I used AI to help with the work I was already doing. The agent might produce the code, but I was still directing each task, reviewing each result and deciding what happened next. Eventually that began to feel like an unnecessarily complicated way to use the technology. If the machine can perform the construction, why was I spending my day managing the construction process?

I stopped doing the making

Over the past year I've been building and operating software factories. These are systems that accept work, produce implementations, verify the results, repair failures and promote working software without me supervising each change. I've written about the architecture elsewhere. The short version is that a factory isn't a coding agent with a longer prompt. It is manufacturing infrastructure.

Lately the work has been to take as much project-specific workflow out of that machinery as possible. A project supplies what it knows, what it requires and how its results have to be proven. The factory supplies a production line that can be used again, so that manufacturing another application doesn't mean inventing another development organization around it.

This has changed the work I do. I don't spend my days reading generated code or reviewing individual pull requests. I spend my time on what I want to create, what the system needs to know, which constraints matter and how to establish confidence in the result. When something fails, my first question is about the manufacturing system. I want to know whether verification missed something or the work was poorly defined, and whether the system can learn from it so the next build avoids it.

The games are the plainest example I have. The first one is a small iPad game where you run around a field picking things up and carry them down to the next floor. In August it got a button for reporting a bug from inside the game, and the first real report that came through it was about the tutorial, where two pieces of text were drawn on top of each other. Later the complaint was vaguer. The flow felt off. A rig was built that plays the game by itself, and it measured the first floor. The field was empty three quarters of the time. Nothing was wrong with the engine or the idea. There just wasn't enough on the ground to pick up.

I didn't write the reporter and I didn't write the rig. My part was deciding the game needed them, and deciding what to do about what they found.

I'm still engineering. I'm still making architectural decisions and taking responsibility for what gets produced. But as that separation became more complete, I started thinking less about what I had time to build and more about what I wanted to exist. That is a very different relationship with creation.

What becomes possible when making is cheap?

Most conversations about AI productivity start with the amount of work one person can now perform. Those questions are understandable, but I think they are obscuring a more interesting one. What happens when we stop assuming that the amount of software we can create is limited by how much of it people can construct by hand?

Imagine a small team with strong product judgment, design ability and domain expertise, and access to reliable software manufacturing. They could explore several solutions to the same problem, test them with real users, and learn which one works. They could create specialized applications for communities too small to support a conventional development team, or build the internal tool that had always been too minor to justify attention. A business might finally have software that fits the way it operates.

My own version of that is small. The second game is about a choir of ducks, and it is more my kid's than mine. Its first prototype was a single file, and when the numbers in it were worked through, a person tapping at an ordinary pace would have bought every duck in about two minutes. The prices were redone so the last one takes more like five hours. The third game is only an idea so far. It comes from something we play in the basement with a prop witch's broom for a bat, a beach ball, and stuffed animals for fielders. Neither would have justified the evenings a few years ago.

Many of those experiments will fail, and that is part of the opportunity. We have had to spend considerable effort predicting which ideas deserve to be built because the cost of finding out was so high. When construction is inexpensive, we can learn from experience instead of speculation.

There are still costs. Software needs to be operated, secured and maintained. Distribution doesn't become automatic, and finding people who want something remains difficult. Cheap construction also makes it easier to produce a great deal of software nobody needs. At its peak the first factory I built cost me about a thousand dollars a week in tokens, and the first game is still not on my kid's iPad as a real app.

But lowering the cost of an experiment changes what is worth attempting in the first place. For most of software's history we have had to ration our ability to create, and I'm interested in what happens when we don't have to ration it nearly as hard.

This is not the end of craftsmanship

I suspect a lot of developers liked the construction and not the ideation. They like being handed a difficult problem, working through the implementation, and refining it until it is technically excellent. They don't necessarily want to discover customer problems or decide what should exist. For them coding was never an obstacle between an idea and its realization. It was the activity they enjoyed.

I have compared this before to bricklayers and architects, and I don't mean it as a ranking. A good bricklayer understands the material and takes pride in the laying, and the building is better for it. An architect is interested in what should exist and whether the finished structure does its job. Software bundled both into one role, because you couldn't realize the architecture without constructing it yourself. I turned out to be the second kind, and I only found that out when I no longer had to be both.

So I am not saying every developer is a product person waiting to be let out, and there is nothing wrong with loving the craft. We still have people who make furniture by hand and restore old cars. More efficient manufacturing doesn't remove the pleasure or the value of making something yourself.

But enjoying a craft and requiring everyone to practice it before anything can be created are different propositions. I don't think there is a single correct way to be a builder. I do think we need to reconsider the assumption that personally performing the construction is what makes someone one.

That distinction matters to me because I didn't arrive here as a manager trying to reduce the cost of developers. I spent most of my career as one of those developers. I know what that work feels like, and I understand why people care about it.

The creative work doesn't disappear

It would be easy to take the argument too far and suggest that if AI can manufacture software, creating valuable products becomes effortless. I don't believe that. The duck game was built quickly and its prices were still wrong. The first game ran fine and was still empty most of the time. What a kid will find fun is not something a factory supplies.

In some ways cheap construction makes the remaining problems more visible. Understanding what people need is difficult, and so is designing something that makes sense to them. Software production used to consume so much of our attention that this work happened around the edges of implementation. We gathered requirements, designed a solution, handed it to developers, and evaluated the result after most of the effort had been spent.

If construction is much cheaper, that relationship can be reorganized. A specification doesn't have to be perfected before implementation begins. We can build working examples, learn from them and revise our understanding, because producing the next version is no longer the dominant expense.

That doesn't remove the need for technical expertise. Architecture, security and reliability still matter, and cheaper production creates more opportunities to make expensive mistakes at scale. The difference is that expertise can increasingly be expressed through constraints, standards and the design of the production system, where it used to be expressed through writing every implementation.

It also changes what we spend our attention on. We can ask whether the backlog contains the right ideas, where we used to ask how to get through it.

I think we've been measuring the wrong thing

Looking back, I spent a remarkable amount of my career thinking about how to make software development more efficient. We wanted to deliver more software with the resources available, and improving the mechanics of development was the most direct way to do that. I still care about efficiency. Operating a factory has made me considerably more interested in the economics of compute and verification.

But I no longer think developer productivity is the most interesting measure of progress. What I care about is how much more we can create, and how quickly we can discover that something isn't working and try a different direction.

I don't know what the eventual scale will be, and I don't think anyone can responsibly promise that every kind of software will become trivial to manufacture. The systems I'm operating still fail, sometimes substantially. But I've seen enough to believe the direction is real.

I haven't lost my interest in engineering, and I'm still perfectly capable of writing code when that's the right thing to do. What has changed is that writing code is no longer the activity around which I organize my ability to create. That doesn't make me feel less like a builder. It has made me more interested in building than I've been in years, because the distance between having an idea and finding out whether it deserves to exist has become so much smaller.

For decades our capacity to create was constrained by our capacity to construct. Now that the two are beginning to separate, I think we're going to discover just how many things people have wanted to create and never had the opportunity to try.