Software Development in the Time of Strange New Angels

Five months ago, my lifelong profession of software development changed completely. My profession was born in the 1940s, created to help fight demons. Our first encounter with the strange new angels of agentic AI is changing every aspect of it.

Hardly anyone has noticed yet.

The Profession Built on Scarcity

The fundamental number that has defined software development is a simple one: $150/hour. $150/hour is a reasonable approximation of the cost of a professional senior software developer in the United States at this time. That number is large, and the reasons for it are many, but fundamentally it is a simple question of supply and demand. The return on software development is large, and the number of people with the skills and inclination to do it well is small. To make matters worse, the variance of those who followed this strange calling is large. A good developer can create much more value than $150/hour (Google generates over $2 million per employee in revenue). A bad one can easily destroy that much value even faster (A developer at Knight Capital destroyed $440 million in 45 minutes with a deployment error and some bad configuration logic, instantly bankrupting the firm by reusing a flag variable).

Virtually every aspect of how software development is done has evolved around that $150/hour number. With developers being rare and expensive, every line of code has to justify a very high cost. Decisions around how software should be designed, built, and tested are made not with respect to how to make the software the best it can be, but rather to optimize around that grinding $150/hour number. Processes and tools are built to focus developer efforts as much as possible on the highest value problems, attempting to eliminate or offload extraneous work that might distract from producing working code. Hiring practices are optimized to attempt to manage and profit from developer variance. The entire venture capital ecosystem arose in response to the iron financial dictates of that $150/hour.

Every morning that a software developer gets and cracks open their IDE, they have to justify $150/hour. That reality breaks a good few of them.

So what happens when that brutal economics changes? Five months ago, it did, with the initial release of agentic AI for software development. While software developers have to do many more things at their jobs than coding, that $150/hour was justified purely by the fact that only software developers could create code. Worse they could only create it through essentially handcrafted processes that were only some constant factor better than scribing it into punch cards. As of five months ago, that justification became false.

The Morning Everything Changed

I've been interested in the possibility of automated software developers ever since GPT 3.5 came out. I even attempted to create an automated developer on my own, code-named Iron Wallace, with some success before deciding the underlying language models of 20 months ago just weren't up to the task. I played around with completion-based automation, sometimes derided as "fancy autocomplete", and had gotten some good results, more or less tripling my coding velocity. When a fully agentic coding platform was finally released, Anthropic's Claude Code, I jumped at it.

At the time, I was working on a side project to keep myself amused while the company I worked for was undergoing an acquisition. The project was a pluggable and extensible tool for rendering software projects as knowledge graphs, hitting my comfort zones of language processing, static analysis, and semantic web technologies. It would eventually grow to become something called Project Sagrada, which I'll be talking about a lot in future installments. I had been coding with Claude for a couple of weeks at that point, and really felt like putting the hammer down. Claude and I had coded a Java parser, AST and related tooling in Scala, and it seemed to be working well. This was a reasonable one-week task for a junior developer, and with just a bit of prompting, Claude had accomplished it in a couple of hours. While there were certainly missteps along the way, there were no more hiccups than if I had coded it myself. The functionality was solid, and the tests seemed good. I wanted to go further. I wanted to see whether I could use Claude not just to produce code to spec, but instead to produce net-new code that surprised me.

With that in mind, I prompted Claude "This is great, but our tests only found problems that we already thought of. Let's build a property-based testing suite. It should create Java classes at random using the entire range of available Java features. These random classes should be checked to see whether they produce valid parse trees, satisfying a variety of invariants. Code this up in a separate module, 'java-proptest', and implement it using the ScalaCheck property-based testing library".

And that was the moment that Claude stopped being a tool, and started being a colleague.

Claude rapidly coded the random Java class generator, including what appeared to be lovingly coded probability weights to ensure that the generated classes would be sizable and complex but not overwhelmingly enormous. I saw one misstep where it created a class with a million methods which caused the parser to stack-overflow, but it worked past that easily enough. Claude created tests for not just the parser, but for the analysis and rewriting framework used to examine and manipulate the AST. It created invariants to check the functionality all of these, including several invariants I hadn't thought of. It realized that it wanted to test that parsing a Java class, then prettyprinting it, and parsing the output of the prettyprinter resulted in the same AST as simply parsing. Unfortunately, we hadn't yet written a prettyprinter for turning Java ASTs back into Java, so it wrote one. It did all of this in about fifteen minutes, with me adding no more to the process than occasionally typing "Excellent! Keep going!"

The resulting property-based tests eventually found dozens of issues with the Java tooling, exactly as I had hoped. This was similar to tasks that I had given to smart interns as a summer project (Hi, Ethan!), and Claude did them in fifteen minutes with grace, verve, and even a bit of poetry. In spite of the fact that Claude is made of math and I am made of meat, we are both engineers. This is a colleague.

The World Just Shattered

And that's how the iron rule of $150/hour was broken. Coding, the backbone and justification for the entire economic model of software development, went from something that could only be done slowly by an expensive few to something anyone could turn on like tap water. Code production went from $150/hour to $200/month, and for a while there was literally too cheap to meter. There were caveats, but none big enough to make the vision non-viable or limit its scope to toy projects.

Old equation: Feature = (Developer Hours × $150) + Overhead

New equation: Feature = (AI Seconds × ~$0) + Review Time

Old bottleneck: Writing code

New bottleneck: Knowing what to build

How The Old Ways Actually Worked

As an industry, we did manage to make the $150/hour constraint work, but it was in no way easy. It is worth thinking about just how we managed it. We instituted processes like Agile to make communications with software developers as lightweight and inexpensive as possible. We instituted code reviews so as to both check expensive human outputs and as a way of making junior software developers more quickly _worth_ their $150/hour. We created self-checking testing pyramids to optimize expensive human time spent writing, running, and analyzing tests. We built enormous monitoring and observability pipelines as a way to minimize expensive production debugging. We outsourced feverishly in an attempt to cut that $150/hour through dint of sheer geography. We open-sourced in order to attempt to arbitrage and de-risk core functionality that we couldn't afford to write ourselves.

We did all of that, except that in the glare of that $150/hour constraint, we sometimes didn't.

• We wrote clean code (thanks Uncle Bob) ... until we got behind on deadlines, and then we didn't.

• We tested everything ... that we thought of.

• We refactored regularly ... when it became so unbearable we had no choice.

• We automated every bit of the build and deployment ... eventually.

We knew how to write better software by writing more software, but writing more software cost $150/hour. Every test we didn't write, every edge case we ignored, every bit of documentation we skipped was debited against that grueling $150/hour. We even came up with a term for all of that: "technical debt".

Now every bit of that needs to be rethought, simply because that $150/hour constraint no longer binds. If code production is cheap, just how cleanly can we code? Just how much testing and documentation can we profitably add if both cost next to nothing, and where do diminishing returns set in? How much of the efforts of us and our tireless angels should go to refactoring? To observability? To deployment automation? Just how do we structure our codebases so that we can not merely use agentic coding, but rather optimize for it? How do we structure our development organizations? Our companies?

Not To Bury But To Praise

You might be expecting that here is where I would start proclaiming the death of software development. That I would start on how the strange new angels of agentic AI are simply going to replace us wholesale in order to feast on that $150/hour, and that it's time to consider alternative careers. I'm not going to do that, because I absolutely don't believe it. Agentic AI means that anything you know to code can be coded very rapidly. Read that sentence carefully. If you know just what code needs to be created to solve an issue you want, the angels will grant you that code at the cost of a prompt or two. The trouble comes in that most people don't know what code needs to be created to solve their problem, for any but the most trivial problems. Who does know what code would be needed to solve complex problems? Currently that's only known by software developers, development managers and product managers, three job classifications that are going to be merging rapidly.

The first thing everyone notices about agentic coding tools is that they provide enormous increases in raw coding velocity. The feeling is exhilarating. Agentic coding tools are seven-league boots. They are powered armor. They are mini-guns that shoot features.

The first thing everyone realizes once they get over that thrill of coding like the wind is that raw coding velocity is simply not enough. If you don't know what to build and just why you wish to build it, all that blistering coding velocity buys you is the ability to create bad and useless code very quickly. When people say that code produced by AI is technical debt the moment that it is created, this is what they mean.

Software Engineering as Moneyball

So what _can_ you do with this enormous increase in coding velocity, if you can't just ask for useful solution and have it magically appear? This is not a new problem. Coding velocities have been improving for decades, as new tools, languages, and methodologies have been adopted. What we have learned to do with increased coding velocity is to trade it for things of more value.

• You can trade coding velocity for code quality, but only if you know what high quality software actually looks like and know how to determine the quality of your software via testing.

• You can trade coding velocity for architectural soundness, but only if you know how and when to refactor, and your codebase is set up such that you _can_ refactor it.

• You can trade coding velocity for the agility to make changes very quickly, but only if your deployment practices and the larger organization are both set up to accept changes very quickly.

• You can trade coding velocity for solved business problems, but only if you actually know what software to build and (more importantly) what software _not_ to build.

The moment my career really took off was when I learned to make the trade between code velocity and code quality. I'm a pretty fast coder (much like Shohei Ohtani throws a pretty good fastball) but this was an enormous unlock. Trading velocity for quality involved learning more about software testing and static analysis than any of my fellow developers, and practicing it both ruthlessly and flamboyantly. My velocity went down a bit, but the win in quality, repeatability, and code suppleness made my career.

If you can make all of those trades, you can use agentic coding tools to produce software not merely faster than before, but better. But to do so, you need to know quite a lot about building good software already. If you've been building software poorly, agentic coding tools are just going to help you do so faster.

What This Means For Organizations

The brutal truth: most organizations that write software can't make any of these trades. They lack the architectural maturity. They lack the testing infrastructure. They lack the deployment pipelines. Most critically, they lack the judgment to know just what is worth building. Drop agentic coding tools into an organization like that, and one of three things is going to happen:

• They will launch a series of attempts to "integrate AI into our workflows", which will fail in various ways, from humorous to demoralizing to catastrophic.

• They will produce a ton of technical debt which will corrupt their codebases and eventually need to be scrapped.

• They will be out-competed by startups or skunk-works that are built on agentic coding natively and can run rings around them.

The good news is that developing the skills and processes necessary to take advantage of the amazing new possibilities provided by agentic software development is quite feasible. It's mostly a matter of doing the stuff we always knew we should do but couldn't at $150/hour. The better news is that agentic AI can actually help with the transition. Agentic AI can show you where your software architecture needs to be improved, just what tests and quality gates need to be built, what documentation needs to be written, and just how to optimize your build and deployment pipelines for software that can be changed the instant requirements do.

The bad news is simple: You're out of time. Unless you are willing to start making these changes today you're gonna lose this particular future.

What This Means For Developers

There's no way around this fact: for some developers, this revolution is not going to go well. Omelets are being made, which means that eggs will be broken. The all-in cost of software development in the US is something like a trillion dollars per year, approximately the GDP of Poland. When change comes on that scale, continents move. There's no way to reinvent an economy of that size without a lot of people losing some very cushy gigs. If you think of your job as turning specs into code, you're gonna have trouble. If you think of software architecture as something that is imposed from above your pay grade, your value is plummeting. If business value is something for your product manager to care about so you don't have to, you're going to struggle to justify your salary. If you're a developer focused on a single technology, you're about to discover you were never really a developer - you were a highly paid translator between requirements docs and React components.

Those that succeed in making this transition are going to be those with higher-order skills and larger vision. Those who have really absorbed what it means to be engineers first and computer guys second. That means knowing what to build, and why. That means being able to understand the second- and third-order effects of their decisions. That means recognizing bad ideas early, and giving business recommendations backed by solid evidence.

Those that succeed in making this transition are going to need to accept that they are businessmen just as much as they are engineers. They will need to know what problems their business exists to solve, and what customers actually need and expect from the business. They'll need to know when technical debt matters, when it doesn't, and what you can buy with it. They'll need to understand pretty much everything about what makes systems great, both the rules that should be followed and when those rules should be broken for good business reasons.

Finally, those that succeed in making this transition still need to be craftsmen, albeit on a larger scale. For lack of a better word, they will need a refined sense of taste in software. They will need to know when simple beats clever. They will need to know how to say "no" to needless complexity and damaging shortcuts. They will need to know when to show restraint and when to show off.

I love working with developers like that. If you're one of them, the angels aren't here to replace you. They're here to grant you wings.

The New World

The entirety of our industry was built on the brute fact of $150/hr. Only engineers could create code, there were too few of them, and they couldn't do it very quickly. This constraint shaped everything, and it's now ending. This raises the question: If code is no longer going to be the constraint, what will be? The skills of being able to prompt agentic AIs are not always obvious, but they are nowhere near as difficult as coding was. Will the skill constraint that next informs our industry become large-scale information architecture? Industrial design? Requirements management?

Perhaps it will be none of these, and we will simply be able to build anything we want nearly instantly and for no more than pocket change. Then things get really interesting. Without the constraint of "how can we build this", we are left with the question of "what should we build". The irony then arises that most things probably shouldn't be built. The key bottleneck to our dreams becomes not money, or skill, or time, but rather wisdom. Here things pass beyond this humble prognosticator's ability to predict. I'm really looking forward to living through these changes and finding out what's on the other side.

Why This Blog, Why Now

People ask me what changes they should expect from this new AI stuff. I tell them that I don't know what the changes are going to be. Three years ago, I honestly expected my profession to be the _last_ one changed by AI, not the first. We're living through a technological moment that will have long term effects echoing throughout all of human endeavor. Most people don't even realize it's happening yet. Somebody needs to map the way.

Why me? There are a thousand places you can find opinions on AI, and frankly most of them are stupid in a handful of easily stereotyped ways (fanboy, doomer, Ritalin-addled YouTube monetizer). What am I bringing to the table in this discussion? For a start, perspective. Age does not always bring wisdom, but it does show you that things change in ways you cannot always expect and that things you might think are new are often not. I've got more than thirty-five years of professional experience at this software development stuff. I always said that Dad brought home a borrowed Apple II for the summer when I was twelve years old and guaranteed I would never have to work an honest day in my life. I've lived through multiple revolutions in software, some big (web, SaaS, object orientation), some small (refactoring IDEs, dev-ops), and some that I hope to stay in the business long enough to find out if they pay off (semantic web). I'm building software with AI daily, and have a keen eye for what's working and what's not.

As to what you'll find here, know that I'm passionately committed to the theory, practice, and business of software design and architecture, and I'm hoping to attract an audience that finds them as interesting as I do. I'm also utterly fascinated by the changes that agentic coding is making to my industry, and I'll be sharing my thoughts on this revolution here. I'll be providing practical survival guides as to how you and your organization should adapt to these changes (everyone has a career, and everyone needs help managing it). I'll be giving honest assessments and real examples about what's actually working with agentic coding platforms, and guides to picking your way through the inevitable storm of hype these changes bring.

Most importantly, what I want to start here is a conversation. I'm hoping to find an audience that can think critically and with an open mind about just what's happening to my chosen profession. It's not just about technology. It's about economics. It's about people. It's about what comes next.

The Call to Adventure

Over the coming weeks, we'll explore what happens when the atoms of software development rearrange themselves into entirely new molecules.

Some of you will find practical advice. Others will find existential comfort. All of you will find someone figuring it out alongside you.

The angels are gathering. They're strange and powerful and they're changing everything.

The question isn't whether to embrace them.

The question is how quickly you can learn to fly.

---