Luc B. Perussault-Diallo

Posted on Oct 12 Originally published at linkedin.com

After Coding

#ai #career #discuss #softwareengineering

We spent decades confusing the ability to write code with the ability to engineer software. AI is making that distinction impossible to ignore.

In July 2025, David Heinemeier Hansson told Lex Fridman why he refused to let AI drive his editor. "I can literally feel competence draining out of my fingers," he said. "You learn with your fingers."

On 6 October 2026, in a post called "Over my dead pencil," he told programmers to put the pencils down. Coding agents, he wrote, "have gotten so good that it's simply not an economically viable enterprise going forward to have humans typing out lines of Ruby, Rust, or C++."

Fifteen months.

I have built on Rails since version 2, and I have been writing code with AI every day for about two years. So I read that post as the most stubborn hand-typist in my corner of the industry arriving somewhere I had already been living. I agree with him. Anyone using these tools daily watched them get more reliable month after month, well before anyone famous said so.

Coding will survive, for fun, for learning, for the parts the machine gets wrong. The question I care about is what engineering turns out to be once producing code stops being the scarce part. My answer hasn't changed in twenty years. Mastery of code was the entry ticket, and it was less than half the job.

How we kept score

Look at what our industry rewarded for twenty years.

Job posts were lists of languages and frameworks. Interviews were whiteboards and timed tests.

In 2025, after a decade running the technical side of a marketplace with sellers in 47 countries, I was handed a thirty-minute coding test that was, in my own words at the time, "absolutely not concrete, nor useful to the company." The clock was the main thing it measured.

Productivity was counted in tickets closed, story points burned, pull requests merged. Some companies counted lines of code. Some still do.

Every one of those measures looks at the output of the keyboard.

The people doing the work knew better. Ask any good engineer back then what they wanted from a team and you heard some version of the same line, "not more code, good code." Fewer lines, the right ones, in the right place. That sentence already described the job we are now being pushed into. We said it for years and measured the opposite.

It made sense. For most of the history of software, turning an idea into working code was slow and expensive, and the people who could do it fast were rare. Scarcity creates status. For decades, the ability to produce code stood in as a proxy for engineering judgment. Now that the proxy is losing its value, we're discovering how poorly we understood it, and how little we deliberately taught the thing we needed.

We confused the artifact with the craft.

None of this was a secret. Fred Brooks wrote it down in "No Silver Bullet," first presented in 1986.

He split the difficulties of software into essence and accident, and he was precise about which one mattered:

"I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared with the conceptual errors in most systems."

Forty years. We all quoted it. We kept hiring for the fuzz.

What the market is pricing now

Adoption is no longer the story. In Stack Overflow's 2025 survey, 84% of developers said they use AI tools or plan to. The more interesting number is about quality.

Asked about their frustrations, 66% picked "AI solutions that are almost right, but not quite," the top answer. 45% said debugging AI-generated code takes more time.

And when METR tried to rerun a productivity experiment in early 2026, between 30% and 50% of developers said they had avoided submitting some tasks because they did not want to do them without AI. Whatever the speed gains turn out to be, the habit has already changed.

Almost right is a strange place for a profession to be standing. The code arrives instantly. Knowing whether it is right does not.

The hiring data tells the same story from the other side. Indeed's Hiring Lab published an analysis in July 2026 showing US software development job postings up almost 15% since Claude Code launched in February 2025, while overall postings fell 7% over the same period.

Good news, until you read the rest. Software postings are still about 27.5% below their pre-pandemic level. And 71% of the increase between May 2025 and May 2026 came from senior roles. 37% came from jobs with AI in the title.

At the bottom of the ladder, Stanford's Digital Economy Lab has been tracking payroll data from ADP. In the November 2025 version of their "Canaries in the Coal Mine" paper, Erik Brynjolfsson, Bharat Chandar and Ruyu Chen report that employment for software developers aged 22 to 25 had fallen nearly 20% from its late-2022 peak.

The authors describe their results as early and descriptive, not causal, and some of those trends started before generative AI. Still, the direction is hard to argue with.

What these numbers show is a market leaning toward experience and away from the entry point. What they don't show is why. Companies may want people who already know AI tooling. They may have stopped wanting to pay for training. Rates, budgets and the way postings get labelled all move these curves too.

My bet, which the data fits but can't prove, is that part of the shift is about judgment. The people being hired are the ones trusted to direct a system and own what it does. The ones not being hired are the people whose job was mostly to turn a clear ticket into code.

The bricklayer problem

Laying bricks is skilled work. A good mason knows mortar consistency by feel, reads a wall for plumb without a level, knows which courses carry load. Calling it "just" bricklaying is snobbery that only people who have never built a wall can afford.

But a building is more than a pile of bricks. Somebody decided where the load goes. Somebody knew the soil. Somebody knew that the people living there would want light in the kitchen in the morning, and that the cheap foundation would crack in the third winter.

Automating the bricklaying leaves the need to understand construction intact. What it takes away is the excuse for skipping that understanding.

That is where I have to be blunt with two groups of people. I belong to both. Twenty-six years as an engineer, eighteen as a founder, twelve as a CTO. Neither question lets me off.

Two questions, two audiences

The first is for engineers.

If your entire contribution to a product was translating someone else's specifications into code, what did you expect would happen when machines learned to do that?

I know how that lands. Plenty of engineers were put in that box by their organisations. Ticket factories, product managers who handed down solutions instead of problems, managers who treated questions as friction. Being confined to implementation was often not a choice.

But it was often a comfortable one. Implementation has clear edges. You can be good at it without ever questioning what you’re building.

You never have to defend a product decision in a board meeting or tell a founder their idea will collapse under real users. The specification was someone else's problem, and the code was yours, and for a long time that division paid well.

The same organisations misread the engineers at the other end. Most of us have worked with one. The person who asked why before writing a line, killed half the backlog, saw the outage coming a quarter early.

Managers called them "10x engineers" and credited the keyboard. The ten came from everything around it: the questions, the refusals, the system they carried in their heads. None of that showed up in anything anyone counted, so the typing got the credit.

The second question is for founders, investors and executives, and it grows out of that misreading.

If you thought replacing engineers with code generators would make you a technology company, did you ever understand what your engineers were doing?

I have been of two minds about vibe coding from the start, and I still am. Half of me loves it. Anyone with an idea and some stubbornness can now get it running, and I have watched people who would never have shipped anything build tools they use every day.

The other half laughed, a little cruelly, at the pitch that came with it, the one that said you don't need engineers anymore. I knew what that bet was missing, and that the bill would land on the people who made it. It is landing now.

Faster code has not meant better software. Veracode tested more than 100 language models on 80 curated tasks in 2025 and found security vulnerabilities from the OWASP Top 10 in 45% of cases, with no real improvement from bigger models. It is a vendor study on synthetic tasks, so treat it as a reason to check your own code.

Google's DORA report for 2025, from nearly 5,000 respondents, found AI adoption now linked to higher delivery throughput, and also found that adoption "does continue to have a negative relationship with software delivery stability."

DHH has his own example. In his second conversation with Lex Fridman, in August 2026, he described designers at 37signals sending vibe-coded pull requests that "destroyed the architecture of the system. And we actually had to clean up manually."

He also said, in the same conversation, "Software is product management." I don't think he meant it as a compliment to product managers. I think he meant that the work left over, after the typing, is deciding what should exist and holding it together.

The entry ticket

Brooks was right that syntax is fuzz. You still had to get through the fuzz to be taken seriously. Nobody let you near the architecture until you had shipped a lot of code that worked, and a fair amount that didn't.

When I migrated a platform from Rails 4 to Rails 7 in 37 days without downtime, the plan was the easy part. What made it possible was a decade inside that codebase, knowing which callbacks hid side effects, which gems lied about their compatibility, which tests were theatre. Mastery bought me the right to make those calls.

This year I built a tool called Sense, a Go binary, after a decade of shipping mostly Rails. It made no difference, because an engineer has no home stack. The calls were the same kind: what to build, what to refuse, where the risk sits. The agents handled the part that used to require years in the language. My value didn't drop when I stopped typing. It stopped being tied to one stack.

That is the part of this shift I enjoy most. It also exposes the hole in it. The entry ticket I paid with years of implementation is no longer on sale. If machines take the first rung, those 20% fewer developers aged 22 to 25 mean lost apprenticeships as well as lost jobs. In ten years they are the senior engineers we won't have.

Nobody has solved that yet, me included. I have opinions, and they come later in this series, labelled as opinions.

There are other counterarguments I take seriously. Job losses are real and not evenly spread, and "move up the stack" is easy advice from people who are already up it. Some people who never called themselves engineers are now building useful software, and some of it is good. And the output of these tools ranges from poor to excellent.

Most of the code I shipped this year was typed by agents, and some of it is better than what I would have typed myself.

What is left

So, after coding, what is engineering?

The same thing it was, with fewer places to hide. You understand a problem well enough to know what should exist, and what shouldn't. You pick between two defensible designs and live with the one you didn't choose. You hold enough of the system in your head to see what a change will break, read a confident almost-right answer and find the wrong part, and stay on the hook after release.

Engineers who were already doing that work are going to have a strange, good few years. Engineers who were not are going to find out, and some of them will learn it fast because they were always capable of it and nobody asked. Founders who thought they could buy the output and skip the judgment are going to learn the price of a stability problem.

Which brings back the entry ticket. Our industry never taught judgment on purpose. It assumed people would absorb it from years of implementation, and for people like me that worked.

If the implementation goes to machines, somebody has to teach on purpose what we used to leave to osmosis, and I can't name a company that has worked out how. What I can't tell yet is whether we will even try, or keep hiring for typing speed with a new name.

We haven't reached the end of engineering. We've reached the end of being able to pretend that writing code and engineering software are the same thing.

Where the load goes

As of October 2026, I count the end of that pretence as good news.

The machines are taking over much of the typing. What’s left is picking the problem, shaping the system, and watching it survive its first real users.

Engineers stuck turning tickets into code now have a tireless partner to learn the rest of the job with, if someone shows them where to look. And the designers, founders and hobbyists shipping their own tools will produce more software than ever, a lot of it in need of someone who knows where the load goes.

Twenty-six years in, this is the most fun I have had building.

This is part of a three-article series, After Coding.