Code Was Never the Unit of Value

Code Was Never the Unit of Value

AI Isn’t Changing Software Engineering — It’s Revealing What It Always Was

Anthony Mendonca recently wrote a thoughtful article titled “The Code is Dead, Long Live the Craft.”

His article captures something important about the moment we’re in.

But I think the shift runs even deeper.

The real change isn’t that code is disappearing.

And it’s not that code is becoming less important.

The truth is simpler.

Code was never the unit of value.

It only appeared that way because software was historically opaque, specialized, and difficult to commoditize.

For decades, writing software required rare expertise. Systems were complex. Tooling was immature. Feedback loops were slow.

That created a kind of professional insulation.

If you couldn’t understand the code, you had to trust the people who wrote it.

And because of that, organizations often treated lines of code, complexity, and engineering effort as proxies for value.

But those were always proxies.

Customers never bought code.

They bought:

  • working products
  • capabilities
  • reliability
  • speed
  • outcomes

Code was simply the artifact required to produce those outcomes.

AI isn’t changing where value lives.

It’s simply making that reality impossible to ignore.


My First Lesson in Software Engineering

I’ve been programming for more than 45 years since I was 5 years old.

My father believed computers were tools for productive work, not entertainment. If I wanted to use our Apple II for games, I had to write them myself.

So I did.

At five years old I started learning BASIC and assembly to build simple games.

I didn’t realize it at the time, but that experience taught me something fundamental:

The code was never the point.

The goal was the game.

The code was simply the artifact necessary to produce the outcome.

That lesson has never stopped being true.


Learning Lean From the Source

Later in my career I had the unusual privilege of working closely with Shingijutsu Consulting, widely regarded as the world’s foremost experts in the Toyota Production System (TPS).

While working at Boeing—first as an aerospace engineer and later as a lead software engineer—I spent about a year working full-time as a simultaneous interpreter for Shingijutsu’s Japanese consultants.

Being fluent in Japanese allowed me to translate directly between Toyota veterans and Boeing engineering teams.

It was an extraordinary education.

For a time I also served as an AIW (Accelerated Improvement Workshop) facilitator, helping bring Lean thinking into engineering organizations.

Watching Toyota-trained practitioners analyze complex systems was eye-opening.

Their perspective was relentless and simple:

Where is the value?

And equally important:

Where is the waste?

That lens has shaped much of how I think about engineering systems and leadership. I’ve written about related themes around intentional system design and leadership here:


Lean’s Brutally Simple Definition of Value

Lean thinking defines Value-Added (VA) work very precisely:

Anything that changes the fit, form, or function of a product in a way that a customer would willingly pay at least one penny for.

Everything else is Non-Value-Added (NVA).

That definition is brutally clarifying.

Every meeting. Every email. Every status report.

All NVA.

If you can’t go back to your customer and say:

"We had a fantastic internal meeting today."

…and they respond:

"Great — let me pay you for that."

Then by definition, the meeting is not value-added.

That doesn’t mean it’s useless.

Some NVA work is necessary.

Planning. Coordination. Architecture alignment. Progress checks.

Lean calls this Necessary NVA.

But a large portion of NVA is something else entirely.

Waste.

Toyota calls that muda.


The Math Is Brutal

In most traditional organizations the distribution looks roughly like this:

  • ~20% Value-Added work
  • ~80% Non-Value-Added work

A familiar pattern.

It’s essentially a power-law distribution.

Inside that 80% NVA bucket:

  • roughly 50% is necessary
  • roughly 50% is waste

Which leads to a startling implication.

If you simply eliminated the waste—nothing else—the math looks like this:

Monday and Tuesday: Necessary NVA work. Wednesday: Value-Added work. Thursday and Friday: nothing at all.

You would deliver exactly the same customer value.

At 40% lower cost.

That’s the power of eliminating waste.


AI Is Compressing Non-Value-Added Work

For decades software engineering required enormous amounts of NVA work:

  • writing boilerplate code
  • wiring integrations
  • infrastructure scaffolding
  • repetitive implementation
  • environment debugging

Important work.

But rarely where customer value actually lives.

AI is rapidly compressing these categories.

Large language models can now generate:

  • infrastructure code
  • glue code
  • repetitive implementations
  • test scaffolding
  • documentation

in seconds.

Which forces a new question.

If AI eliminates large portions of NVA work…

Where do engineers create value now?


Engineers Become Systems Designers Again

The best engineers were never just coders.

They were systems thinkers.

AI simply makes that reality visible again.

The role increasingly becomes:

  • defining objective functions for success
  • structuring incremental feedback loops
  • designing environments where progress can be measured
  • assembling tools agents can reliably use

In other words: SYSTEMS ENGINEERING.

Because once you understand value creation, engineering stops being about writing code.

Truthfully, it never really was—any more than building a house is about hammering nails.

It becomes about designing systems that reliably produce outcomes customers are willing to pay for.


Discipline Matters More, Not Less

Ironically, the rise of AI makes disciplined engineering practices more important, not less.

Practices like:

  • test-driven development
  • small composable components
  • deterministic tooling
  • clear interfaces
  • reproducible environments

These practices aren’t academic ideals.

They are how you build environments where AI agents can operate safely and productively.

Without structure, AI simply produces chaos faster.


Working With AI Agents Feels Familiar

If you’ve ever led an engineering team, working with AI agents will feel remarkably familiar.

The pattern is almost identical.

You:

  1. Describe the outcome
  2. Ask for approaches
  3. Evaluate options
  4. Select a direction
  5. Delegate execution
  6. Measure results
  7. Iterate

The difference is speed.

Instead of sprint cycles measured in weeks, you may run dozens of iterations in a single day.


Toyota Already Solved This Problem

The deeper lesson from Toyota was never about manufacturing.

It was about systems thinking.

Design systems where:

  • value is visible
  • waste is eliminated
  • feedback loops are tight
  • improvement is continuous

AI doesn’t invalidate those principles.

It amplifies them.

Which means the engineers who will thrive in this new era will not be the ones who write the most code.

They will be the ones who best understand:

  • systems
  • value
  • outcomes
  • and how to orchestrate humans and machines toward them.


The Future Engineer

The future engineer looks less like a programmer and more like a systems architect directing teams of human and machine collaborators.

You describe outcomes.

You build environments.

You assemble tools.

You design feedback loops.

You guide systems toward measurable results.

Code still exists.

But it is no longer the center of gravity.

It never really was.

To view or add a comment, sign in

More articles by Ward Vuillemot

  • AI as Amplification, Not Replacement

    Building the Ironman Suit for Human Intelligence The story goes like this: AI will replace knowledge workers. Maybe.

    11 Comments
  • Why I Wrote a Personal Operating Guide (And Why Every Leader Should)

    Most organizational dysfunction isn't caused by incompetence. It's caused by unspoken expectations.

    2 Comments
  • Works in Progress Told in Three Truths

    Sadly I do not know who to properly attribute the below to, but when I recently heard these it quite literally stopped…

  • Fate or Destiny, What Do You Choose?

    Fate versus Destiny has always fascinated me in their natural juxtaposition to each other. On the one hand we have the…

    1 Comment
  • Leading Remotely: Creating Culture From Afar

    In my last article, Leading Remotely: Lessons from 5+ Years in the Trenches, I talked about my experiences thus far as…

    3 Comments
  • Leading Remotely: Lessons from 5+ Years in the Trenches

    I really appreciated Adam D'Angelo's, CEO of Quora, write up on Remote First at Quora. He shares a lot of great…

    16 Comments
  • Days I Hate, People I Love

    I’m sharing this news in that counter-logical way to many who might believe its better to not draw attention to…

    3 Comments
  • Killer Bots, Finally!

    If you have not seen it already, I recommend taking a gander at The Verge's article on the search for the killer bot. I…

    3 Comments

Others also viewed

Explore content categories