A New Approach to Quality

Chapters 13 to 15 gave you the ability to create: build by speaking, think with the machine, judge the product rather than the code. This chapter asks the question those abilities make unavoidable. If you can build almost anything, what is worth building — and what makes the result any good?

For most of the history of software, that question was partly answered by difficulty. Building was hard enough that the act of building something working was itself a distinction. That is changing. When competent software becomes something many people can produce, producing it stops being enough to set anyone apart. Something else has to.

I find that prospect exciting rather than threatening. But it does require a different idea of quality from the one most programmers grew up with.

When everyone can make the clothes

Fashion is a useful place to start, because it settled this question long ago.

Making a garment is not difficult. The machinery, materials and skills are widely available, and an enormous number of people and factories can produce well-made clothes. Yet being able to make a garment does not make it fashionable, distinctive or desirable. A manufacturer with excellent capability can produce something nobody wants. A designer with a distinctive vision can create great value using production methods available to everyone.

What decides which is which? Not a fixed committee, although it can sometimes look like one: designers, editors, brands and influential wearers shape what people regard as desirable, and a relatively small number of voices carry a great deal of weight. But taste in fashion actually moves through the interaction of creators, audiences, culture, reputation and distribution. Nobody decrees it, and nobody fully controls it.

Software may be heading towards something similar in parts of its market. If many people can build technically capable applications, then some categories — consumer apps, games, personal tools — may come to behave more like markets for clothing, music or entertainment than like markets for engineering. Presentation, identity, community, reputation and fit to a particular audience become the things people choose between, because the technical competence underneath is no longer rare.

You can compete in that world. Plenty of people will. But the most important point of this chapter is that you do not have to. Fashion is one way of creating value. It is not the only one.

The new scarcity

When something becomes abundant, attention shifts to whatever remains scarce. If implementation is becoming abundant, it is worth being precise about what is not.

Knowing which problem is worth solving is scarce. So is understanding a particular community, profession or difficulty well enough to see what would actually help. So is coherence — a product that feels like one thing rather than a pile of features. So is trust: people choosing your creation because they believe it will work and keep working. And so is reach: the people who would value what you made actually discovering it.

None of these is beyond the machine’s help. The previous chapters showed AI contributing to understanding, research, evaluation and design, and it will contribute more. I am not arguing that judgement is permanently human territory. I am arguing that these are now where the difference between creations comes from, because the code is no longer where it comes from.

Quality is not one score

Programmers are trained to think of quality as a property of software: correct, fast, secure, maintainable. Those properties still matter. But they are not the whole of quality, and they are not always the most important part.

Quality depends on what the creation is for. A research tool is good if it helps you find and reason about evidence, and if its results can be checked. A game is good if people enjoy playing it. A personal organiser is good if it fits one person’s life closely enough that they keep using it. An engineering system is good if it does its job dependably and measurably better than the alternatives. A commercial product is good if the people it is for find enough value in it to adopt it, trust it and, perhaps, pay for it.

Those standards can pull against each other. A technically sophisticated application can be worse for its users than a simple one. A beautiful consumer interface may be useless to a research laboratory. A brilliant research prototype may be nowhere near ready to deploy. A hobby project can be wonderful and commercially worthless at the same time, and that is not a contradiction.

So the first question of quality is not “is this good?” It is “good for what, and for whom?” The purpose of the work decides which qualities matter most. Purposes also change: a hobby becomes a research instrument, a research instrument becomes a product. When the purpose changes, the standard changes with it, and it is worth noticing when that happens rather than carrying an old standard into a new purpose.

Start by building for yourself

I suspect many readers’ first serious creations will be for themselves, and I want to say clearly that this is not a lesser starting point. It may be the best one.

You understand your own problems better than any outside developer ever could, because you live with them. You know exactly where your notes go missing, which ideas you lose between a conversation and a desk, what you wish you could ask your past self, how your research actually proceeds. A commercial application has to serve thousands of people reasonably well. A personal one can serve one person unusually well.

ALIVE, the system behind much of this book’s evidence, began this way. It is a persistent environment where my work, and what I learn while doing it, survives across conversations, models and restarts — built because I needed it, not because a market asked for it. Whether it is ever useful to anyone else is an open question, and its value to me does not depend on the answer.

Many personal tools sit in the same territory. Something that records and organises spoken ideas. Something that keeps the history and decisions of long AI conversations retrievable. Something that tracks a dozen small projects, organises a reading life, supports a hobby, or gives you a better interface to the AI systems you already use. None needs millions of users. None needs to earn anything. If it makes your days better, it has succeeded.

The personal value of an application and its economic value are different things. Being able to create useful software for yourself is one of the biggest opportunities machine coding offers, and it is available to almost anyone. Some of these tools will turn out to be useful to other people too. Most will not need to.

Compete, or invent

When you do build for other people, there are broadly two kinds of path, and it helps to know which one you are on.

Consider, as an illustration, someone who builds a polished habit-tracking app. The category is crowded. The app is technically competent — the machine made sure of that — and it is genuinely pleasant to use. It struggles anyway, because so do hundreds of others like it. In a crowded category, competence is the entry fee, not the prize. What might make the difference is everything the previous section called scarce: a design that gives it a recognisable identity, a deep understanding of one particular kind of user rather than everyone, a reputation earned somewhere first, a community that recommends it. That is the fashion path. It is real and winnable, but it is a contest of taste, trust and reach, not of implementation.

Now consider, again as an illustration, someone who has spent twenty years restoring old clocks. They know a problem almost nobody else knows: identifying parts across makers whose catalogues were never digitised, matched against wear patterns you can only learn by hand. Before machine coding, the tool they imagined would have needed a development team they could not afford. Now they can build a rough version, use it on their own bench, improve it through real use, and discover whether it actually helps. It may serve only them. It may turn out that a few hundred other restorers have exactly the same problem. They are not competing within a category. They are creating something for which the category barely exists.

Some creators compete to make something better within an established category. Others create something for which the category barely exists yet. Both can produce valuable work. Neither guarantees success. An unusual idea still has to prove itself useful, and a familiar category can still be won by someone who understands its users better than anyone else does.

How a standard is made

If quality depends on purpose, where does your standard for a particular creation come from? Earlier chapters promised to say something about recognising good work and demanding it, and this is the place.

Standards are made, not found. They come from exposure: using a great many examples of the thing you are trying to make, good and bad, until you can feel the difference before you can explain it. They come from comparison: putting your creation next to the best alternatives and naming, specifically, where it falls short and where it is better. They come from articulation: saying in words what “good” means for this particular creation — fast to start, quiet, trustworthy with my notes, fun for a nine-year-old — so that you can judge against it and direct the machine towards it. And they come from reality: seeing what happens when the creation meets the people it is for.

The machine can help with most of this. Ask it to show you the strongest examples in a category and explain what makes them strong. Ask it to compare your product against them, specifically and without flattery. Ask it to critique the product from the point of view of a particular kind of user. Ask a second, separate machine to do the same and see where they disagree. Use it to analyse feedback, cluster complaints and propose what to change. Chapter 15 described how to read the product; this is how to decide what you are reading it for.

But keep one line sharp. A machine’s opinion of your product is not evidence of how people will receive it. A model telling you your idea has strong market potential has told you nothing about the market. It cannot invent users, testimonials or demand, and when it appears to, it is guessing fluently. Machine critique is a very good way to improve a creation before it meets reality. It is not a substitute for reality.

Everyone can build; not everyone will earn

This is the part of the chapter I most want readers with commercial ambitions to take seriously.

AI broadens access to creation enormously. People who lacked the skills, the money or the time to build what they imagined can increasingly attempt it. That is a genuine and important change, and I do not want to diminish it. But broader access to implementation is not equal access to everything else. People still differ in knowledge, time, money, data, reputation, existing audiences, distribution and circumstances. Lowering one barrier does not remove the others. The defensible claim is not that everyone now stands on equal ground. It is that many more people can now attempt things that were previously out of their practical reach — which is remarkable enough without exaggeration.

It also helps to separate five achievements that are easily run together:

1. Creating something.
2. Creating something good.
3. Creating something another person finds valuable.
4. Reaching that person.
5. Finding a sustainable way to support or earn from the work.

Machine coding makes the first dramatically easier and helps substantially with the second. It helps less, so far, with the third, fourth and fifth. And as building becomes easier, more creations compete for the same attention, so the later steps may become harder, not easier. A product can be technically excellent and commercially invisible.

None of this is an argument that you should try to earn from what you build. It is an argument for knowing which of the five you are attempting. If you want a business, a niche can help: unusual knowledge of a profession, a place, a hobby or a community points you towards problems you are especially well placed to solve, and makes your creation harder to substitute with someone else’s. It does not remove competition, and it does not tell you whether enough people care. Only they can tell you that.

Find the people who care

If production becomes abundant, the relationship between a creator and the people their work serves becomes more valuable, not less. For some creations those people are a professional community; for others a group of enthusiasts, a set of researchers, or an audience of readers. For a personal tool, the only person who matters may be you, and that is fine.

If you do want other people, the questions are old and still unanswered by any machine: Who would actually benefit? What do they do now instead? What frustrates them about it? Where do they spend their time? How would they discover what you made? What would bring them back?

A relationship is not the same as an audience of followers. It is understanding people well, hearing what they really think, earning their trust, and changing the creation because of what they tell you. AI can help: researching where a community gathers, summarising feedback, drafting how to explain what you made, exploring ways to reach people. It cannot stand in for the contact itself. If you want to earn from something you create, discovering who values it may become as important as discovering how to build it.

Try Machine Coding — Find Something Worth Creating

This exercise is about choosing, not building. Speak each prompt and let the conversation run. It has not been executed as a demonstration for this book; it is for you to run.

Find what you know.

I want to build something genuinely useful or interesting to me. Ask me about my work, my hobbies, the things I know unusually well, and the problems I run into regularly. Help me find opportunities that connect to my own experience rather than generic app ideas.

Explore different purposes.

Based on what I’ve told you, suggest one application that would improve my daily life, one that would help me learn or research something, and one unusual invention or creative project. For each, tell me who it would be for and what would make it valuable.

Define what good means.

I like this one. Help me say what would make it genuinely good for its purpose. What must it do particularly well? What should we refuse to add? Show me the best existing examples of anything similar, and tell me how I’d recognise success.

Consider other people — honestly.

If I wanted to share this with other people, who might find it useful, and what do they currently do instead? List the assumptions we’d need to test with real people. Don’t invent demand, and don’t assume anyone would pay.

Finish with three things: a direction you chose for your own reasons, a sentence saying what “good” means for it, and the first small experiment you will build — for yourself, or for one real person.

Many more creators

I want to end with encouragement, because that is what this chapter is really about.

Think of someone who has spent twenty years fascinated by a subject but never had the skills or money to build the software they imagined. They can begin now. Think of someone who wants one small application to make their days easier. They can build it for themselves this week. Think of someone who wants to try an entirely new way for people and AI to work together. They can attempt it. Think of a specialist who understands an obscure problem shared by a few hundred others. They may be able to serve those people without first assembling a software team.

Not every experiment will work. Not every creation will find an audience. Not every application will earn anything. But far more people can now take part in the act of creating, and that matters whether or not money follows.

Machine coding does not have to turn everyone into a software entrepreneur. It can turn many more people into creators. The machine gives you more freedom to build. What makes that freedom valuable is what you choose to do with it — and the standard you hold the result to.

What comes next

This chapter was about the standards you choose for what you make. The next is about the ground you are making it on, which will not hold still. The models, tools and costs at the heart of machine coding change faster than any programming tool before them. Chapter 17, Keeping Up With the Machine, is about following those changes without being consumed by them — and about building a machine to help.