Coding Is the Easy Part

Most people think a software engineer is someone who writes code. So they hire for that. They ask which languages you know, how fast you type out a feature, how many years you've used some framework. Fair enough, that's the visible part of the job. But it's the easy part. The thing you're actually paying an engineer for happens before a single line of code gets written.

A good engineer isn't paid to write code. They're paid to solve a problem. Code is just one of the tools they might use to do it, and often it's not even the right one.

You've heard it everywhere lately: coding is cheap now. AI writes it, a kid can ship an app over the weekend, the typing is basically free. All of that is true. And it quietly proves the whole point. If coding is the part that just got cheap, then coding was never where the value lived. The value sits in everything around it, the part AI still can't do for you.

Writing code was never the hard part

Think about how a feature actually gets built. The typing is maybe 20% of it. The other 80% is everything around it: what does this thing need to do, who's going to use it, what happens when they use it wrong, how does it fit the work people already do, what breaks if we change it later. That's the real work. The code is just where all those decisions land.

This is why two engineers can build "the same feature" and get wildly different results. One asked the right questions first and built the thing that solves the problem. The other just built exactly what was on the ticket. Both wrote working code. Only one of them was doing engineering.

And now AI writes the code for you. Describe what you want and it produces something that runs. So the part everyone used to measure, the typing, the syntax, the framework trivia, is the part that just got cheap. What's left is the part that was always the actual job. We've made this point about the craft as a whole: code got cheap but software didn't.

Most clients hand you a solution, not a problem

Here's where it gets interesting. When someone comes to you with "I need a button that exports this report to PDF," they think they're describing a problem. They're not. They're describing a solution they already picked. The real problem is hiding behind it: why do they need that PDF? Who reads it? What do they do with it next?

Half the time, when you actually ask, the PDF is being printed, signed, scanned, and emailed back, so they can copy three numbers off it into another system. The problem was never "I can't export a PDF." The problem was "two systems don't talk to each other and a human is the glue." Build the button and you've solved nothing. You've just made the wrong process slightly faster.

A weak engineer takes the ticket and builds the button. A good one stops and asks why, because they know the person in front of them is an expert in their business, not in software. It's the engineer's job to translate what they want into what they actually need. That's a thinking job, not a typing one.

Sometimes the best fix is no code at all

The hardest thing for a lot of engineers to accept is that the best solution is sometimes no software. A step you can just delete. A form with three fields instead of twelve. A rule that says "we don't do it that way anymore." A cheap off-the-shelf tool instead of a custom build. None of those are code, and all of them can be the right answer.

We've turned away work because the honest answer was "you don't need us to build this, you need to change one thing in how you work." That feels strange when building software is how you get paid. But a real engineer is loyal to the problem, not to the code. If your engineer always reaches for "let's build it," they're not solving your problem. They're feeding their own habit, and you're the one paying for it.

This is the same disease behind a lot of failed projects. Companies jump straight to building because building feels like progress. But most digital transformation projects fail on bad problem definition, not bad code, and you end up with a system built for the boss that the actual users quietly refuse to open. Every one of those started with someone coding a request instead of solving a problem.

Where the difference actually shows up

The trouble is, you can't see this on day one. The button works. The demo looks great. Everyone signs off. The engineer who coded the request and the engineer who solved the problem hand over things that look identical at launch. The difference only shows up months later, and by then it's expensive.

The coded-request version slowly reveals itself. The feature nobody uses. The report that's technically correct and completely useless. The workaround your staff invented because the system didn't fit how they actually work. The change request you're now paying for because the thing was built to spec and the spec was wrong. It all traces back to the same root: someone built what was asked instead of solving what was meant.

The problem-solved version is quieter. It just works, people use it, and nobody talks about it. Good engineering is invisible like that. When the thinking up front was right, there's nothing dramatic to point at later, which is also why it's so easy to undervalue.

AI just made this the whole job

For a long time you could hide a weak problem-solver behind strong coding. They couldn't frame a problem, but they could grind out clean code fast, so they looked valuable. That cover is gone. AI grinds out clean code faster than any of them, and it does it for everyone. The pure coding skill stopped being a moat.

So the only thing left that's worth anything is the part AI can't do for you: understanding the real problem, deciding what's worth building, knowing what to leave out, spotting the trap before you walk into it. AI is a brilliant tool in the hands of someone who already knows what they're solving for, and a fast way to build the wrong thing in the hands of someone who doesn't. We said this before: AI is a multiplier of skill, not a substitute for it.

How you spot the real thing

If you're hiring an engineer, or picking a vendor, stop grading them on tech stack. Watch how they handle a problem you bring them. The good ones ask annoying questions before they promise anything. They want to know why, who, and what-happens-when, not just what. They'll sometimes tell you the thing you asked for is a bad idea, and explain a cheaper, simpler thing instead.

Be a little suspicious of the one who says "no problem, we can build that" to everything. It sounds great in a sales meeting. It usually means they're going to code your request, bill you for it, and bill you again when it turns out the request was wrong. The engineer who pushes back a bit is the one who's actually thinking about your problem instead of their invoice.

The honest version

Coding is a skill, and it matters. But it was always the easy part, the visible tip of a much bigger job. The hard part, the valuable part, is the thinking: understanding the problem so well that the right solution becomes obvious, even when the right solution turns out to be less code, or no code, or a flat "you don't need this." That's what separates an engineer from a typist.

AI didn't change that. It just stripped away the cover and left the real job standing there in plain sight. The companies that figure this out will stop asking "can you build it?" and start asking "do you understand what I actually need?" Because in a world where anyone can build anything, the only thing that's still scarce is knowing what's worth building at all.