I was speaking with a founder last week.

We were talking about the fun of building with agents, the weird new problems that come up, and the little startup sob stories you only laugh about much, much later.

One of his stories scratched at something I've been chewing on for more than a decade:

Was that worth building?

“could we build it?”
”was it technically impressive?”
”did the demo work?”

Those are now easier than ever. But was it worth the time, the money, the attention, and the opportunity cost?

If you spend engineering time on a problem, does it move the top line or the bottom line? Does it make the product meaningfully better? Does a user feel it? Or did you just build another internal CRM because it felt more fun than buying off-the-shelf?

I can't tell you how many times this came up at Apple.

"We can spend a month here and improve power by 1 dB."

Okay…what does the user get?

Better wireless range? Better data speeds? A feature that finally works reliably? A benchmark win? A slide that looks better in a review?

Then the debate would begin.

Engineering would argue the physics. Product would argue the user impact. Program would argue the schedule. Finance would quietly exist in the background like gravity.

Eventually some exec would decide which tradeoff mattered most.

But we almost never got a clean answer to the simple version:

Was that worth the time and money?

That question is hard because the answer is full of nuance. It depends on confidence, timing, strategy, user perception, risk, quality, and a dozen other things that refuse to fit neatly in a spreadsheet.

I keep coming back to: cost per accepted outcome. A thing the company can actually use. A feature that ships. A bug that stays fixed. A renewal that gets saved. An answer someone trusts enough to act on.

That distinction matters more now, because AI work has a meter attached to it.

Software always had cost. Salaries, cloud spend, tools, support, meetings, maintenance. But the marginal cost of the work was easy to hide in the grey of payroll and planning. "Was it worth it?" usually meant headcount, or a roadmap debate, or a slide in a planning doc. You could work more hours. Push harder. Call it platform work. Call it an investment. Eventually the question got abstract enough that everyone moved on.

Agents make that harder.

Every run has tokens. Every retry, tool call, eval, search, and failed attempt leaves a little receipt behind.

Suddenly finance can ask a much cleaner question: what did our tokens buy us?

That is a lot easier to ask than: what did our engineers do for us?

It is also more uncomfortable, because the answer can be very dumb.

Sometimes the expensive model saves you three weeks.
Sometimes the cheap model produces a pile of almost-right work that costs more in review than it saved.
Sometimes the agent does exactly what you asked, which is the problem, because it was too vague.
Sometimes the senior engineer looks expensive until they kill the wrong project in one sentence.

Same old economics. The meter is just more visible now.

This is where leaders need to get much more precise.

Companies already have OKRs, KPIs, strategies, roadmaps, and all the other machinery we use to convince ourselves we've tamed the mess. That machinery matters even more now, because agent work does not do well with vibes.

You still need someone to define the outcome. Someone to decide what "accepted" means. A budget, a stop condition, a quality bar, and a sense of what the work is worth if it succeeds.

The Jobs To Be Done were always there. Now the job can be split between humans and software.

Some work gets a cheaper model and a tight scaffold. Some work gets a frontier model, better tools, and a human reviewer. Some work should go to a less experienced IC who needs the reps. Some should go straight to the distinguished engineer, because the expensive path is actually the cheapest one.

And some work should not exist at all.

That last category is the one we don't talk about enough.

AI makes it easy to build things that feel finished enough to defend. A workflow. A dashboard. A feature nobody asked for but everyone can now picture. Friction used to be the immune system. If a thing took three engineers and six weeks, it had to survive a few hard conversations before it got built. Now the idea shows up half-built, already named, with a convincing demo. That does not make it valuable. It makes it harder to kill.

So maybe the process inverts.

Don't start by pretending you know the terminal value of every project. Start with the cost envelope.

This is a $500/month problem.
This is a two-week problem.
This is a good-enough-by-Friday problem.
This is a please-do-not-spend-another-minute-on-this problem.

Then ask what accepted outcome would justify the spend.

That still won't give you a perfect formula. It shouldn't. Judgment, taste, and the ability to call something Good Enough carry the last mile.

The old Steve Jobs line is useful here: Real Artists Ship. The part people forget is that shipping means killing clever work that is not worth carrying.

Anyone can build now.

The craft is deciding what deserves to exist.

For more than a decade, I've been asking whether the work was worth it.

The bill finally came through.

How do you decide a feature was worth building? I'm collecting methods, especially now that the meter is running.

A new kind of role is emerging: the person who makes AI actually work day to day. Join our live roundtable on July 16. Reserve your spot

Keep Reading