When Everyone Can Build, What Becomes Valuable?

I have spent most of my professional life learning how to make things. Designing interfaces, writing code, building websites, developing products, working out how systems fit together. For a long time, the ability to produce a particular result depended heavily on access to particular skills. If you couldn't code, you needed someone who could. If you couldn't design, you needed a designer. Every discipline had its tools and its language, and crossing those boundaries could be slow.

AI has made those boundaries much easier to cross. It is now possible to describe a concept and see a working version of it relatively quickly. The quality varies, of course, and the gap between a demonstration and a dependable product remains substantial. But the direction is unmistakable: more people can make more things with less initial friction.

That raises a question I find more interesting than whether AI will replace a particular job.

When the ability to build becomes widely available, what becomes valuable?

Production was never the whole skill

It is tempting to assume that the skill was always the act of producing the thing. Writing the code. Drawing the screen. Assembling the campaign. But I have rarely found the hardest part of a project to be the isolated act of making it.

The difficult questions usually arrive before and around production. What problem are we addressing? Whose problem is it? What would improvement look like? Which assumptions need testing? How far should we push the idea? What will happen when the system encounters the behaviour of real people?

Production matters enormously, especially when the result must be robust, accessible, secure and maintainable. Yet production without judgement is simply activity. A team can move quickly and still make very little progress if it has misunderstood the problem.

As AI reduces the time between an instruction and an output, that distinction becomes harder to ignore.

More answers increase the value of a better question

I have always been drawn to questions that change the shape of a problem. Sometimes one question removes an unnecessary feature. Sometimes it reveals an entirely different audience. Sometimes it makes a technically difficult ambition much simpler to achieve.

AI is exceptionally useful in this process. I can use it to explore alternatives, challenge an assumption, compare possible architectures or create a prototype before investing heavily in one direction. It gives me more material to think with. But it does not remove my responsibility to decide what deserves attention.

If anything, the abundance of plausible answers makes the original question more important. Ask a shallow question and you can receive an impressive volume of shallow work. Ask a better question, and the same tools can help reveal possibilities that were previously too expensive to explore.

This is not a mystical property of prompting. It is a practical consequence of understanding context. The value lies in knowing what information is missing, recognising what a solution would need to survive and being willing to revise the question when the evidence changes.

The advantage of moving between disciplines

I have written before about why I don't niche down. I understand the economic argument for specialisation, and there are many situations where deep specialist knowledge is essential. But my own strength has often come from being able to move between strategy, design, technology and delivery without treating the boundaries as absolute.

A designer can imagine an interaction that changes the technical approach. A developer can recognise a system constraint that should change the product strategy. A product leader can see that the original brief is solving the wrong problem. In practice, the most useful decisions often emerge from interaction between those perspectives.

AI makes it easier to explore adjacent disciplines, but that does not mean all knowledge has become equivalent. There is a difference between generating an interface and understanding why it is usable. Between producing code and knowing what will happen when it scales. Between drafting a strategy and being accountable for whether it improves anything.

The ability to connect disciplines becomes valuable because it helps us ask better questions of the specialists, tools and systems involved.

Taste is a form of judgement, but it isn't enough

There is a popular argument that taste will become the defining creative skill as production becomes easier. I think there is truth in it. Being able to recognise quality, coherence and originality matters when anyone can generate hundreds of variations.

But taste on its own can become another form of preference. I like this. I don't like that. That is useful as a starting point, but it does not tell us whether a product will serve its users, whether a platform is sustainable or whether a choice helps the client achieve anything meaningful.

The stronger version of taste is disciplined judgement: recognising what works, understanding why and remaining willing to change your mind. It combines aesthetic sensitivity with evidence, experience, technical understanding and a clear sense of purpose.

It is also collaborative. The creative director, engineer, strategist and client may each see something the others miss. A good process allows those perspectives to challenge the idea without making every decision a contest of authority.

Speed changes the responsibility to choose

I am a strong believer in rapid prototyping. I would rather put a useful idea into interaction, observe what happens and improve it than spend weeks debating an abstract possibility. AI has expanded that approach dramatically.

But speed has a shadow. It can encourage us to treat everything we are capable of making as something worth making. Features accumulate because they are easy to produce. Prototypes become products without the necessary scrutiny. Systems grow more complicated while the original purpose becomes less clear.

I have seen how expensive poor early decisions can be, even in fairly ordinary digital projects. Architecture, content structure, accessibility and the way a team maintains a system all become harder to repair later. Building faster is valuable only if the feedback loop is capable of correcting direction.

The discipline is to move quickly where learning is cheap and slow down where consequences are difficult to reverse. A prototype should answer a question. An experiment should have a reason to exist. A production commitment should be made with an understanding of what it will require after launch.

What this means for agencies

For agencies, the change is particularly interesting. More teams can now demonstrate ideas that once required specialist production resources. That can reduce the distance between strategy, creative exploration and client understanding. It can also create pressure to deliver more, faster and for less.

I do not think the most useful response is to race towards maximum output. It is to strengthen the ability to identify which output is worth pursuing. An agency's value is increasingly tied to its interpretation of the client's situation, the opportunities it can recognise, the people it brings together and the quality of its decisions through delivery.

That is also why I value embedded consulting relationships. The greatest contribution is not always arriving with a new tool or producing a particular deliverable. Sometimes it is bringing an additional perspective into the room early enough to change the direction of the work. Sometimes it is staying involved long enough to see whether the idea stood up to reality.

Building remains important

None of this is an argument for abandoning craft. I still write code. I still care about the small details of an interface. I still enjoy the moment an abstract idea becomes something that can be used. The craft gives me a way to test my thinking against the world.

What has changed is the relationship between what I know and what I can attempt. I no longer need to treat every unfamiliar discipline as an immediate boundary. I can explore, learn and test more freely, while recognising that reliable work still demands verification and expertise.

Perhaps that is the more fundamental shift. Technology expands our sphere of possibility, but it does not tell us where to direct our attention. We still have to decide what matters, what is worth changing and what responsibility we are prepared to take for the outcome.

When everyone can build, the question is no longer simply who can make the thing.

It is who can recognise what should exist, understand what it will affect and carry the judgement to make it worthwhile.