14 min read
Yes, that is the title. You probably think I am being mean (I would, if I were reading it). Hold off a minute and read the rest. I think you will agree.
The phrase “developer happiness” started showing up around 2014. Spotify published its engineering culture videos. The Software Craftsmanship movement (Sandro Mancuso’s book had just landed) was at its peak. A few years later Nicole Forsgren and the DORA team published Accelerate and gave the industry its first defensible link between developer experience and business outcomes.
For about a decade, “developer happiness” meant something specific. Your laptop was not from 2009. Your CI was not 47 minutes long. Your platform team had built the paved road. The economic case was clean: a senior engineer cost a hundred thousand dollars to replace, and removing the small daily indignities of the job paid for itself in retention. That was the right intervention for that era.
Then the work changed. The friction those programs were built to remove is now removed by something else. The platform team did not finish paving the road. The model paved it. The engineer no longer writes the boilerplate, no longer types the seventh CRUD endpoint of the morning by hand. The work those interventions were trying to make tolerable is the work that no longer needs to be done by a human.
In 2026 you still want happy developers. But “happy” no longer means “comfortable in the workflow you have used for fifteen years.” It means productive on the work that matters, shipping at a cadence that would have been unimaginable in 2019, spending your day on the parts of engineering that compound (judgment, system design, spotting what is wrong with the diff the model just handed you).
The engineer who is happy in 2026 is the engineer who ships. The engineer who is unhappy is often the one being asked to leave behind a definition of “happy” that quietly stopped applying. Those are not the same person.
So let me say it directly. I want you software developers to be unhappy. Not all of you. The ones who are still defending the version of the job that AI has already eaten.
There is a new job family forming, and it deserves its own name. I have been calling it the AI Engineer (sometimes AI Software Engineer when I am being formal about the role description). I wrote it up in detail as a working standard here: We Went Through the Training and We’re Not Seeing the Value. That piece is the job description. This piece is why you should want to be one.
The AI Engineer is not a marketing phrase that will fade. It is what this profession is becoming. It is what your competitors are already hiring for. It is what the engineer two desks over from you is quietly turning into while you write your fifth comment thread about why the model “doesn’t really understand the system.” Farmers went through this with the tractor. Typesetters went through this with the laser printer. The job did not disappear, but the job stopped looking like the job, and the people who refused to look up lost a decade.
If that frame annoys you, I am doing my job. Keep reading.
Meet Bob
Bob is in the back of the room. Headphones on. Oat milk latte cooling next to a sticker-covered laptop. On the desk, in a stack with the spines facing out: Beck, Feathers, Fowler. Bob leads the local Software Craftsmanship meetup. He has been writing unit tests since 9:14 AM and he is, by his own description, in the zone. He calls it soothing. He calls it craft.
Most readers also read: The Engineers Who Can’t Use AI Agents Don’t Have a Tools Problem
Bob works at a big corporation. His “customers” are six people on the internal RPM team, and they work nine to five (so does Bob, so does the tool, so does anyone who would notice if it were down). His tickets this sprint are CRUD endpoints, two report screens, and a webhook that has been on the backlog for six weeks. This is not firmware. This is not the embedded controller in a pacemaker. It is a line-of-business application for six people on a 9-to-5, the kind of work that pays Bob’s salary and funds Bob’s latte.
And Bob is unhappy. Last quarter his manager asked him to start using AI Agent Dev Tooling and to stop hand-rolling the same five test scaffolds he has been hand-rolling since 2019.
If you are Bob’s manager and Bob is unhappy, congratulations. You are doing your job.
Bob is good at parts of his job. His instincts about state management, about idempotency, about the weird race condition in the payment retry loop nobody else can find, those are real and you do not want to lose them. But Bob’s job is not to feel soothed. Bob’s job is to ship working tested product to customers. Those two things are not the same.
Bob is not an age bracket. Bob is a posture. The Bob I see most often is fifteen years in. The next most common Bob is twelve months out of a bootcamp, sitting at a Vim setup he spent two weekends configuring, treating AI as “training wheels for people who never learned the craft.” Same headphones. Same defense of the soothing part. Same one article about AI hallucinations that decided the issue for him. The years on the resume do not predict who will be Bob. The relationship to the tools does.
The Majority of Software Is Not Special
Most software written this year will be a line-of-business application. CRUD on a database. An API that talks to another API. A scheduled job that emails someone if it breaks. The HR system, the loan origination platform, the booking flow, the customer support tool. Pick any company that is not a chip designer or a flight controls vendor, and that is the work their engineers are doing.
For that work, there is no longer a defensible reason to write it the way Bob wrote it in 2019. The output of one engineer with AI Agent Dev Tooling, who knows what they are doing and reviews what comes back, is between three and ten times what Bob produces in a sprint, on the same quality bar, with the same test coverage, shipped at the end of the day instead of at the end of the quarter. I have written one of these up in detail: two engineers replacing a ten-person hiring plan in twelve months, real production code, real roadmap, real monolith decomposed. That is the published example. Most companies measuring it on private dashboards are quiet because they do not want their competitors to copy them. The numbers are not subtle.
If Bob is producing one feature per sprint and the engineer next to him is producing seven, you do not have a tooling problem. You have a Bob problem.
“But the Hard Stuff…”
I hear this every week. “Sure, AI is fine for SaaS, but in our domain…” and then a list.
Sometimes the list is real. Firmware under FDA scrutiny. A trading engine where a regression costs eight figures. The kernel module everyone is afraid to touch. There is real, hard engineering where AI assistance today is uneven at best.
Even those people should be trying. Not “putting AI on the safety-critical path tomorrow.” Trying. Building the scaffolding with it. Writing the test harness with it. Generating the fuzzing inputs with it. Spiking the architecture on a Saturday with it. The hard-core engineers who refuse to even experiment will be the most surprised in eighteen months when the tooling catches up to their domain and they have not built a single neuron of intuition about how to direct it.
What Bob Is Actually Defending
When Bob says “it is soothing” and “it is my craft,” I believe him. I started writing code in the early 2000s. I like my headphones on, my favorite beverage on the desk, the feeling of being in the zone for three uninterrupted hours with nothing else in my head. I have felt the small clean satisfaction of a green bar at the end of a quiet hour. It is nice.
It is also a hobby.
I had to go through this change myself. I am not writing about Bob from outside Bob’s chair. I sat in it for two decades.
I built trust in my code the same way you do: CI/CD, automated testing as the floor and not the ceiling, roll-forward deploys instead of pretending we could roll back. The whole catalogue of software-engineering-stuff-we-know-is-good. None of that goes away when AI shows up. It compounds.
If you go on YouTube and dig around for videos of me from about 2021, you can watch me teaching this by hand. Pre-agent. Pre-AI. I am at a whiteboard explaining strangler-fig migrations and characterization tests to a room of senior engineers whose companies paid serious money for them to be there. Hand-refactoring legacy code was, for almost a decade, one of the highest-margin services in our industry. It was a money printer.
I do that work with AI now. Not as an experiment. As the way I do it. And I will tell you something I did not expect to feel: I am unhappy when I have to do it without AI. The hand version is still soothing. It is also a fraction as effective in a fraction of the time, and I cannot un-know that.
The engineers who have crossed over do not want to go back. The ones who refuse assume the other side is colder and worse. It is not. The craft is still there. The leverage is just orders of magnitude higher.
Would Your Customers Pay More for Hand-Crafted Code?
The six people on the RPM team open their browser, click the dashboard, see whether the report runs. Have they ever asked Bob whether the SQL was hand-typed or generated? Has anyone, ever, in the history of your product, asked whether the function bodies were lovingly composed at 9:14 AM with a latte?
They have not. They will not.
Would you pay more for a hand-crafted car? Sometimes. There is a market for that. It is called Pagani. They build a few dozen cars a year, they cost three million dollars each, and the marketing claim is “we built this by hand.” For the Toyota Camry that gets you to your kid’s soccer game, nobody pays extra because the door panels were hand-fitted. The buyer wants the car to start when they turn the key.
Walk down to the taco truck on the corner. Two-dollar tacos, line out the door at lunch. Nobody is asking the cook whether the tortillas were pressed by hand or pulled out of a bag. If you tried to sell a five-dollar “hand-pressed artisan tortilla taco” out of the same window, you would lose to the truck across the street that does the two-dollar version twice as fast.
Software for the RPM team is not Pagani. It is the two-dollar taco. The customer wants the report to render and the webhook to fire. That is the deal, and that is the entire deal.
Bob’s craft is real. It is also invisible. The customer cannot see it, the buyer is not paying for it, and the competitor across town who ships at three times the cadence is taking the deal anyway.
What Marcus Built While Bob Refactored
Sit in on Bob’s standup on a Wednesday. Ask Bob what he put into production this sprint. Bob will tell you, with quiet pride, that he refactored the order processing module. Cyclomatic complexity is down from 21 to 17. The tests still pass. The behavior is unchanged.
Now walk to the desk of the engineer two rows over. Call him Marcus. Marcus is using AI Agent Dev Tooling, and Marcus does not look smug about it. He is just shipping.
Marcus rebuilt the CI pipeline so deploys take four minutes instead of forty-seven. Marcus stood up blue-green deployment so the team can roll back in seconds instead of paging the on-call at 2 AM. Marcus shipped the webhook the RPM team has been asking about every Friday since February.
If you ask Bob whether the team needs a better pipeline, Bob will say yes. If you ask whether blue-green would help, yes. If you ask whether the slow endpoints need tracing, yes. Bob is not stupid. Bob has fifteen years of experience and a real understanding of what good infrastructure looks like.
Bob’s answer, every time, is the same. “We should do that. I just don’t have time.”
Bob does have time. Bob is choosing to spend it on a refactor that took the cyclomatic complexity of a working, tested, not-on-fire module from 21 to 17. “I don’t have time for the pipeline” translates to “I have time, I am spending it on the part that feels good to me, and I am calling the part I am avoiding ‘we should do that someday.’“
When the RPM team finally gets the webhook, they will not ask whose code wrote it. They will ask why it took six weeks. The honest answer, the one nobody is going to say out loud at the retro, is “because Bob was refactoring.”
Bob Is a 2024 Senior. Marcus Is a 2026 Senior.
I am not going to argue that Bob is not senior. Bob is senior. He has the years. He has the title. He goes to the craftsmanship conference every spring and comes back with notes on hexagonal architecture and value objects. He reads the changelogs. He has opinions on every new framework, every Postgres release, every runtime everyone is going to switch to next quarter. By the standards of 2024, Bob is exactly what “senior software engineer” was supposed to mean.
The standard moved.
Bob is a senior engineer from a profession that was redefined while he was at the meetup. He is not a senior AI Engineer. Marcus is. Marcus has fewer years on his resume than Bob, has never spoken at a conference, and is shipping seven times what Bob ships on the same quality bar. By the standard of the job that exists now, Marcus is the senior engineer in the room.
Bob’s skills are real. They were also calibrated for a job that has changed underneath him. The instincts about state management and idempotency still matter. The years of careful refactoring still matter. The unwillingness to update the toolchain does not.
Then you ask Bob about AI. The temperature in the room changes. Bob does not trust it. When you ask why, Bob points to a mistake an AI agent made for him in February of 2024. He has not touched it since. That was two years ago.
This is not skepticism. Skepticism is staying current with what a tool can and cannot do, and updating your view as the evidence changes. What Bob is doing is using a single bad experience from a previous era of the technology as permanent permission to stop looking. That is the behavior of an engineer who needed an excuse, and February 2024 happened to provide one.
Bob is senior in the old job. Marcus is senior in the new one. Only one of those jobs is hiring.
The Signal You Wanted
Look at your engineering organization right now. Same standups as 2024. Same sprint length. Same code review process. Same definition of done. Same release cadence. Same on-call rotation. If you cannot point to three things AI broke and forced you to rebuild in the last twelve months, you do not have an AI-native team. You have a 2024 team using a 2026 toolbox.
The signal you should be looking for is that your people are breaking your processes. The sprint is too long because they ship in three days now. The PR review is too slow because the model wrote half of it before the human opened the file. The standup is dead because async-with-an-agent ate it. The “definition of done” no longer matches what production looks like. Things are on fire in a useful way.
If your processes look identical to what you ran in 2024, that is the signal you missed. If your people are happy about that, that is the signal to push them. Bob complaining about the new tools is not the dangerous Bob. Bob content with the old ones is the dangerous Bob, because the content Bob is not generating the friction that would tell you the work has already changed.
If a competitor down the street is shipping seven features a sprint with the same headcount, on the same quality bar, while your standup, your sprint length, your release process, and your code review look identical to what you ran in 2024, what is your plan when their pricing drops twenty percent and your customers notice? What do you tell your board? What do you tell Bob two years from now, when the soothing has nowhere left to go?
Hope is not a plan. And neither is craft that you refuse to update.
A Note to Bob’s Manager
If you got here as Bob’s manager, do not send him this article. Do not print it out and slide it across the desk. Do not screenshot the section that sounds like him.
Pair with him. Teach him. Sit next to him for an afternoon and use the new tools together on a piece of work from your backlog, not a tutorial. Show him what shipping at the new cadence looks like in your codebase, on your stack, on the ticket he was about to spend a sprint on. That is the intervention.
If you cannot do that, if you have not used the tools yourself, if you cannot demonstrate the new cadence on a problem you own, that is a different post, and Bob is not your problem.
A Note to the Software Developer Reading This
If you got this far and you are an engineer, not a manager, and the piece annoyed you, good. That annoyance is the most useful signal you have this year.
The AI Engineer is the engineer who started learning the new tools while you were waiting for the hype cycle to pass. They are not smarter than you. They are six months further down a road that does not have an off-ramp.
Be unhappy. Then go do something with the unhappiness.
