"Code Was Never the Hard Part" Is Half Right in 2026

11 min read

A sentence has been going around dev circles for months now, and every time I read it I feel my jaw tighten a little.

"LLMs may be good at coding, but code was never the hard part."

Here is my honest answer after sitting with it: "code was never the hard part" is half right, and the half it gets wrong is the half that pays your rent. Deciding what to build is genuinely hard. But so is building it. And in 2026 the data on AI generated code is finally clear enough to show which half of the work machines actually took, and which half they quietly made worse.

Let me show you both.

Key takeaways

• The phrase is true for ticket work. Add a dashboard widget, change a button state, wire a form. That was never the bottleneck.
• It falls apart for load bearing work. Real time systems, custom auth, anything with state, scale, or money attached.
• GitClear analyzed 623 million code changes from 2023 to 2026. Duplicate code blocks are up 81%. Refactored and moved code fell from 21% to 3.8%.
• Stack Overflow's survey shows 84% AI adoption and only 3% of developers highly trusting the output. 66% say the biggest pain is code that is "almost right, but not quite."
• The skill being repriced is not typing code. It is knowing which code should not exist.

[Image: Two columns side by side. Left column labeled "Ticket work" with small task cards. Right column labeled "Load bearing work" with a system architecture diagram. A dividing line down the middle.]

So is code the hard part or not?

Both people in this fight are describing real jobs. They are just describing different ones.

There is a kind of programming where the hard part genuinely is not the code. Somebody decides the instructor dashboard needs a "revenue in the last 28 days" widget. A developer picks up that ticket. If they know the codebase, that is a twenty minute job. The thinking happened in the room where somebody decided that widget mattered. The typing is the easy part, and pretending otherwise is silly.

Then there is the other kind.

Say your product needs live video for fifty people in one call. You reach for the obvious hosted option, you burn six weeks on it, you hit a bug in production that the maintainers never answer in the issue tracker, and you throw the whole integration away. So you drop down to a WebRTC SFU like mediasoup and build the thing yourself. Now you own connection state, reconnection logic, bandwidth negotiation, the database schema, the staging setup, and every ugly edge case that only shows up when the fortieth person joins on hotel wifi.

Nobody who has done that work believes coding was the easy part. The idea "we should build our own live video" takes four seconds to have. The implementation carries about 95% of the weight, and if you get it wrong nobody uses the product no matter how correct the idea was.

A laggy real time product is not a product with a good idea. It is a broken product.

Same industry. Same job title. Wildly different work.

What kind of coding are we actually talking about?

This is where the argument keeps collapsing, because "programmer" covers two people who barely share a profession.

One person builds the library. The other person calls it.

Writing mediasoup is not the same activity as adding a Google Sheets integration to a CMS. Both are programming. Both are legitimate work. But the knowledge, the failure modes, and the compensation are on different planets, and most of the internet argues about "coding" as if only one of those exists.

Here is the uncomfortable part for my own side: most programmers, even before AI, even at big companies, were mostly doing the second kind. You architect once, then you grind implementation, then you test, then you fix, then you do a hundred small tickets. That is not an insult. That is the job. The article that started this fight treats every programmer as a systems craftsperson, and that is too generous to be useful.

Why do LLMs make the "coding is easy" argument feel true?

Because they are genuinely excellent at exactly the half that was already easy.

McKinsey's numbers put it well. AI cut time on routine coding tasks by around 46%, but the gain drops under 10% on high complexity work. That is the whole story in one line. The model flies through the widget. It crawls through the system.

And a model will never stop you before you start. Ask any LLM to build a Zoom clone and it says "great, let's start with the signaling server." It will not say the thing a senior engineer would say in eight words: do not build this, buy it, your margins do not justify a custom SFU. Taste has no loss function.

So people watch the model produce four hundred lines in twelve seconds and conclude coding got solved. What they watched was the easy half getting faster.

What does the 2026 data actually say about AI generated code?

This is where it stops being opinion.

GitClear and GitKraken analyzed 623 million real world code changes from 2023 to 2026. The trend lines are not subtle:

Signal	Then	Now (2026 YTD)
Duplicated code blocks	40.3 (2023)	73.0, up 81%
Moved code (a refactoring signal)	21% (2022)	3.8%
Copy and paste lines	9.4% (2022)	15.7%
Cross file function calls (reuse)	baseline	down 35%

Read that second row again. Moved code dropped from 21% to 3.8%. Moving code is what you do when you notice a function belongs somewhere else, pull it out, and make the system smaller. It is the physical fingerprint of somebody thinking about structure.

That fingerprint has almost disappeared from the world's git history.

Meanwhile Stack Overflow's developer survey landed at 84% AI adoption with 3% of developers saying they highly trust the output. 46% actively distrust it. The single biggest frustration, at 66%, is AI solutions that are "almost right, but not quite," and the second biggest, at 45%, is that debugging AI written code eats more time than writing it would have.

Google's DORA report has the cleanest summary of all of this. 90% of respondents use AI at work, and AI adoption still shows a negative relationship with delivery stability. Their conclusion was that AI does not fix a team. It amplifies whatever the team already was.

Good teams got faster. Sloppy teams got sloppier, faster.

Did that famous "AI makes devs 19% slower" study hold up?

Partly, and the correction is more interesting than the headline.

METR ran a randomized trial in early 2025 and found experienced open source developers were 19% slower with AI tools, while predicting they would be 24% faster. That number got quoted in every AI skeptic thread for a year.

Then METR revisited it. For a subset of the same developers in early 2026, they now estimate roughly an 18% speedup, with a wide confidence interval. They also admitted a selection problem: the developers who got the most out of AI would not take part in the no-AI condition, even at fifty dollars an hour.

I bring this up because I do not want to hand you a comfortable number. The honest read is that the tools got better fast, the measurement is hard, and anyone quoting a single clean percentage at you in 2026 is selling something. What survived both versions of the study is the perception gap. Developers consistently feel faster than they measure.

Why won't an LLM tell you to delete the thing?

Here is my favorite example, and you can test it yourself in ten minutes.

Start a project with all your API routes in one file. Something like this:

// api/handler.ts
export default async function handler(req: Request) {
  const { pathname } = new URL(req.url)

  if (pathname === '/api/users') return getUsers(req)
  if (pathname === '/api/users/create') return createUser(req)
  if (pathname === '/api/posts') return getPosts(req)
  // ... 97 more of these
}

At ten routes this is fine. Genuinely fine. Now ask an AI agent to add route number 101.

It will add route 101. It will do it perfectly. It will do it at route 400 too, and the file will be nine thousand lines long, and it will never once stop and say:

This file is the problem. Move to file based routing. Delete this dispatcher.

That refusal to look up from the current task is the thing. Models optimize the next step. Somebody has to look at the whole shape of the system, decide it is ridiculous, and take the cost of the rewrite. Right now that somebody is a human, and if the GitClear numbers mean anything, there are fewer of them doing it every year.

The rarest skill in software in 2026 is not writing code. It is deleting it on purpose.

The bug no model was going to find for me

Let me give you a real one from my own stack, because abstract arguments are cheap.

I run artofcode.in on Next.js and Convex, with about 17 dev tools and 40 posts behind auth and admin flows. A few days ago every single login on the site started failing with an "Invalid origin" 403. Not some logins. All of them.

The auth code was correct. Every model I could have asked would have read that code and told me it was correct, because it was. The actual cause was a redirect direction at the hosting layer. The apex domain is canonical, and the redirect was pointed the wrong way, so requests arrived at a host the auth config did not recognize as trusted.

The fix was one setting. Finding it meant holding four systems in my head at once and asking which of them was lying. The code was never wrong, so no amount of reading the code was going to help.

That is the work. That is what "senior" actually buys you. And notice something: this bug lives exactly where the "code was never the hard part" crowd says the value is, in understanding the system, and exactly where they say it is not, in gnarly technical detail. It is both. It was always both.

If you want to see the kind of small utilities that come out of that habit, most of what I build ends up in the free dev tools on the site, from a JSON Formatter I wrote because I was tired of pasting payloads into random sites, to a tool for decoding JWTs I built during exactly this class of auth debugging.

If deciding what to build is the hard part, why is it not paid like it?

The original argument runs a set of sharp rhetorical questions. If figuring out what to build is the hard part, why are product managers not put through ten round interviews? Why are market researchers and customer success people not treated as rockstars? Why do developers get angry when a salesperson promises a feature, given the salesperson just found real demand?

They land, but there is a hole in them.

You cannot compare the top 5% of one role to the average of another. 90% of people in any field look bad next to the top 10% of any other field. That is just how distributions work. Compare great PMs to great engineers and the gap closes fast. And on pay, the comparison quietly skips leadership. The people deciding what gets built at the top, the CEO and the rest of the C suite, out earn the median engineer by a lot. The idea side is paid. It is just paid under a different job title.

The thing that changed in 2026 is defensibility. Before, if you claimed to be a React developer, I could ask you five questions and find out in ten minutes. That filter still mostly works. What broke is the entry gate on the other side: producing something that looks like working software no longer proves anything about the person who shipped it.

So the noise floor went up everywhere, and the honest signal got scarcer.

[Image: A distribution curve with a small shaded region at the right tail labeled "the part that still gets paid", and a much larger left region labeled "everything a model can now produce".]

What should you actually do about this in 2026?

Not vibes. Specific things.

If you are early in your career: go down a layer, not sideways. Pointers, recursion, memory hierarchy, how HTTP actually works, what a TCP connection costs. You will not use most of it directly. You will use all of it when something breaks at 2am and the code looks correct. Do the data structures work even when a model can write the sort for you, because the point was never the sort.

If you are experienced: go sideways, not just deeper. Sit in on customer calls. Learn what your company's money actually comes from. The engineers who survive this stretch are the ones who can tell which 20% of the request matters, and that is a business skill wearing an engineering badge.

Everyone: stop pasting model output you have not read. The most irritating pattern in software right now is somebody dropping a giant LLM response into Slack and making it your job to figure out what it means. If you did not understand it, you did not do the work. You forwarded it.

Do not outsource your judgment and your taste. Those are the last two things on this list that are actually yours.

Actionable takeaways

• Sort your own work into ticket work and load bearing work. Be honest about the ratio. If it is 95% tickets, that is your risk, not your resume.
• Use AI hard on the ticket half. Verify line by line on the other half.
• Once a month, look at your codebase and ask what should be deleted. No model will ever raise this. Put it on your own calendar.
• Learn one layer below your current stack this quarter. One. Not a roadmap, one thing.
• Read every line you ship, including the lines you did not write.

Frequently Asked Questions

Is "code was never the hard part" true?

It is true for routine feature work and false for systems work. Adding a dashboard widget or wiring a form was never the bottleneck, so AI handling it changes little. Designing a real time video pipeline, a custom auth flow, or anything with scale and money attached is dominated by implementation difficulty, where the idea is worth a fraction of the execution.

Does AI actually make developers faster in 2026?

It depends heavily on the task. McKinsey measured around 46% time savings on routine coding and under 10% on high complexity work. METR's randomized trial found experienced developers 19% slower in early 2025, then revised toward roughly 18% faster for a subset in early 2026 after finding selection problems in the original sample. The consistent finding across studies is that developers feel faster than they measure.

Is AI making code quality worse?

The measured signals say yes on maintainability. GitClear's analysis of 623 million code changes found duplicate code blocks up 81% since 2023, copy and paste lines up from 9.4% to 15.7%, and moved code, which indicates refactoring, down from 21% to 3.8%. Google's DORA report also found AI adoption still correlates negatively with software delivery stability.

Will AI replace software engineers?

It is replacing a category of task, not the role. The work that is repricing downward is producing code that already exists somewhere. The work repricing upward is judgment about what should exist: system structure, tradeoffs, debugging across layers, and deciding what to delete. Engineers who only did the first kind are exposed.

What should junior developers focus on now?

Fundamentals below the framework layer, because that is where the debugging happens. Understanding memory, network protocols, and data structures pays off precisely when AI generated code looks correct but behaves wrong. Pair that with reading and verifying every line you ship instead of forwarding model output you have not understood.

Want to build the kind of judgment that survives this shift? Start by shipping small, complete things and reading every line, and grab whatever you need from the 17 free tools I have built along the way.

Written by Adithya Guttha, Founder of Art of Code.