code was never the point

Since I learned how to write code, I've become increasingly interested in the utility & economics of it, specifically within commercial settings. And, unsurprisingly, AI is dramatically shifting the calculus of code creation & maintenance - and therefore completely changing the value dynamics of software engineering - in some very interesting ways.

making things work

I first viewed writing code as a means of communicating my intent - line-by-line, imperatively - to a computer, which would thereby execute some procedure or calculation on my behalf. At scale, and especially when applied to commercial use-cases, this usually involved the creation and maintenance of large codebases which were designed to deliver some desired value to the business for an extended period of time.

Upon entering the workforce in the mid-2010s, I'd noticed that the skills required to imperatively type working code into a computer were hard skills - someone (like me) could be trained up to do it, and they'd generally do it effectively as a function of time-spent on the job. At the time, my naive perspective was that coding as a business function should be (and usually was) viewed as a profit-center on its own, and the best coders were technical wizards who could give companies a major competitive advantage if effectively put to use.

A lot of my attention (and that of much of the industry) shifted to automating the reliability & verifiability of code - that is, we engineered solutions that helped us develop trust that our code worked (and continued to work) as we expected, such that more code guaranteed positive outcomes. This was done through the implementation of increasingly popular practices like test-driven development (TDD) and static analysis, which automated testing and embedded code quality into our working models.

Writing working code was not a major bottleneck to delivering effective software, assuming there was enough capital in the business to hire & train up the right number of engineers who could get the job done. If the coded solutions solved the right problems, even if the engineers who built them were quickly cobbling code together without too much regard for readability, those engineers were typically seen as valuable assets to the business by virtue of the value delivered through their time spent coding.

the balance of good code

A year or two into my first full-time role, my focus shifted towards the constant upkeep necessitated by code in enterprise settings. An active, production-ready codebase needs to be kept in check - it shouldn't be allowed to organically become a large web of complexity, lest it turn into the dreaded & unmaintainable "big ball of mud," and engineering velocity slows to a crawl. Ideally, it'd be a well-organized system that can be easily maintained & evolved by teams of humans over extended periods of time.

I wrote about similar ideas quite early on in my career. I didn't say so explicitly in the post, but I was arguing then that organizing code & enabling its efficient evolution was much more a people and communication problem than it was a technology or automation problem. Crafting good production code was much more an exercise in anticipating the thought processes and needs of humans who will - weeks, months, or years into the future - need to change a few lines (or entire sections) of the codebase, ideally quickly, and without misunderstanding or breaking anything along the way.

Now, I don't want to dwell too much on what good code looks like. There are tons of books on this topic. But it's worth highlighting that optimizing entirely for the creation of good code, while tempting (especially to many of us engineers), ignores the reality that the best code combines the "goodness" of good code with the practicality of delivering business value at any given point in time. Mastery of the craft involves balancing trade-offs, managing risk, thinking strategically, and reasoning intuitively - all of which are behaviors that are not visible from the resulting code itself.

Put slightly differently, the goal of commercial software engineering has always been to maximize the enterprise value of a codebase, and not necessarily to minimize the cost of building it. Teams that knew the ins and outs of good code, and optimized appropriately for the continuous, practical evolution of their codebases and systems, gave their businesses significant advantages over competitors who lacked such qualities in their software organizations.

the human limits of LLMs

LLMs are interesting in so many ways. And I think it's fascinating to observe the manner in which agentic systems fundamentally change the premises by which we create & maintain code. Specifically, these systems upend many of the assumptions that underpin the legacy economics of software engineering.

Critically, LLMs are not humans. This is true despite the years-long marketing barrage that has hit the world - claiming that we have achieved AGI, or that LLMs will replace your colleagues, friends, and significant others - mostly driven by a few enterprises that have a lot to gain from the widespread public adoption of such a narrative.

The cost of writing code has fallen dramatically due to LLMs. But - as I observe above - the actual writing of code was never the true bottleneck. It was the act of designing the code, and doing so in a fashion through which it unlocked business value at the appropriate horizon, which was time-consuming and difficult to get right. This is all the more true when one considers the aforementioned strategic thinking and practical trade-offs involved in the software engineering process, which are tenets of the most valuable codebases that belong to a business, and are activities whose benefits are not directly evident from the code itself.

But - again - LLMs aren't human. They don't understand the long-term costs of poor abstractions, unclear interfaces, or technical debt in the way human maintainers of a codebase do. They are unable to empathize (or sympathize) with future engineers working on very bad or even very good code. And they do not have human taste, business sense, and intuition that make great engineers indispensable.

An LLM might take shortcuts, just like a human would. Worse, it might come up with some "clever" workarounds that serve as stumbling blocks in the future. At scale, when left unchecked, these shortcuts and workarounds compound and make it increasingly difficult for future contributors - both LLM and human - to appropriately understand and reliably evolve the codebase to meet the needs of a business and its customers.

Finally, AI cannot be held accountable for its work. I plan to write more about this separately, but suffice it to say, for now, that modern organizations run on accountability and trust. Finding the appropriate balance of AI-augmented execution with a sufficient layer of human accountability is becoming one of the premier challenges of software engineering, and this problem deserves more emphasis than it's getting.

AI in the value chain

Everything I've stated here up to this point has largely ignored the reality that, at the time of writing, agentic coding is consuming the software engineering industry at an unprecedented pace - a trend which has only seen exponential growth for multiple years on-end (ref). Agentic coding is an incredible tool! And if you're a professional software engineer in 2026 who isn't comfortable with the new paradigm, you are lightyears behind the rest of the industry.

But agentic coding is still just coding. Just like the imperative hand-writing of working code, agentic coding is a hard skill that can be learned.

So what happens when code is churned out at light-speed, as companies invest in AI capabilities, and engineers (and non-engineers) work out best practices for using coding agents? We're already seeing results, and there are tons of little improvements being implemented through the use of this new technology that accumulate into tangible operational efficiencies, especially at scale. However, one notable wrinkle is that there simply hasn't been a clear story of a noteworthy company using AI to achieve significant revenue growth. If layoff announcements are to be believed (which they shouldn't be), the highest-profile AI-driven wins for businesses have been centered upon savings associated with headcount reductions - and even that narrative is likely a misdirection, since those firms conveniently neglect to mention the COVID-era overhiring that is almost certainly the real driver behind these "newfangled cost savings."

These insights, combined with a popular belief (or hope, depending who you ask) that AI workloads will replace software engineering, highlights a common blunder where people conflate coding and software engineering. Code, while valuable, is not the desired outcome of software engineering. Code is a liability (ref), and if the same value can be extracted from a small amount of code as can be extracted from a large amount of code, then the path of less code should always be chosen.

This brings me to my point. In a world where code is cheap, the fundamentals of software engineering are more important than ever. This is not a novel idea, but it bears repeating in various forms until it's priced into the mindsets of everyone adjacent to tech, as well as the valuations of companies that rely heavily on software to run their core businesses.

Furthermore, the problem of compounding shortcuts & technical debt in code - massively exacerbated by the widespread adoption of coding agents - is bound to upend all existing heuristics around the value of maintaining existing code. When code is cheap, when does it become worthwhile to throw something away and replace it with brand new code, purpose-built for our evolving needs? Again, code itself moves out of focus, and engineering takes center-stage in the creation of actual results.

Code has always been a means to an end, and not the end in and of itself. But gone are the days when an engineer was seen as valuable just for their sheer ability to churn out lines of code. While still important, code alone can no longer be considered a differentiating asset that creates nearly as competitive an advantage as it historically has. The edge is shifting toward engineers with business sense, taste and judgment - what shouldn't we build? And how does what choose to build make a meaningful, positive impact on an enterprise and its customers?

outcomes over implementation

Markets have never cared much about code. Agentic coding, if anything, is a means to re-align the historically frothy and noisy priorities of software organizations with externalities that actually reward shareholder value in a refreshingly direct manner. It's a clear vector for pushing software engineers to be better fiduciaries to the businesses they work for, and - in many cases - are shareholders of.

As a manager of people, my biggest responsibility is to ensure that everyone on my team is driven by incentives that meet the highest-priority needs of the business. I can think of no better way to facilitate that line of sight than by continuously commoditizing one of the historically time-consuming activities that has been essential to our craft, and watching it fade to the background. Meanwhile, our attention shifts to the high-leverage and non-trivial task of creating valuable outcomes for the business.