davideisinger.com

davegriffith-substack-com-o74bc9.txt (25083B)

---

 [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/