The Last Craft

In 2023, Anderson Cooper sat opposite Rick Rubin at Shangri-La and asked him what he was being paid for.

Rubin had already removed the usual defences. He barely played instruments. He did not know how to work a soundboard. He said he had no technical ability and knew nothing about music. To most people, this would sound like a confession or fraud. From Rubin, it sounded closer to a dare.

He co-founded Def Jam from an NYU dorm room in 1984. He helped shape early records by LL Cool J, Run-DMC, the Beastie Boys, and Public Enemy. He crossed from hip-hop into metal, rock, country, pop, and everything adjacent. He produced Johnny Cash’s Unchained, worked with the Red Hot Chili Peppers, Slayer, Adele, System of a Down, Jay-Z, Tom Petty, and enough others that the full list becomes less useful than the pattern. The Grammys credit him with nine wins and nineteen nominations through the 2026 awards.¹

So Cooper asked the question that follows naturally. Why pay this man?

Rubin answered: “The confidence that I have in my taste and my ability to express what I feel has proven helpful for artists.”²

The claim only lands because the records landed. Skill still matters. Opinions still need a record of being right. Rubin’s value sits above the individual instrument. He is paid to hear the whole thing, to know when the work is alive, and to say so clearly enough that the artist can move.

Software has spent decades rewarding people who could play every instrument themselves. AI is starting to unsettle that bargain.

The Language of Buildings

Software has always borrowed from construction.

We talk about architecture, foundations, scaffolding, load-bearing abstractions, technical debt, platforms, blueprints, maintenance, and structural integrity. The language is not decorative. It reflects how the work has felt for most of the industry’s life. Someone had to place each beam. Someone had to run each wire. Someone had to understand enough of the structure to know where the walls could move and where they could not.

That construction language maps onto people who write code.

At the first level is someone who can write code. They can make a script work, automate a task, glue two tools together, or build something small for themselves. The work can be useful and clever. The obligation is local. If it breaks, the person who wrote it usually pays the cost.

A programmer is a professional handyman. They know the tools, can fix things for other people, build features from a spec, and diagnose common failures. The work now has customers beyond the author. The standard rises because someone else depends on it.

Developers can build houses. A house is smaller than a skyscraper, but it still has to be habitable. A developer turns product needs into software that real people can use. They understand persistence, interfaces, deployment, release process, user flows, and the compromises needed to ship. They are producing something people move through.

An engineer builds bridges and skyscrapers. The word should imply load, failure, safety, maintainability, and professional duty. An engineer thinks about systems under stress. They design for other people changing the thing later. They care about contracts, boundaries, failure modes, operating costs, and the consequences of being wrong.

Each level carries more knowledge. Each level also carries a different standard of professionalism. An amateur coder can survive on ingenuity. A programmer needs reliability. A developer needs product sense. An engineer needs to take responsibility for a system beyond its visible features.

For most of software’s history, that ladder made sense. The person with more craft could take on larger structures.

AI puts pressure on that ladder from the bottom upward.

It gives programmers speed. It gives developers more material to assemble. It gives engineers more designs, migrations, tests, refactors, and explanations than they could have produced on their own. The visible act of construction becomes less scarce at every layer.

The scarce skill becomes knowing whether the bridge should exist, how the load will move through it, who will cross it, what it will connect to, and what kind of failure it invites.

The language of construction starts to break down in the world of AI-driven development, and music production becomes a better analogy.

Rubin’s Empty Hands

Rubin is often described as mystical, but his practical work is rigorous.

He strips. He listens. He chooses. He notices the part that everyone else is walking past.

In the same 60 Minutes interview, Rubin described himself as a reducer. He said he liked getting the point across with as little information as possible. Cooper also told the story of Tom Petty sending Rubin demos where none of the songs landed for him. Rubin heard a small guitar figure between two songs, drove to Petty’s house, and told him that the accidental part was the best thing on the tape. It became “Mary Jane’s Last Dance”.²

Rubin did not add another instrument. He did not outplay the band. He heard the centre of gravity before the artist had named it. He saw that the work was hiding within itself.

Selection is active work. A good producer does not wait for output and give opinions afterwards. They create conditions, ask for takes, narrow constraints, reject false directions, and keep the work aimed at its strongest form.

Most AI adoption will go wrong by measuring the band according to how many takes it recorded. The dashboard will show more pull requests, more tickets closed, more prototypes, and more lines changed. Those numbers are easy to produce, and for a while, they will look like progress.

The bill arrives later: more services, more abstractions, more tests that freeze implementation details, more generated documentation that says the obvious, more glue code, and more things nobody understands because nobody had to understand them to create them.

Rubin’s lesson is blunt: output cannot be allowed to impersonate quality.

Reznor’s Whole Picture

The opposite case starts in Cleveland, with Trent Reznor using spare studio time to shape the first incarnation of Nine Inch Nails.

Nine Inch Nails began outside the usual band shape of a stable set of players gathered around songs. Trent Reznor was the centre. Britannica describes Nine Inch Nails as essentially a stage name for Reznor in its early form, and says he wrote, arranged, performed, and produced most of the material.³ The Pretty Hate Machine credits are even more direct: all songs were written, arranged, programmed, and performed by Trent Reznor.⁴

Reznor did not play all the parts because every other musician lacked skill. Nine Inch Nails has always depended on collaborators, producers, engineers, and live musicians. The early solo construction mattered because the thing he was making was an arrangement of interactions: drum machine against distorted vocal, sampler against guitar, pop structure against industrial texture, emotional directness against mechanical force.

The work needed one mind close enough to every part to hear how the parts changed each other.

Reznor gives the necessary counterweight. Rubin shows how value can sit above the instrument. Reznor shows why taste has to stay in contact with the material. The producer who cannot hear the whole arrangement is useless. The craftsperson who can only hear their own part is trapped within it.

For software engineers, technical depth matters because it trains perception. Someone who has never fought a production incident will miss certain failure shapes. Someone who has never maintained an API will underestimate contract damage. Someone who has never watched users struggle through a flow will confuse interface completeness with usability. Someone who has never lived inside a codebase for years will overvalue local cleanliness.

Craft is how taste stays attached to reality.

The producer-engineer does not abandon the instruments. They stop proving themselves by playing all of them on every track.

Code Taste Is Too Small

A lot of people will say the future belongs to engineers with taste in code. They are stopping at the first layer.

Code taste matters today because models still produce plausible junk. They reach for common patterns when the local system needs a specific one. They write clean functions that do not belong. They create tests that pass and protect the wrong behaviour. They satisfy the prompt while violating the architecture.

Over time, AI will get better at that layer. It will learn local idiom. It will apply style automatically. It will refactor towards the conventions of the repository. It may also raise the abstraction level until much of the code that currently displays taste becomes generated material that nobody reads line by line.

The scarcer taste concerns whether the interaction is right, not whether a function is neat.

For a web app, GUI, TUI, or CLI, the interaction is the user’s path through the system. It includes language, timing, feedback, error recovery, defaults, affordances, trust, and the shape of the decisions the interface asks the user to make. A technically clean implementation can still result in a poor user experience. It can ask for the wrong thing, at the wrong moment, in the wrong form, with the wrong recovery path.

For a service, the user is often another piece of software. The interaction is the API contract, event shape, retry behaviour, idempotency, consistency model, pagination, schema evolution, latency budget, permission model, observability, and failure semantics. A tidy service can still be hostile to every caller. A generated client can still encode a bad relationship.

The important abstractions are the ones that shape interaction. They decide what the user can understand, what another system can rely on, what the team can change safely, and what failure will look like at 3am.

AI can produce code, and increasingly good code. The producer-engineer has to judge the layer above it.

The Producer-Engineer

A producer-engineer has more responsibility than operating the model.

This is not about turning tickets into prompts, prompts into diffs, diffs into reviews, and reviews into deployment risk. Doing this may make you busy. You may produce a lot. The work is still administrative if there is no point of view about what should exist.

A producer-engineer understands the human and machine audiences of the work.

For human-facing software, they can see when a flow is technically complete and practically dead. They can feel when a CLI command is asking the operator to remember state the system should remember. They can see when a GUI hides the important choice behind a tidy layout. They can tell when a web application is giving the user more options because the team refused to make a product decision.

For services, they can hear the integration before it breaks. They can see that a field name will become policy. They can see that a callback turns one team into another team’s runtime dependency. They can see that a retry strategy creates duplicates unless the system has a real idempotency boundary. They can see that an event schema has smuggled an internal model into the public world.

The engineer of the last era proved skill through direct construction. The engineer of the next era proves skill through production. The arrangement carries the value.

The Bad Future

The degraded version of this future turns engineering into content management.

The team asks for more output because output is easy to count. The model writes more code because code is easy to generate. Reviewers skim more diffs because the queue is full. The codebase grows wider. Nobody is accountable for whether the system has improved.

The failure will look professional. It will have dashboards. It will have adoption targets. It will have internal success stories about cycle time. It will have a lot of merged pull requests.

It will also produce systems with more surface area, weaker conceptual integrity, and less ownership.

The Last Craft

Software engineering was never typing. Typing was the public evidence of a harder job: turning intent into reliable behaviour.

AI changes who does the visible work. The grading system stays.

The compiler still refuses ambiguity. Production still exposes false assumptions. Users still punish confusing interactions. Other systems still punish bad contracts. Maintenance still punishes cleverness that nobody can safely change.

The old craft was writing the code.

The last craft is knowing what the code should make possible.

The last craft needs Rubin’s confidence in taste and Reznor’s contact with the whole arrangement. Taste without craft becomes aesthetic opinion. Craft without taste becomes competent output. The producer-engineer needs both, because the value shifts from playing the instrument to understanding what the whole arrangement should sound like.

Software engineers are not made redundant by that shift. The job changes shape. Companies will still need people accountable for behaviour, failure, contracts, users, and the long-term health of the system. What fades is the idea that value comes from being the hands on every line. The engineer remains, but the work moves up a level.