When Code Gets Cheap, Judgment Gets Expensive

I started writing software in 2003. Back then, if you wanted a computer to do something useful, somebody eventually had to sit down and write quite a lot of code. Over the years the tools improved, frameworks became more capable, libraries got richer, Stack Overflow saved us from ourselves, and development environments became increasingly helpful.

Then Artificial Intelligence (AI) arrived.

Today I can describe a piece of functionality in plain English and watch a machine produce a respectable first attempt before I have finished my coffee. That is remarkable, and I use these tools myself. But it is also creating some confusion about what software engineering actually is.

There is a growing assumption that if AI makes code easier to produce, developers must become less valuable. I think that conclusion may have things backwards.

When code gets cheap, judgment gets expensive.

Code was never the whole job

Writing code matters, but it has never been the hardest part of serious software engineering. The difficult work usually surrounds the code.

What are we actually trying to build? What does the business really mean by the requirement? Which part of the existing system will break when we change this one? What happens when the network fails halfway through the operation? What happens under real production load? Why does something work perfectly in development and behave like a deranged raccoon in production?

AI can help answer many of those questions, but somebody still has to recognize that they need to be asked.

That distinction becomes increasingly important as generated code improves. A function can compile, the tests can pass, the naming can be excellent, and the implementation can still be wrong for the system in which it lives.

Software has context. Applications have history. Databases have history. Businesses have history. Customers develop workflows nobody documented. Integrations contain assumptions. Security requirements exist for reasons that may not be obvious from the code. A technically elegant answer can still be the wrong answer.

Experienced engineers make mistakes too. The difference is that, after enough years, you become suspicious of things that look too easy.

That suspicion has value.

Experience is accumulated consequence

We often describe seniority with numbers: twenty years of .NET, fifteen years of SQL Server, ten years of cloud development. Those numbers are useful shorthand, but they miss much of what experience actually represents.

Twenty years of engineering should not mean repeating the same year twenty times. It means living with the consequences of technical decisions.

You have watched harmless shortcuts become permanent architecture. You have inherited systems nobody wants to touch. You have migrated software while people are actively using it. You have diagnosed production failures that refuse to reproduce anywhere else. You have discovered that a specification and the real business process sometimes appear to have been written for different companies.

Eventually that becomes pattern recognition.

You learn which questions to ask before changing something. You recognize when a design feels wrong even before you can fully explain why. You learn that cleverness has a maintenance cost. You learn when boring technology is exactly what the business needs. You learn that the phrase "this should be a simple change" deserves immediate investigation.

That knowledge is hard to manufacture because much of it was acquired through consequences.

AI increases leverage, which increases the importance of judgment

A common argument goes something like this:

AI writes more code. Fewer developers are needed. Therefore developers become less valuable.

The first two statements may sometimes prove true. The third does not automatically follow.

Suppose an experienced engineer can use AI to accomplish work that once required several people. The amount of leverage attached to that engineer has just increased dramatically. That makes the judgment of the person directing the work more important, not less.

A poor architectural decision made at normal speed is one problem. Making the same kind of decision five times faster is an entirely different kind of productivity improvement.

This is why I am less interested in whether AI can write code than in who is supervising the code being produced.

The future may not divide developers into humans on one side and machines on the other. A more meaningful distinction may be between engineers who use AI to amplify understanding and engineers who use it as a substitute for understanding.

I do not think "vibe coding" itself is the enemy. For prototypes, experiments, utilities and disposable software, asking AI to build something quickly can be extraordinarily useful. My concern begins when generation outruns understanding, particularly in systems that matter.

The dangerous moment is not when AI writes the code. It is when nobody responsible for that code understands enough of the surrounding system to know whether the answer belongs there.

That problem existed long before AI. AI simply gives it a much bigger engine.

Hiring systems have a problem

If engineering judgment becomes more valuable, employers face an awkward question: how do they identify it?

Our current hiring machinery is not particularly good at that.

A conventional resume is a compression format. Twenty or thirty years of work gets reduced to a few pages containing employers, dates, job titles, technologies and selected achievements. An Applicant Tracking System (ATS) may reduce that information further into fields, keywords and searchable criteria.

There are understandable reasons for this. Recruiters need ways to process large numbers of applicants efficiently. But important context disappears in the process.

Consider two developers whose resumes both list C#, ASP.NET, SQL Server and Azure.

One may have spent years working on relatively straightforward internal applications. The other may have led production migrations, modernized legacy platforms, diagnosed concurrency failures, designed integrations, worked directly with business stakeholders and rescued troubled systems.

On a technology checklist, they can look remarkably similar. In practice, they may be very different.

The difference is not the technology. It is what they actually did with it.

If I were evaluating an experienced engineer, I would want to know what they owned, what broke, what they fixed, what they modernized, which architectural decisions they made, what constraints they worked under, what happened in production and what other people relied on them to know.

Those questions reveal experience in context.

And context becomes more important when polished resumes, generated code, optimized applications and AI-assisted interview preparation become easier for almost everyone to obtain.

This is where SageLinked came from

Eventually this became more than something I wanted to write about. It became something I wanted to build.

I started SageLinked around a simple idea:

A developer's career is bigger than a list of technologies on a conventional resume.

The resume is still useful. It is the starting point. But I believe we can do much more with the experience buried inside it.

SageLinked is developing the SLXR - SageLinked eXplainable Resume - as a richer, developer-reviewed representation of what someone has actually built, fixed, modernized, supported and owned.

The words developer-reviewed matter.

I have no interest in feeding somebody's career into an AI model and allowing a machine to announce what that person supposedly knows. AI can help identify experience, organize information and highlight areas where useful context may be missing. The developer should still review it, correct it, add context and decide what represents them.

Some of the most valuable information in an engineering career exists nowhere except in the memory of the person who lived it.

Experience may be entering a very interesting period

I do not know exactly what software development will look like five years from now. I am suspicious of anybody who claims they do.

AI will improve. Development workflows will change. Some roles will shrink and new ones will emerge. Work that currently takes days may eventually take minutes.

But one principle seems increasingly durable.

The easier it becomes to produce an answer, the more valuable it becomes to recognize a good answer.

If AI makes software dramatically easier to produce, responsibility moves toward the people deciding what should be built, how the pieces should fit together, what risks are acceptable and whether the result should ever be trusted in production.

That does not sound like the end of experienced software engineers.

It sounds like a potentially very good time to be one.

Experience isn't outdated. It may be becoming the real advantage.