The Wrong Half

A man in one of my sessions typed a question into the chat. It said: do you think developers will be able to verify their own code with an AI agent, reducing or even eliminating the need for dedicated QA engineers?

Quality assurance, QA, is the half of building software that finds out whether the thing actually does what somebody said it would do. He was asking whether that half is about to stop being a job.

Nobody knows exactly what is going to happen next. I do not, and neither does anybody who sounds certain about it from a stage.

What I know is narrower than that. It took two years of using the thing to get it. Writing the code stopped being the expensive part of building software. Checking it did not.

Start with something that has nothing to do with computers, because everything after this is built on it.

It is Monday and you drive to Walmart. You have been there a hundred times. You park the car, you walk through the door, and everywhere you look there is a red circle with a white dot in the middle of it. On the walls. On the signs. On the shirts the staff are wearing.

That is the Target logo. You are standing inside Walmart and you are looking at Target.

Tell me what happens in your head. Not what you think. What you feel, in the first second, before you have worked anything out. Why did I come to Target?

Nobody told you. Nobody handed you a document. You had a picture in your head of what the inside of Walmart looks like, and what was actually in front of you did not match the picture, and you knew in one second.

That gap is the whole subject of this book. You pay for a Toyota Corolla, they hand you the keys, and it is a Corolla. If they handed you something else, you would know before you sat down, and you would not need to be told. You have an expectation, and the thing in front of you either meets it or it does not.

Software is exactly the same. Go to Amazon and type apple into the search box. You expect apples. If the results come back with a watermelon and a goat, you do not need a computer science degree to know something is broken. You typed apple. You got a goat. That is a bug.

So write it down as a sentence you can keep: a bug is when the software does not meet the expectation.

You walked into the wrong store and you knew in one second, with no document and no training. So why would software ever need that written down in advance?

Because nobody has ever been inside this one. You had a hundred visits to Walmart in your memory, so the comparison cost you nothing. Software that does not exist yet has no memory attached to it. Nobody has been inside it, nobody has a picture of it, so there is nothing to compare it against until somebody sits down and decides, in writing, what right is going to mean here.

One thing makes software much harder than the store. Quality is a perception. Ask ten people what a good meal is and you get ten answers, and none of them is wrong. Your picture lives in your head and mine lives in mine, and nobody can test anything against a picture nobody else can see.

So before the software exists, somebody writes the expectation down. That document is called the acceptance criteria, and it is exactly what it sounds like: the written statement of what counts as correct. You put your bank card into a cash machine and you ask for $20. The acceptance criteria says you get $20. Not $21. Not $19.99. Twenty dollars, exactly, every single time, for everybody.

That written list is what turns this into jobs, and the shape it makes is the shape of every software team ever built.

Three different people. One person decides what it should do and writes that down. A second person builds it. And a third person, who did not build it, goes and finds out whether the thing that got built matches the thing that was written.

That third job is not a mystery and it is not glamorous. It is a person at a screen with the written list beside them, going through it line by line. Item one says asking for $20 gives you $20. So they ask for $20 and they look. Item two says asking for more than your balance refuses you. So they try it and they look. Down the whole list, one item at a time, writing down every place the software and the paper disagree, and sending each one back to the person who built it.

Each one of those disagreements is a bug.

And somebody is paying for all of this. Software is not written for fun. Somebody has commissioned it, money has been agreed, and a date has been set. Which is why the written list matters so much: if nothing was written down in advance, then when the thing arrives wrong there is no bug, there is only an argument, and the argument happens after the money is already spent.

Three people: one writes it down, one builds it, one checks it. That is expensive. So why not let the person who built it do the checking and save a salary?

Companies have tried that for as long as software has existed, and it is the single most expensive habit in this business. Hold that question, because the whole back half of this book is the answer to it, and I am going to answer it on myself rather than on somebody else. For now take the short version: the person who built the thing cannot see what is wrong with it, and that is not about their character or their skill. It is about what happens inside anybody's head when they look at their own work.

For thirty years a software team had two halves, and one of them cost far more than the other.

Developers wrote the code. Testers validated the code. In practice that was a person using the software the way you use it, clicking the buttons, making sure the transactions work, and when something did not work, taking a screenshot and sending it to the developers.

The expensive half was the writing. The most expensive thing in the whole lifecycle was hiring developers. If you paid people to type code by hand, that was the biggest number on the bill, and every decision a company made about software came out of that one fact.

Then the typing got cheap. Not a little cheaper.

A coding agent is the thing that made it cheap, so let me say plainly what one is. You type a sentence in ordinary English saying what you want the software to do. The agent writes the code for it, runs it, sees the errors, fixes them, and keeps going on its own until it decides it is finished. It is not a person and it is not a company you hire. It is a program you talk to, and it works while you sleep.

A good developer used to write around two hundred lines of code in a day. Now the same person opens an agent and twenty thousand lines come back. Measure it a different way and it is five hundred lines a day becoming fifty thousand. Either way you are looking at a hundred times more code arriving from the same person.

The price of the writing half collapsed. The checking half did not move, because nothing about a machine producing the code makes the question of whether it is correct any easier to answer. You still have to know what right looks like. You still have to go and look.

Far more code is arriving at the checking step than used to. And the software you used this morning worked fine, and so did the software you used yesterday. So how bad is it, really?

You cannot tell yet, and that is exactly the danger. Think of a virus in the body. The first day, there are no symptoms. The second day, no symptoms. The third day, no symptoms, and the whole time it is building up. Then one day it takes the person down.

That is where this industry is right now. Millions of lines of code have been written without proper validation and without proper testing, and the defects are sitting inside those lines somewhere, and nobody knows where, because nobody looked. The name for that pile is technical debt, and it is accumulating at a speed the industry has never seen before, because nothing has ever produced code this fast.

You can already see it coming out. Production is the live version of the software, the one real people are using with their real money, and production failures are showing up more often and hitting harder. Amazon mixed up tens of thousands of orders in a single day. Large companies go dark for hours.

So the bill inverted. We do not have a code writing problem, we have a QA problem. The problem is not the coding. The problem is that nobody knows, with any certainty, whether code being generated a thousand times faster is any good, and whether the application built out of it actually works. Writing code is not the problem. Validating code is the problem. That is the job of QA.

Google's research team put a number on what that did. For every 25% increase in how much AI a team adopted, they measured a 7.2% reduction in delivery stability, and they gave the section a blunt title: AI is hurting delivery performance. The next year the speed came good. The instability did not.

Here is what one of these looks like from the outside, so the size of it is real to you.

In July 2024, a security company called CrowdStrike pushed a routine update to its software. That software runs deep inside Windows, at the level where a crash takes the whole machine down with it. The update contained a file that described a check with twenty-one pieces of information in it. The program that had to read that file had been built to handle twenty.

It reached for the twenty-first piece, found nothing there, and Windows crashed. Not on one machine. On roughly eight and a half million of them, at the same time, around the world, into a reboot loop that would not stop.

Airlines could not check passengers in. Flights were grounded. Hospitals canceled surgeries. Banks, broadcasters, emergency lines, supermarkets. One airline alone, Delta, later told its investors the week cost it three hundred and eighty million dollars in revenue and seven thousand canceled flights. An insurance analytics firm put the bill for the largest American companies at five point four billion dollars.

Now the part that matters for this book. A validator existed. Software whose only job was to check that file before it went out. It approved it, because it had been told to expect twenty-one pieces too. And every test before that day had used a wildcard in the twenty-first slot, a match-anything, which never actually reads the field. The bug had been sitting there for four months. July was simply the first day anybody put a real value in that slot.

If you do not test your software you build properly, you will lose millions of millions of dollars. That is what it looks like.

I am not telling you AI wrote that file. It did not, and I am not going to pretend otherwise to make a point. What I am telling you is the shape: the checking was real, and it was narrower than the thing it was checking. And since coding agents arrived, failures with exactly that shape have been arriving more often, because there is far more code going out and the same number of people looking at it.

A company whose entire business is protecting computers took eight and a half million of them down in one morning. So what would you have had to do differently to catch it?

Put one real value in the twenty-first slot. That is all. Not more testing, not better people, not a bigger budget. One test case that used an actual value instead of a match-anything, written by somebody who asked what happens if this field is ever filled in. Every failure in this book is that, and the reason the job is hard is that the question sounds obvious afterward and invisible beforehand.

For two years I was anxious about this and I got it wrong. I looked at the first coding agents and I was frustrated. What is this. This is stupid. I decided the whole thing was a joke.

Then in December 2025, I was following some small accounts on a social platform, people with almost no followers, and all of a sudden everybody was talking about one particular coding agent.

I run a company that teaches people to write code. My core competency was coding. So I wanted to believe coding was important. I did not want to believe a machine could do a better job for free, or very close to free. Believing that would be against my interest. And if it was true anyway, it could kill me, it could kill the business, it could kill my value proposition.

So I made a decision. Instead of holding on to my confirmation bias, instead of refusing to accept what might be reality, instead of resisting the technology because it threatened me, I wanted to give it a shot. I wanted to find out for myself whether coding was really gone. I wanted to find out for myself instead of reading other people's conspiracy theories about it, because I look for the truth, and I want to do the right thing, and sometimes the right thing is not the thing I want to believe.

So I started using it. Fifteen hours, sixteen hours, day and night, sessions running while I slept. My wife started telling people the coding agent was my new wife. I built five or six applications that people pay for. Then I rebuilt the company on it.

Here is what that saved. The customer relationship software, Salesforce, cost me $60,000 a year. I switched it off. Then the AWS hosting cost me $180,000 a year. I switched that off too. Add the two people who ran Salesforce and the software development team I no longer had to keep, and we saved around $700,000 every year. Three quarters of a million dollars, off the bill, and it did not come back.

In December I still thought they were wrong. By January I was using it sixteen hours a day. Nothing changed my mind in between. So what moved first?

The belief sat exactly where it was, and using the thing did not move it either. What moved was a number. I asked myself whether I could be radically honest with myself instead of holding on to my small-box belief. A small box, and I had built it. And if there is a 1% chance that they are right, I am not missing this train. It never asks you to be persuaded. You only have to agree the odds are not zero, and then go and use the thing until your opinion is made of something other than your own interest. You should be running this on me right now. I sell the training.

I am not the only one who could not read my own results.

A non-profit research group called METR ran a controlled experiment on sixteen experienced developers, working on code they already knew. Three numbers, and the order matters. Before starting, the developers guessed the tools would make them 24% faster. That is the prediction. Afterwards, asked how it had gone, they said the tools had made them 20% faster. That is the memory. And the stopwatch running the whole time said the tools had made them 19% slower. That is the fact. On a task that should take an hour, that is about eleven minutes lost, on every single one. They were wrong about their own speed, in the direction that flattered the tools, while somebody was timing them. The group has since said the picture is probably better now, and you should know that too.

So the first thing to get right is what this machine actually is.

Think about the weather. For years you have watched a clear sky in the morning and a sunny day afterward, and a heavy sky and rain afterward. So you predict, and you are right about seven times in ten. The prediction comes out of what you have seen before. It does not come out of any knowledge of tomorrow.

A large language model, which is what sits behind the tools you have heard of, works that way on words. Every single word is a next-word prediction, one word after another after another. It is not looking anything up. There is no drawer inside it holding the answer, and there never was.

Say it in plain language, because everything else follows from it. It is a prediction machine. It is not a truth machine.

When the guess happens to match the truth, you get a correct answer and it feels like the machine knew. When it does not, you get a wrong answer in exactly the same confident voice, and it still feels like the machine knew. That is in the DNA of how these things are built. It is by design. It is not a bug somebody will fix next year, because the predicting is the product.

Researchers at New York University tested what that means for safety. They set a coding assistant eighty-nine different jobs, asked for each one many times over so they had one thousand six hundred and eighty-nine finished programs in hand, and then went through every one of them looking for security holes. A security hole is a way in that nobody intended: a door left open that lets a stranger read other people's data or move their money. About 40% of those programs had one.

Old software could be held to the exact promise from the second movement: twenty dollars from the cash machine, every time, for everybody. Nobody yet knows how to write a promise like that for something that predicts. The best anybody has managed is a percentage, which is a strange thing to hand a bank.

Nobody ever shows you the prediction the software made. So when do you find out it was wrong?

After. Always after, and that is the whole difference between this and the weather. A forecast is handed to you as a number while you are still standing in your hallway. You hear it, you decide, you take the coat, and being wrong costs you a coat. The prediction inside the software is not waiting for anybody to read it, and here is the part people miss. These things are not being used to write sentences on a screen any more. They are wired into the software that runs the business. The prediction comes out of the machine and goes straight into the part that has its hands on the bank account, so the guess is not shown to anybody. It is carried out. It moved the money, approved the claim, updated the record, and the first human being to see it is the person it happened to.

One word pays your salary in this field, and it is worth slowing down for.

Think about everything you can do on Amazon. Open an account. Log in. Search for a product. Compare two products. Put one in the basket. Check out. Cancel the order. Return an item. Update your credit card. Change the delivery address. Write a review. Each one of those is a scenario, each has variations, and a company that size has ten thousand of them and more. A bank like Bank of America is the same.

Now somebody changes one line of code this morning.

That is the problem. Nobody knows whether the other ten thousand scenarios still work. Login worked yesterday. Does login work now? Checkout worked an hour ago. Does checkout work an hour from now? Nobody knows, because nothing was touched on purpose, and things break anyway.

Re-running everything that used to work, to prove it still does, is called regression testing. The word regression by itself means the opposite thing: it is when something that used to work has quietly gone backward and stopped working. So the damage is called a regression, and the work you do to catch it is called regression testing, and you will hear people shorten both of them to just regression. That is confusing and I did not invent it. Change one line of code and anything else could break. That is the single biggest risk in building software, and it is why, every time anybody adds anything, the entire set has to be run again.

Now put an agent on it. You can build anything you want, and the feature arrives, and that part genuinely is not the problem any more.

The first question everybody asks is: can you build it? The answer now is yes, always, quickly. So ask the second question instead. What happens when you add code on top of code?

The thing you asked for works. The checks are what nobody looks at. A check here is a written test, built once by a person and kept, so it can be run again whenever anybody wants. A serious company has thousands of them saved up, one for each thing the software is supposed to do. Those are the ones nobody ran, and you do not know which of them broke. Regression is the number one problem with agentic software development. Not building. Breaking what was already built, quietly, while you were busy being impressed.

And the damage a single change can do grew with the volume. Ten thousand scenarios, re-run every week, in every browser people use and on both kinds of phone. Done by hand, that is tens of thousands of hours a year, which is a room of ten people doing nothing else, forever, just to make sure the thing that worked yesterday did not get taken down because an agent inserted one line of code somewhere nobody was looking.

You added one feature this morning and something you shipped last month stopped working. Nobody went near last month's code. So how?

Because none of it is separate. Software is not a shelf of objects standing next to each other. It is one thing wired through itself, and the pieces get shared. The login screen and the invoice both need to know who you are, so somebody wrote that once and both of them use it. There is one copy, not two. Change it so the invoice prints your full name, and the login screen is now looking at the same changed thing, and nobody decided that. Nobody wrote that connection down, which is exactly why nobody thought to check it. And you cannot write them all down: a large application has millions of these shared pieces and the connections between them change every week, so any map of them is out of date before it is finished. That is why the only defense anybody has found is the brute one. Run all of it again, every single time.

If you live in Virginia you know Interstate 66. Out west it is eight lanes wide and the cars are doing 60 miles an hour. Then it gets closer to Washington and it narrows, and narrows, and near the city it is two lanes, and now you are doing 5 miles an hour, and sometimes you are not moving at all.

The cars did not get slower. The road got narrower. It is always the narrowest part that decides how fast anything arrives, and that narrow part has a name. It is called the bottleneck.

Software development now has exactly that shape. The eight lanes are the code, and they got wider, and everything in them is flying. Whatever my team did in one month, one person now does in a day. The two lanes are the people who have to say it works, and nobody widened those.

Writing code is not the issue. The bottleneck is software quality assurance.

Do not take that from me. Take it from the people with the data.

GitHub publishes a yearly count of what happens on its platform. In 2025, pull requests created went up 20.4%. A pull request is one batch of changes, offered up for somebody to look at before it goes in. In the same year, comments on those pull requests went up 0.35%, and comments on commits fell 27%. Production went up a fifth. Reading it did not move at all.

Uber's engineering team wrote publicly about why they had to build a review tool. Their sentence: reviewers are overloaded with the increasing volume of code from AI-assisted code development. They land about sixty-five thousand of those batches every week.

And it is not only counts. Stack Overflow surveys developers every year. In the last one, of forty-nine thousand of them, the most common frustration with these tools, named by 66%, was AI solutions that are almost right, but not quite. Another 45% said debugging AI-generated code takes longer than writing it themselves would have.

Google's own DORA research team went through one thousand one hundred and ten written answers from Google engineers. They gave their section a title I could not improve on. The verification tax: time saved writing is often re-spent auditing.

Every one of those organizations could hire more reviewers tomorrow. None of them is doing that. So what stops them?

Reading does not scale the way writing just did. You can double the amount of code by paying for more of the thing that writes it. You cannot double a careful human being by paying twice. One of Google's own engineers said it in a single sentence in that study: reviewing somebody else's code is so much harder than writing it, and AI tools are increasing the rate at which people can churn out code that needs to be reviewed. So the two lanes cannot be widened by hiring. They can only be widened by building something that does the checking itself, and that is a job, and it is the one at the end of this argument.

Something happened on the way to that conclusion that shows you how badly the industry confused production with progress.

Companies started measuring their engineers by how much of the machine they consumed.

Not what they shipped. Not what worked. How many tokens they burned. A token is roughly a word's worth of the machine's attention, and you buy them by the unit.

Jensen Huang, the chief executive of Nvidia, said it out loud. If you pay an engineer $500,000 a year, and at the end of the year that engineer has not spent at least $250,000 of it on tokens, he said he would be deeply alarmed.

Inside Meta, an employee built a dashboard that ranked eighty-five thousand colleagues by how many tokens they had consumed. The company burned sixty trillion tokens in a single month. One individual averaged two hundred and eighty-one billion of them, which on public pricing is well over a million dollars of spending by one person.

I said at the time what I still think. Token maxing is a very stupid way to lose money.

They worked it out. That dashboard was killed two days after a reporter found it. Meta's chief technology officer, who had been encouraging the whole thing, wrote that nobody should be using these tools just for the sake of using them, and that token usage alone is not a measure of impact of any kind. Uber burned through its entire year's budget for a coding agent by April. Microsoft told its staff plainly that this is not what we are optimizing for.

Now think about what an incentive like that actually produces.

Imagine a government announced tomorrow that every good Christian in the country receives $250,000 a year. Or every good Muslim. Pick whichever one you like, it works the same. Within a month, near enough the whole country is Christian, or the whole country is Muslim. The mosques are full. The churches are full. Everybody knows the words.

Now ask the only question that matters. How many of them actually believe?

Pay people for the outward sign of a thing and you will get the outward sign of that thing, in enormous quantity. So what happened to the thing itself?

It got quietly replaced by its own measurement. Engineers rewarded for consumption produce consumption. They generate code that nobody asked for, in volume, to move up a leaderboard, and it lands in the same place as the code somebody did ask for. Output is easy to count and correctness is not, so the organization measures the half it can see, rewards it, and gets more of it. A journal editorial put the reason in one sentence: prompting models and generating results is straightforward, but output evaluation is not.

Imagine I wrote a book. Four hundred pages, three months, my own life in it, every page mine. You are my senior editor. You read it before it can be published, and you come back and say: chapter fifteen does not make sense.

I fix it that afternoon. I know what is under chapter fifteen, because I put it there.

That is how software used to work. Every developer wrote every line by hand and carried the whole thing in their head, so a senior person could point at a page and get it fixed by the one human being who already knew that page.

Now run it again. The developer starts the agent and goes to sleep. The next morning there are eighty thousand books on the desk. The editor says something is wrong. What is wrong now. Nobody in that building has read eighty thousand books. You can read one book a day if you are superhuman. Assume you are the best editor alive and I hand you one of the eighty thousand, four hundred pages, and ask you to evaluate it in twenty minutes, because we are pushing it to production this afternoon. It does not matter how good you are.

And when I read my own book, I do not read the page. I read what I meant to put on the page, which is a different document, and it has no errors in it. So the editor cannot ask the writer, and the writer's memory, which used to do this job for nothing, left on the day the writing did.

That is where we are now. Agents write hundreds of thousands of lines a day. Reading them with human eyes, line by line, would take hundreds of years of human effort. The math does not close and it never will.

So the editor needs two things. A written statement of what the thing was supposed to do, made before anybody built it, by somebody who is not the thing that built it. A requirement is the sentence that says what correct means here. A test case is one checkable step that proves it.

Say you have that. Every chapter, written down in advance, by somebody independent. You still have eighty thousand books and one afternoon. So what has to change?

The reading, and this is the answer the whole book has been walking toward. Nobody reads eighty thousand books. So somebody turns those written statements into software that does the reading: a program that runs every check by itself, against all eighty thousand, overnight, and hands you a report in the morning saying which ones no longer match. That is test automation. The volume created the problem and automation is the only answer anybody has found to it, and the people who can build it are what the hiring is for.

I built the signup chain for our sessions myself, with an agent. The payment platform, the meeting tool, the email, our customer system, all of it wired together, and I did not type the code.

It worked. Somebody enters a credit card. The card is approved immediately. The confirmation link goes out and they are in.

Then some people did it the other way. They paid straight out of their bank account instead of with a card. A bank transfer is not instant, it takes two or three days, so the payment platform sat there saying in progress, processing, not successful yet. My software had been built to wait for the word successful. So it did nothing. No link, no email, nothing, for people who had already paid me.

The platform was not lying to me either. It said in progress. It said processing. Both of those are true and neither of them is successful.

I found out because two of them called me that morning, while I was doing something else, to ask where their link was. I apologized and sent the links out by hand, one at a time, which is the work I had built the thing to stop doing.

It worked 98% of the time. 2% of the time, my software failed. The 2% was the people who had trusted me with a bank account number, which is the group you would least like to pick.

The payment platform did its job. The code did what the requirement said. I checked it and the check passed. So where was the defect?

In none of the three, which is why nothing caught it. Successful was the only word my software had been taught to wait for, and I am the one who taught it. The requirement was right about the cases it covered. The code was right about the requirement. The check was right about the code. I checked it against the list in my own head, which is where the software had come from in the first place, and nobody had written the slow payment down because it was unusual. A check is only ever as wide as the cases somebody thought of, and my cases and my code came out of the same place, so the gap in one was the gap in the other. One person was standing on both sides of the question.

You will be told, usually by somebody selling you something, that a bug caught after release costs a hundred times more than one caught in design. There is a chart. One, six and a half, fifteen, a hundred.

It is not real.

Somebody pulled the thread. The chart traces to one line in a textbook, and that line cites a source printed in the textbook's own reference list: course notes, from an internal IBM training class, in 1981. Not a study. A handout. The two researchers who published a real version of it added the word often, and said the ratio is closer to five to one on small systems. The largest study anybody has run, one hundred and seventy-one projects, found no consistent effect.

The number this industry repeats most often, about the cost of not checking things, is a thing nobody checked.

You can write eighteen million lines of code, but if you do not test it you cannot deploy it.

Use the real cases instead. They are worse.

Boeing built the 737 MAX with bigger engines mounted further forward than on earlier models, which made the nose want to pitch up. Rather than redesign the aircraft, they added software called MCAS, the Maneuvering Characteristics Augmentation System, to sense when the nose was too high and automatically push it back down.

MCAS took its reading from a single sensor on the outside of the plane. When that one sensor lied, MCAS pushed the nose down. Each time the pilots pulled up, it pushed down again. And it was not in the flight manual, so the pilots did not know it existed.

Lion Air Flight 610. Ethiopian Airlines Flight 302. Three hundred and forty-six people died.

The international review afterward found that the aircraft was certified on revision E of that software while the safety analysis had stopped at revision C, and that no human factors test cases were ever designed for it. Boeing had not classified MCAS as safety-critical, which is the classification that would have forced regulators to look at it hard. By late 2020, the costs Boeing had itself disclosed came to twenty point seven billion dollars.

A trading firm called Knight Capital sent new software to eight servers and a technician copied it to seven. On the eighth, code nobody had used since 2003 woke up, and the part that told it when to stop had been moved years earlier and never retested. It traded for forty-five minutes and lost four hundred and forty million dollars. The system had sent ninety-seven warning emails before the market even opened. Nobody read them.

A sensor, a server, a routine update. Three small things. So why did none of the people responsible see any of it coming?

Every one of them was checked. That is the part nobody expects. The aircraft was certified. The trading code went out through a process. The update was routine, a word that means we have done this before. In each case the checking was real and narrower than the thing it checked, and nothing about a passing check tells you what it did not cover. So the job is not clicking buttons. It is deciding, in advance and in writing, what the list has to include, and being the person willing to stand up and say the list is not finished yet.

Let me show you the job from the inside, on my own software, because I do this work and not only talk about it.

A few weeks back I was adding the library to our learning system. New pages, new buttons, a new thing students can open. It sat on its own copy of the software, off to the side, where it could not touch anybody. We call that a branch, and at that point I had seventeen of them.

The full set of checks on that system is four or five hundred test cases and takes about four hours to run. I was not going to wait four hours on a branch. So I ran the smoke tests first, which is a small set that only asks whether the thing is standing up at all, and within about half an hour I knew the library worked and nothing obvious around it had fallen over.

Then I moved it to the QA environment, which is a full copy of everything, where the checks can run for real. And there I ran all four or five hundred.

They passed. Once all pass now you can deploy, and that is the sentence the whole job turns on. It went to production, the live one, the copy with real people in it, and the next morning a few thousand students logged in and the library was simply there, the way a door is there.

Somebody complained that day. Not about a broken page. He did not like the book I had put on the shelf.

Four hours, on a feature I had already watched working with my own eyes. So what was I actually buying?

That complaint. A man telling me my taste in books is bad is the most expensive thing that happened that day, and four hours is what it cost to make that the worst outcome available. Nobody thanks you for it, because nothing happened, and nothing happening is the entire product. That is why this work is invisible from the outside, and why it is the first thing an impatient company cuts. The four hours never show up anywhere. The morning they get skipped does.

What is happening to software has happened before, to every trade that ever got cheaper, and it went the opposite way to how it looked at the time.

Before the engine, business moved on camels and horses. Then the engine arrived. Did business go away? The camel traders lost their trade, and that was real. But the world's economy did not shrink. It grew by a factor nobody in 1800 could have imagined, because goods that could never travel started moving, and markets that could never reach each other connected, and there are more people making a living from trade today than were alive then.

In the 1980s a computer was a luxury. One machine cost more than a car, and only companies and wealthy families had one. The price fell. Did the computer industry shrink? Everybody on earth is carrying one now.

Same with cars. Same with air travel. Same with electricity.

An English economist wrote the sentence for it back in 1866, about coal. Make fuel cheaper to use, he said, and people do not burn less of it. They burn vastly more. He put it like this: it is wholly a confusion of ideas to suppose that the economical use of fuel is equivalent to a diminished consumption. The very contrary is the truth. And on the same pages, the part almost nobody quotes: he said the very workers whose labor is saved often find their labor in greater demand afterward, not less.

Now apply it here. The cost of producing software just fell through the floor. So the world is not going to produce less software. It is going to produce far more of it than has ever existed, in places that could never afford custom software before.

All of it has to be checked.

Every cheap thing in history arrived with people insisting the trade around it was finished. So why were they wrong every single time?

Because they counted the work that was disappearing and not the work that was arriving. The camel trader was right that camels were finished, and wrong about trade. What is scarce now is not a job title, it is the ability to look at software a machine produced and say whether it is right. That capability is in short supply, the volume of code needing it goes up every month, and I watch our own students walk into those jobs. They need more of you, not less of you. The AI industry has even started renaming it. They call it evals, short for evaluation, which means testing. Does it work or not.

I say the same sentence at the start of every session where somebody might hand me money: take this with a grain of salt, I could be biased, because this is what I do for a living. That sentence costs me people in the room. I keep saying it because the alternative is asking for money while pretending I have no position.

I had to accept that the thing I was best at, the thing I had built a company teaching, was the half that got cheap. Everything I know now sits on top of that, and I did not enjoy learning it.

And I still shipped the broken signup. The person who built it and the person who could not see it were the same person.

When somebody tells you the work is finished because the machine writes the code, you have one question. Which half did it make cheaper, and what happened to the other one.

When the thing that produced the work is also the thing that checks the work, you do not have two opinions. You have one opinion twice, and it is in the voice of whoever was most convinced already.

When a check comes back clean, you know one thing only: the cases somebody wrote down passed. An aircraft was certified. A deployment had a process. An update was routine. None of that is the same as correct, and the distance between them is where this job lives.

And when somebody hands you a number about how important checking is, check the number. The most repeated one in this field turned out to be a handout from a training class in 1981.

So remember this one thing if you remember nothing else.

A good software developer used to write five hundred lines of code a day, by hand, and they understood every line of it. They knew what the problem was. They knew what the solution was. Today an agent writes fifty thousand lines in a day and nobody knows what it wrote. Nobody knows whether it duplicated something that already existed, whether it left an error in there, whether it quietly broke the thing that was working yesterday.

The risk of software failure is higher than it has ever been. And writing the code is not the issue. Validating it is.

That is why the software quality assurance engineer, the one who has the fundamentals and the AI skills and the automation skills together, is going to be wanted in this market. There is more code than there has ever been, more features than there have ever been, more software than there has ever been, and every line of it still has to be true before it reaches somebody's money.

The man in the chat had the shape of it right. Something is ending, and he had the wrong half.

Everybody can build now. What nobody can do cheaply is look at what came out and say, with something behind it, that this is right. That is the job. It is open, and it is yours if you go and learn it.