Yes. I want you software developers to be unhappy. That is the title. You probably think I am being mean. I would, if I were reading it. Hold off a minute and hear the rest. I think you will agree.
The phrase developer happiness started showing up around twenty fourteen. 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 DevOps Research and Assessment team, the D-O-R-A 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 two thousand nine. Your Continuous Integration was not forty-seven 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. They no longer type the seventh Create, Read, Update, and Delete 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 twenty twenty-six 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 twenty nineteen. You are 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 twenty twenty-six 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. Just the ones who are still defending the version of the job that A-I has already eaten.
There is a new job family forming, and it deserves its own name. I have been calling it the A-I Engineer, or sometimes A-I Software Engineer when I am being formal about the role description. I wrote it up in detail as a working standard in a piece called We Went Through the Training and We are Not Seeing the Value. That piece is the job description. This piece is why you should want to be one.
Look. The A-I 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 does not 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. The people who refused to look up lost a decade.
If that frame annoys you, I am doing my job. Keep listening.
Now. Let us 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, are Beck, Feathers, and Fowler. Bob leads the local Software Craftsmanship meetup. He has been writing unit tests since nine fourteen A-M and he is, by his own description, in the zone. He calls it soothing. He calls it craft.
Bob works at a big corporation. His customers are six people on the internal Revenue Performance Management 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 Create, Read, Update, and Delete 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 nine to five. This is 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 A-I Agent Development Tooling and to stop hand-rolling the same five test scaffolds he has been hand-rolling since twenty nineteen.
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 A-I as training wheels for people who never learned the craft. Same headphones. Same defense of the soothing part. Same one article about A-I 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.
So. Here is the thing. The majority of software is not special. Most software written this year will be a line-of-business application. Create, Read, Update, and Delete on a database. An Application Programming Interface that talks to another one. A scheduled job that emails someone if it breaks. The Human Resources 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 twenty nineteen. The output of one engineer with A-I Agent Development Tooling, who knows what they are doing and reviews what comes back, is between three and ten times what Bob produces in a sprint. This is 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.
OK. But what about the hard stuff? I hear this every week. People say, sure, A-I is fine for Software as a Service, but in our domain, and then they give a list.
Sometimes the list is real. Firmware under Food and Drug Administration scrutiny. A trading engine where a regression costs eight figures. The kernel module everyone is afraid to touch. There is real, hard engineering where A-I assistance today is uneven at best.
Even those people should be trying. Not putting A-I 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.
Now. What is Bob actually defending? When Bob says it is soothing and it is my craft, I believe him. I started writing code in the early two thousands. 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. Continuous Integration and Continuous Deployment, 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 A-I shows up. It compounds.
If you go on YouTube and dig around for videos of me from about twenty twenty-one, you can watch me teaching this by hand. Pre-agent. Pre-A-I. 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 A-I 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 A-I. 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.
Right. Ask yourself. Would your customers pay more for hand-crafted code? The six people on the Revenue Performance Management team open their browser, click the dashboard, and see whether the report runs. Have they ever asked Bob whether the Structured Query Language was hand-typed or generated? Has anyone, ever, in the history of your product, asked whether the function bodies were lovingly composed at nine fourteen A-M 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 Revenue Performance Management 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.
So. Let us look at 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 twenty-one to seventeen. 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 A-I Agent Development Tooling, and Marcus does not look smug about it. He is just shipping.
Marcus rebuilt the Continuous Integration 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 two A-M. Marcus shipped the webhook the Revenue Performance Management 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 do not have time.
Look. 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 twenty-one to seventeen. I do not 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 Revenue Performance Management 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 retrospective, is because Bob was refactoring.
So here is the situation. Bob is a twenty twenty-four senior. Marcus is a twenty twenty-six 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 twenty twenty-four, 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 A-I 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 A-I. The temperature in the room changes. Bob does not trust it. When you ask why, Bob points to a mistake an A-I agent made for him in February of twenty twenty-four. 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 of twenty twenty-four 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.
Right. So what is the signal you should be looking for? Look at your engineering organization right now. Same standups as twenty twenty-four. 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 A-I broke and forced you to rebuild in the last twelve months, you do not have an A-I-native team. You have a twenty twenty-four team using a twenty twenty-six 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 Pull Request 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 twenty twenty-four, 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 twenty twenty-four, 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.
OK. 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 conversation altogether, and Bob is not your problem.
Finally, a note to the software developer listening to this. If you got this far and you are an engineer, not a manager, and this piece annoyed you, good. That annoyance is the most useful signal you have this year.
The A-I 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.
So. Be unhappy. Then go do something with the unhappiness.