Why Software Development Fell to AI First

Not the future I was expecting, but probably the one I deserve

I find it’s always important to examine why you made a mistake. The worst mistake I ever made was reading “Bitcoin: A Peer-to-Peer Electronic Cash System” in January of 2009, thinking “cool math toy, maybe someone will turn it into something useful someday” and moving on. My most recent mistake, however, was not realizing that software development would be the first field to be transformed by agentic AI. I always assumed it would be the last. Let’s examine why that was.

The Obvious Reasoning (That Was Totally Wrong)

The logic seemed airtight: software engineering is hard. Not ‘requires training and practice’ hard - ‘one typo and nothing works’ hard. A lawyer’s brief with a typo is embarrassing. Code with a typo doesn’t compile. We measure code quality in ‘defects per thousand lines’ because even professionals ship bugs constantly. Getting software to production means catching a thousand tiny errors that each individually break everything. The precision required for software engineering is daunting even if it didn’t also require deep abstraction, complex problem-solving, understanding intricate systems, and juggling a dozen concerns simultaneously. I figured AI might handle some of that precision work eventually, but there wouldn’t be much value until it could handle all of it. Meanwhile, other fields seemed ripe for ‘good enough’ automation - scheduling, customer service, marketing copy. Tasks where you could be 90% right and still provide value.

So obviously AI would eat the rest of that stuff first, and programming—creative, complex, painfully precise abstraction-heavy work—would be among the last to fall. Add in a touch of motivated reasoning and the time-honored truth that “It is difficult to get a man to understand something when his salary depends on his not understanding it”, and I figured I could ride this career all the way to a sweet retirement in my Secluded Mountain Lair without some pesky robot coming in and altering the deal.

The robots had other plans.

What I Missed: The Perfect Storm

Software development turned out to be uniquely vulnerable to AI for reasons that had nothing to do with difficulty. It was vulnerable because of its structure, a structure that was created over the decades by … software developers.

1. The Feedback Loop Is Instantaneous

Write code. Run it. It works or it doesn’t.

In software, you know within seconds whether your solution is correct. The compiler tells you about syntax errors. The tests tell you about logic errors. The runtime tells you about everything else. These are all just software, and as long as you’re not connecting to the outside world or doing anything stupid, software is faster than a greased marmot on Adderall. Feedback is immediate, objective, and unambiguous.

Compare that to other fields: Marketing copy needs months to show results. Graphic design evaluation is subjective. Medical diagnosis has delayed outcomes and confounding variables—plus you can’t just reboot the patient and try again.

AI learns through trial and error. The technical term is stochastic gradient descent, but that’s just “try things, see what works, adjust parameters, wash, rinse, repeat.” The speed of that loop determines how fast you can train. More iterations over more data points means better AI.

Software development has the fastest, cleanest feedback loop of any professional domain. That’s not a minor advantage—it’s the difference between training an AI in weeks versus years. When you can run a million test cases and get objective pass/fail results in seconds, you can iterate until you get it right.

This is why software engineering AIs shipped first. Not because the problem was easier, but because the training environment was perfect.

2. The Corpus Is Public and Enormous

I’m old enough to remember when “open source” was a strange new idea being pitched by even stranger folk. The notion of publishing your professional work where anyone could see it was deeply bizarre—especially when the only justification was “visibility to your peers” or, worse, “out of the goodness of your heart.”

Fast forward thirty years. GitHub alone has billions of lines of code, publicly available, with commit histories showing how problems were solved. Stack Overflow has millions of Q&A pairs demonstrating common problems and solutions. Documentation sites explain APIs and patterns. Blog posts walk through implementations. God help us, even YouTube videos show you how to build everything from CRUD apps to distributed systems.

The entire knowledge base of software development is sitting there in machine-readable format, already digitized, already structured, already cross-referenced. It’s like someone spent three decades preparing the perfect training set for teaching AI to code. Except nobody was preparing anything—we were just being idealistic nerds who believed in sharing knowledge and showing off.

What other profession has that? Medical records are private. Legal documents are proprietary. Business strategy is confidential. Architecture firms don’t publish their full CAD files and decision trees.

We thought we were building a commons for human collaboration. Turns out we were building a training dataset for AI.

3. The Environment Is Deterministic

As has been widely commented on, the physical world is messy. Noisy, uncontrolled, filled with random interruptions and general folderol. Plus there are all these damned people running around mucking things up.

Software runs in environments we’ve made perfectly clean. Virtual machines. Docker containers. Cloud instances. Any time an environment wasn’t completely controlled, we invented more comprehensive ways to specify and manage it. “It works on my machine?” Fine, we’ll ship your machine as a Docker image. The entire execution environment for any decent piece of software can be specified, versioned, and replicated with a single command (that’s part of the definition of “decent”).

Compare that to almost any other field. Plumbers deal with houses built in 1952 with mystery pipes behind walls that may or may not be asbestos. Doctors treat patients whose bodies differ in ten thousand subtle ways. Lawyers work within legal systems that vary by jurisdiction, judge, and apparently time of day.

Software? If it works once, it works every time, in every environment we specify. That’s determinism. And determinism is catnip for AI training.

When inputs and outputs can be specified down to the byte, training runs become feasible at scale. When environments are perfectly replicable, feedback loops stay clean. No confounding variables. No environmental noise. Just: does this code work? Yes or no.

The robots didn’t have to deal with the messy physical world. They got to practice in the cleanest sandbox we knew how to build.

4. The Medium Is The Message

AI operates in text. Software is written in text¹. Training data is text. Output is text. There’s no translation layer, no trying to map one modality to another.

This is stupidly important and almost nobody talks about it.

When you train an AI to generate images, you’re teaching it to go from text (prompts) to pixels (images). Two different modalities. The AI needs to learn not just what a “sunset” is, but how to translate the concept of a sunset into specific RGB values at specific coordinates. That’s hard.

When you train an AI to understand speech, you’re going from waveforms to phonemes to words to meaning. Multiple transformation steps, each lossy, each introducing ambiguity.

When you train an AI to code? Text in, text out. The input format is the same as the output format. A Python function is text. An explanation of what that function does is text. The error message when it breaks is text. The fix is text. The test that validates the fix is text. The documentation that gets written about it is just more text.

It’s like teaching someone to translate French by giving them French documents and French translations, versus teaching them to translate French by giving them French audio and asking for interpretive dance.

Software developers work in text and output text. The AI doesn’t need to learn how to represent code as something else. Code already is what the AI speaks natively.

This is why LLMs got good at coding before they got good at robotics, or design, or plumbing, or anything involving the physical world. Not because code is easier—because the medium matches perfectly.

5. Verification Is Automated

Generations of software engineers have grappled with the problem of “How can we possibly convince ourselves that the software we’re building will actually work.” Fully general verification of software is mathematically impossible per Gödel, but that hasn’t stopped us from building partial verifiers, tuned to validate the sorts of software that humans actually wrote. We built type checkers to verify that our software was handling data with integrity. We built static analysis tools (“linters”, as the kids are calling them nowadays, although almost none of them know where the word comes from) to find common failure patterns. When those weren’t enough to get us to correctness, we built enormous testing infrastructures that let us specify properties of software that could only be checked via execution.

We built all of that for ourselves, so that we could sleep at night, and so that we could find and fix our mistakes as quickly as possible. While the tools weren’t perfect at finding issues, they were vastly more complete and comprehensive than the tools that other professions created to find their issues.

Unsurprisingly, the robots figured out they could use those tools too.

If you want to check the correctness of a legal brief, there are deterministic tools that can check your citations, but none that can really check the correctness of your argument, let alone it’s persuasiveness. If you want to check the correctness of a plumbing fix, you first need an experienced human eye looking it over, and then you just need to turn on the water and see if it leaks. Mechanical engineering and architecture have automated checks built into their CAD tools, but those provide much less robust validation than what we can do with software.

This is the secret weapon that made AI-assisted software development work so quickly: the AI doesn’t need a human to tell it whether its code is correct. It can run the tests itself. It can invoke the linter. It can check the type signatures. It gets immediate, automated feedback on whether what it generated actually works.

That’s not true in almost any other domain. An AI writing marketing copy can’t run a test suite to verify persuasiveness. An AI designing a building can’t automatically check if people will find it aesthetically pleasing. An AI diagnosing patients can’t run deterministic tests to verify the diagnosis before a human reviews it.

But an AI writing code? It writes a function, runs the tests, sees they fail, reads the error message, fixes the bug, runs the tests again. No human in the loop. The verification infrastructure we built for ourselves became the training wheels that let AI learn to code without constant human supervision.

We didn’t just make software development easy to learn. We made it possible to learn autonomously. The robots didn’t need us to grade their homework - we’d already built the answer key into the system.

Who’s Next

If the pattern is “instant feedback + public corpus + deterministic environment + text-native + automated verification,” what other fields match this profile?

The obvious answer: none of them completely. Software development was uniquely vulnerable because it hit all five factors. But some fields are closer than others.

Scientific research is tantalizingly close. Experiments have clear success/failure. Decades of published papers provide training data. Methods are (theoretically) reproducible. Results get peer reviewed. The feedback loop isn’t as fast as compiling code, but it’s faster than most human endeavors. If AI can accelerate hypothesis generation, experimental design, and result interpretation, we might see drug discovery and materials science move at software speed. That’s not scary—that’s civilization-saving.

Data analysis and quantitative research are already being transformed by the strange angels. Clean datasets, objective metrics, reproducible methods. The main barrier was that most corporate data is in private silos, but companies are rapidly deciding that AI-assisted analysis beats competitive secrecy.

Legal research has the corpus (millions of cases, public record) but lacks the feedback loop. You don’t know if your legal argument worked until the judge rules, which could be months or years. Still, legal research assistants are getting very good very fast.

What’s actually safe? Fields with messy feedback, private knowledge, and physical world constraints. Plumbing. Physical therapy. Negotiation. Anything where success is subjective, delayed, or context-dependent. Anything that requires navigating actual humans with their contradictory preferences and irrational behavior.

This is Moravec’s paradox playing out at the profession level. We thought “complex” work was safe and “simple” work was vulnerable. But complexity isn’t what matters—it’s the structure of the learning environment. Software development is intellectually complex but structurally simple. Changing a diaper is intellectually simple but structurally complex (try teaching a robot to handle a squirming baby).

The fields being transformed first aren’t the “easy” ones. They’re the ones with clean training environments and tons of data.

The Uncomfortable Conclusion

I was wrong about software development being last to be transformed, but I was wrong in an interesting way. I confused “difficult for humans” with “difficult for AI.”

Software engineering is genuinely hard for humans. It requires abstraction, precision, systems thinking, and the ability to juggle a dozen concerns in your head simultaneously. That’s why senior developers are rare and expensive.

But none of that matters for AI vulnerability. What matters is:

• Can the AI get fast, objective feedback?

• Is there enough training data?

• Is the environment reproducible?

• Does the work happen in the AI’s native modality?

• Can correctness be verified automatically?

Software development scores five out of five. That’s why it was upended first.

This flips our intuition about the future of work. The safe jobs aren’t the “simple” ones requiring less cognitive effort. The safe jobs are the messy ones—the ones happening in the physical world, with delayed feedback, dealing with humans and their infinite variability.

You know what job is probably safe? Kindergarten teacher. Try building an AI that can manage 20 five-year-olds with different emotional needs, keep them safe, teach them to share, and communicate effectively with their parents about behavioral issues. Good luck automating that feedback loop.

Meanwhile, I’m a principal engineer with 35 years of experience, and some days it feels like Claude Code can do half my job already.

Moravec’s paradox predicted that human-hard would be AI-easy and human-easy would be AI-hard. The corollary is that cognitively-complex professions are transformed first if they have clean learning environments, while cognitively-simple professions survive if they’re structurally messy.

We automated ourselves first not because coding is easy, but because we accidentally built the perfect training ground. We made our feedback loops instant. We published our knowledge. We containerized our environments. We made everything text. We automated our verification.

The robots didn’t outsmart us. We just made it really, really easy for them to learn.

---

This post was constructed as always with the able assistance of Claude Sonnet 4.5. No one’s figured out clean environments, feedback loops, or verification tools for humor, so you can blame the jokes on me.

1. If developing, building, or shipping your software requires anything other than typing text into an edit window, you’ve got bigger problems to solve before you start worrying about agentic AI.