Why the engineers who matter now are the ones who know what to leave out.

On the evening of 15 October 2026, at a SpaceX test site in McGregor, Texas, Tesla finally revealed the production Roadster. Nine years after it was first shown, and six years after it was meant to be in customers’ hands, the car drove along the underside of an inverted ramp, fired cold-gas thrusters, flipped in mid-air and landed itself. Zero to sixty in under a second, with the thrusters fitted. Production in 2028.¹

It was quite a spectacle, and a spectacle only has to work once, on camera. It was also, by Tesla’s own fine print, a trick that cannot legally be performed anywhere a customer drives. The thruster package the entire demonstration was built around is “not approved for public road use and not available in all regions”. Asked whether it had jurisdiction instead, the FAA said the vehicle does not meet its definition of an aircraft either.¹

Gene Munster of Deepwater Asset Management summed it up in a phrase I’d struggle to improve on: “an engineering flex with no commercial value beyond embarrassing traditional car makers.”² The market seemed to agree. The shares jumped about 4% the next morning, gave it all back by lunchtime and closed down 2%. Six days later Tesla reported a quarter of flat revenue and a 29% fall in profit. On the earnings call, Musk called the demo “one of the most exciting events”. The Roadster got no price, and no date beyond 2028.²

I’m not interested in piling on Tesla. The people who built those thrusters solved hard problems, and that deserves respect. I’m interested in the Roadster because it is the cleanest, most expensive illustration I’ve seen of a failure mode I’ve watched in software for twenty years, and one that coding agents are about to make dramatically worse: mistaking capability for value.

The Product Flow

Steve Jobs had a simple model of how a technology company should work, and he repeated it in various forms for most of his career. Walter Isaacson recorded the cleanest version near the end of his biography: profit mattered because it let Apple make great products, but “the products, not the profits, were the motivation.”³

That is a narrower claim than it sounds. It isn’t that the money doesn’t matter. It’s that the money is what you build great machines with, and the machines are what bring the money back, and the order of those two clauses is the whole difference between a company with a purpose and a company with a narrative. Money in service of the product, reinvested into a better product, with the customer at the centre of the loop.

The Roadster reveal runs that loop backwards. The thrusters aren’t there because a Roadster owner has a job that requires a kickflip. They’re there because a kickflip makes a livestream, and a livestream is meant to move a share price. The engineering came back as attention rather than as a better car. The product has become the vehicle for the story rather than the other way round.

What a Flex Costs

It is worth being blunt about that phrase, because it is usually offered as a compliment with a caveat attached. An engineering flex is engineering performed for the people watching rather than the people using. The fact that it is hard is the entire point — nobody flexes with something easy — so difficulty ends up standing in as evidence of worth. That is exactly backwards. Difficulty is a cost. The only thing that counts is which problem went away, and for a car that supposedly flips itself on a closed test site, the answer is none.

The usual defence is that this is what a halo product is for. Sometimes it genuinely is. A halo earns its keep when the engineering comes back down the range — when what you learned building the unaffordable one makes the affordable one better. Tesla, of all companies, knows the difference, because it wrote the distinction down. The 2006 master plan was explicit that the first Roadster existed to pay for the cheap car: “When someone buys the Tesla Roadster sports car, they are actually helping pay for development of the low cost family car.”⁴ That is a flywheel. Thrusters do not come back down the range. Nothing in a mass-market Tesla gets better because a Roadster can supposedly hop, and no buyer of either is better off. What came back was attention, and attention is not a product.

The other defence is that this is what breakthrough engineering looks like early on, and that the people who laughed at the Model T did not look clever for long. That one fails on its own terms, because it inverts what made the Model T work. Ford built for the roads America actually had — rutted, unpaved — and for owners who would fix the thing themselves with what was already in the shed. It integrated with the world as it was. That is what a product which changes an industry has to do, and cars in particular, because they are among the most heavily regulated products on earth and for good reason. Crashworthiness, type approval and the rules protecting pedestrians and cyclists are not friction awaiting disruption. They are the accumulated price of a century of people dying in traffic. A capability that cannot be approved for use anywhere is not ahead of its time; it is outside the system it would have to live in. Tesla already holds the receipt for ignoring that: the Cybertruck cannot be registered anywhere in the EU, because its stiff, sharp-edged body fails the rules on protecting vulnerable road users.⁵ The thrusters are the same mistake with better choreography.

This is the part that should worry anyone who builds things for a living. When a flex is rewarded — with coverage, with a viral clip, with a standing ovation at a conference — it stops being a harmless indulgence and becomes a template. Capability starts to justify itself. The question “what problem does this solve?” starts to sound naive in the room. Cars make that corruption expensive and therefore rare. Software has always made it cheap, and software is about to make it nearly free.

Overshooting Is an Old Disease

Clayton Christensen gave us the vocabulary for this in 1997. In The Innovator’s Dilemma, he described performance oversupply: incumbents keep improving their products along the dimensions they’ve always competed on, long after those improvements exceed what customers can actually use or are willing to pay for.⁶ Once that happens, the basis of competition shifts. Customers start caring about other things, such as reliability, convenience and price, and that’s precisely where cheaper, simpler challengers get in.

Zero to sixty in under a second is performance oversupply in its purest form: an improvement along the one axis sports cars have always competed on, pushed so far past what any road, any tyre or any driver can absorb that it stops being a feature and becomes a statistic. Meanwhile, Tesla hasn’t launched a new mainstream passenger car since the Model Y was revealed in 2019,⁷ and competitors are shipping affordable, good-enough EVs on cycles measured in months.

Christensen’s later work makes the point sharper. His jobs to be done framework argues that customers don’t buy products; they hire them to make progress in a specific situation.⁸ The famous example is the morning milkshake: commuters weren’t buying it for the flavour, they were hiring it to make a long, boring drive bearable and keep them full until lunch. Understand the job, and the right improvements become obvious. Ignore it, and you can improve the product forever without making it any more useful.

We Do This in Software Too

It’s easy to laugh at a flying car. It’s harder to admit how often we build the software equivalent.

Pendo’s 2019 Feature Adoption Report analysed usage across 615 software products and found that most of what gets built is never really used.⁹

That’s the industry’s thruster budget.

We all know the forms it takes. The microservices architecture for a product with a few hundred users. The Kubernetes cluster running a single binary. The plugin system nobody writes plugins for. The feature built for the launch demo that nobody touched after week one. The rewrite that happened because the old framework had stopped being interesting.

None of that work is fake. It’s often impressive. But it serves the builder, the conference talk or the funding round, not the customer’s job.

Early in my career I was sent to fix a problem for a customer. I fixed it in a few lines of SQL, written and tested in under an hour. Problem solved, customer happy, move on.

That wasn’t allowed. The work had already been billed, and a few lines of SQL didn’t look like what the customer had paid for. So it needed a UI. I spent an afternoon building and testing screens around a query that already worked, then more time packaging it as a one-off app and shipping it to the customer as a pre-built executable.

It landed exactly as you’d expect. What is this? What does it do? Who’s allowed to run it? An admin could have read a few lines of SQL and known exactly what they did. An executable from a supplier had to be trusted. Nobody needed it, and in the end it was thrown away. The fix took under an hour. The show took an afternoon, a packaging job, a deployment and a round of security questions, and then it was binned.

I didn’t have a word for it then. It was a flex: effort put on so that a bill could be justified, not so that a problem could be solved. Today an agent would build that UI in minutes, and that’s exactly what worries me. Back then the show at least cost enough that someone had to argue for it. Now it costs nothing to make, and just as much to live with.

What Changes When Code Is Cheap

Here’s the argument I think most people are getting backwards.

The common assumption is that coding agents reduce the cost of building, so building more is now cheap and therefore fine. If a feature costs an afternoon instead of a sprint, why not ship it and see?

Because the cost of a feature was never mostly in writing it.

The cost is in everything that comes after: maintaining it, securing it, testing it, documenting it, supporting it, explaining it to the next engineer, working around it when you change something else, and carrying it in the head of every person who touches the system. Agents reduce the first cost dramatically. They do almost nothing for the rest. In fact the evidence so far suggests they increase it.

GitClear’s duplication finding is the mechanism visible in the diff: generating a near-copy is now cheaper than refactoring towards the thing you already have.¹⁰ And the METR trial is the more uncomfortable of the two, because the developers in it were experienced, working in code they knew, and wrong about their own throughput by roughly forty points.¹¹

That gap between feeling productive and being productive is the whole problem in miniature. When producing code feels effortless, the natural brake on overbuilding disappears. You no longer have to ask whether something is worth the effort, because the effort seems to have vanished. The cost hasn’t vanished. It has just moved downstream, to the part of the lifecycle that doesn’t show up in the demo.

Engineers as Chefs

The best analogy I have for this is a kitchen.

In a world where ingredients are expensive and labour is slow, a cook’s value is mostly in execution: can you actually produce the dish? Now imagine a kitchen where every ingredient is free and every prep task is done instantly. Does that make every cook a great chef?

Obviously not. It makes the gap between a great chef and an average one far wider. When anyone can put twenty things on a plate, the skill is in knowing which three belong there. A five-star kitchen is defined as much by what never leaves the pass as by what does. The menu is a set of decisions about what not to serve.

That’s where engineering is heading. The agent is the brigade: fast, tireless, willing to prep anything you ask for. The engineer’s job is to know the diner. What job are they hiring this product to do? What’s the smallest thing that does that job reliably? What are we going to say no to?

Jobs put it in five words at WWDC in 1997, while explaining why Apple was killing technologies its developers loved: “Focusing is about saying no.”¹²

The engineers who thrive in the agent era won’t be the ones who generate the most code. They’ll be the ones with taste: the ones who can look at a perfectly working, freshly generated feature and say, calmly, “we’re not shipping that.”

The New Build-Versus-Buy Line

There’s a second consequence of cheap code, and it changes where the opportunity is.

When a competent developer can have an agent produce a passable internal tool in an afternoon, a lot of software is now competing with “I’ll just build it myself.” For technical buyers, thin products are in trouble. If your product is a nice UI over a database table, your customer’s engineers can roll their own before your sales call ends.

What they can’t roll in an afternoon is the complete package: the domain knowledge baked in, the edge cases already handled, the compliance already done, the upgrades, the support, the years of someone else having thought hard about this one problem. That part was never really code. It’s understanding a problem deeply enough to know what the product needs, and what it doesn’t.

So the value moves to completeness and convenience. The winning product isn’t the one with the most features; it’s the one that solves a real pain so fully that building your own would be obviously daft.

And that points at where the hunting grounds are: niche, less technical audiences with genuine pain. The safety manager, the practice owner, the small operator who has no interest in prompting an agent and just wants something that works on Monday morning. They don’t want more. They want the problem gone.

Less, done completely, beats more done halfway.

Questions Before You Build

If you lead an engineering team, or you are the engineering team, here are the questions I’d want answered before anything new goes into a system, especially now that “it’s cheap to build” is no longer a reason on its own.

• What job does this do, and for whom? If you can’t name the customer and the situation, you’re building a thruster.
• What will it cost to own, not to write? Maintenance, security surface, support, cognitive load. Estimate the next three years, not the next three hours.
• What are we removing to make room for it? If the answer is “nothing”, you’re adding weight, not value.
• Would we build this if it took a sprint instead of an afternoon? If not, the low build cost is hiding a bad decision.
• How will we know if nobody uses it, and will we actually delete it? Most teams can answer the first half. Very few honour the second.

And for leaders: start rewarding subtraction. Celebrate the engineer who deleted a service, retired a feature or talked the team out of a rewrite, with the same energy you celebrate a launch. What you celebrate is what you’ll get more of.

The Point

The Roadster will probably sell. But it isn’t a model for how to build things that matter, and in software we’re about to be tempted by the same trap at a much larger scale. The cost of building has collapsed. The cost of owning hasn’t. The cost of building the wrong thing has never been higher.

Anyone can cook now. Not everyone should.