davideisinger.com/static/archive/davegriffith-substack-com-o74bc9.txt

[1]
Dancing with Robots: A Software Architect's Journey

[2]Dancing with Robots: A Software Architect's Journey

SubscribeSign in

Software Development in the Time of Strange New Angels

[7]
Dave Griffith's avatar
[8]Dave Griffith
Sep 01, 2025
78
11
6
Share

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 ([14]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, [15]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.

━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━

Thanks for reading Dancing with Robots: A Software Architect's Journal!
Subscribe for free to receive new posts and support my work.

[36][                    ]
Subscribe
78
11
6
Share

Discussion about this post

CommentsRestacks
User's avatar
[                    ]
[                    ]
[                    ]
[                    ]
[45]
Josh's avatar
[46]Josh
[47]Nov 13
Liked by Dave Griffith

Bravo, looking forward to following along for more. Really enjoy your writing
style!

Expand full comment
Reply
Share
[50]
Tom Berman's avatar
[51]Tom Berman
[52]Nov 13

Really enjoyed the topic. I agree that it has completely changed the game.
After years as a professional software developer, AI coding is radically
different, I can do more, have more tests and cover more edge cases. I think of
it as a sort of higher level abstraction, instead of thinking in terms of
classes or functions more like full functionality.

On a personal note, there is some discomfort when a model spits out hundreds of
lines of code, and I go from slowly building a system which I fully understand
to one with areas of increased sophistication / complexity, that is almost
certainly better than I could write myself but struggle to understand.

Expand full comment
Reply
Share
[54]3 replies by Dave Griffith and others
[55]9 more comments...
TopLatestDiscussions

No posts

Ready for more?

[70][                    ]
Subscribe
© 2025 The Unloginable
[72]Privacy ∙ [73]Terms ∙ [74]Collection notice
[75] Start your Substack[76]Get the app
[77]Substack is the home for great culture

This site requires JavaScript to run correctly. Please [78]turn on JavaScript
or unblock scripts

References:

[1] https://davegriffith.substack.com/
[2] https://davegriffith.substack.com/
[7] https://substack.com/@davegriffith
[8] https://substack.com/@davegriffith
[14] https://csimarket.com/stocks/GOOG-Revenue-per-Employee.html
[15] https://archive.nytimes.com/dealbook.nytimes.com/2012/08/02/knight-capital-says-trading-mishap-cost-it-440-million/
[45] https://substack.com/profile/30699654-josh?utm_source=comment
[46] https://substack.com/profile/30699654-josh?utm_source=substack-feed-item
[47] https://davegriffith.substack.com/p/software-development-in-the-time/comment/176801025
[50] https://substack.com/profile/5558652-tom-berman?utm_source=comment
[51] https://substack.com/profile/5558652-tom-berman?utm_source=substack-feed-item
[52] https://davegriffith.substack.com/p/software-development-in-the-time/comment/176735220
[54] https://davegriffith.substack.com/p/software-development-in-the-time/comment/176735220
[55] https://davegriffith.substack.com/p/software-development-in-the-time/comments
[72] https://substack.com/privacy
[73] https://substack.com/tos
[74] https://substack.com/ccpa#personal-data-collected
[75] https://substack.com/signup?utm_source=substack&utm_medium=web&utm_content=footer
[76] https://substack.com/app/app-store-redirect?utm_campaign=app-marketing&utm_content=web-footer-button
[77] https://substack.com/
[78] https://enable-javascript.com/