Memory Lane

It seems somewhat fitting that now, March 11, 2026, almost three years ago to the day that OpenAI’s GPT-4 was released (and almost three years after I asked GPT-4 my first recorded questionI distinctly remember asking GPT3.5 to create a song about something in the style of Nine Inch Nails, but my ChatGPT.com history only goes back to March 27, 2023.

Compare March 2023 with March 2026. (I have no idea why I was interested in this.) ), I’m writing my first thoughts on it.

I must, however, confess I never was in love with the craft of programming. I would listen to people who talked about the Law of Demeter and spent hours custom-building just the right keyboard and had a VIM config that was as long as my arm and could navigate, keyboard-only, with blinding speed and efficiency and go “Wow, I am never, ever going to be as good as they are.”

I lost interest in software development as a careerI have always loved creating things with software. I just couldn’t be a software developer 40 hours a week for the rest of my life. because I was forced to care about things my brain just couldn’t. “Your method is too long! It must be less than 8 lines of code!” the linter would yell. And I would dutifully apologize and break it up into many small methods, for reasons that I still don’t understand and still find much more confusing and difficult to read and reason about than one larger method. Yes, I understand what you are asking. No, I cannot make my brain hold onto it while I’m coding, so you’re gonna have to yell at me after I wrote all of this code and make me re-write it. Great.

I also hated the programming languages; they all felt obnoxiousPHP? Mixing logic and presentation? Blech! Java, JavaScript, C++? So many curly braces and formality and boilerplate code. and didn’t jive with how my brain worked. I found Ruby/Rails in 2005 and enjoyed programming again but always knew I wouldn’t be the mythical “10x” developerI was probably a 2x developer, because I cared about things not sucking and did help move things forward, but the job market tends to be bimodal so either you’re a enterprise programmer, toiling away in the salt mines or working at the latest startup making millions at acquisition. .

I am technical, so I know what a good database is and what isn’t⊕But it’s web scale! , how to talk about architecture, I can tell the difference between acceptable code and hot garbage, rife with security holes and inefficiency. But I’m not the world’s best programmer and never will be. I maximally enjoy the results of programming and minimally enjoy the act of programming itself.

So I went into management and later entrepreneurship. I transitioned from manager to director to CTO, then CEO and founderWith some exits! .

I love the art of creation. Of starting from nothing and building a thing that people liked and wanted to pay for. For this, I absolutely love Agentic programming. Gone are the days in which I am sitting at my computer, stuck trying to figure out the best way to get started. I never have to worry about getting too far into something and realizing I need to refactor but am too demoralized to do so. Agents can refactor in an instant. Law of Demeter? That a problem for the agent to figure out. It’s internalized all this stuff so I don’t have to.

Yes, there are plenty of things to worry about, still, but the minutiae? It’s got it handled. AllIn the “copy-paste from ChatGPT web window” era I still wrote some “by hand”; now, in the Agentic era? the code I’ve written since ChatGPT is written by the LLM. I’m not too worried about increasing complexity of software or bugs or whatever - in the long run, better AI will render the inability for a human developer to “keep up with” the output moot.

But even with all this, I see growing storm clouds on the horizon. Since any given product feature’s cost is essentially Development Hours x Hourly Rate, agents shrinking development time to minutes or seconds drive that cost toward zero - fundamentally skewing the cost/benefit ratio. Hell, the ROI calculation approaches infinity! This means anything we can think of we ought to build, right?!

When building is free, the risk isn’t that we can’t build enough, it’s that we build too much and overproduceIn Lean manufacturing, overproduction is the cardinal sin; for many reasons product development isn’t a factory production line, but it’s close enough in areas that are important to consider. .

A Not-so-brief Digression on Complexity

In the olden days (you know, like a year ago, or right now for anyone who isn’t currently using AI to build software) product development hit diminishing returns.

Why? Well, Fernando suggests:

1. Support and maintenance workload
2. Building difficulty
3. Customers’ expectations and demands

You can read his excellent post to get more information but I think you can easily fill in the blanks as to what those are. But where the “Customers’ expectations and demands” are more in terms of “we need more from the product and it’s not giving it, I’m gonna leave” I think we’re missing a big one that is essentially contra to “we need more”:

4. Product has hit the “Coherence Threshold”

What’s the Coherence Threshold?

Before we dive into the exact definition let’s talk about software complexity. Complexity - as identified by Brooks in “No Silver Bullet” - can generally be broken up into two types: essential and accidental.

Development Complexity

• Essential complexity - inherent to the problem itself. You cannot remove it without changing what you’re solving. A tax filing product is complex because taxes are complex. That’s irreducible.

• Accidental complexity - introduced by your tools, architecture, process, history. It’s complexity that serves the implementation, not the problem. It can theoretically be eliminated.

Brooks’ point was that most of the hard work in software is essential, and that’s why there’s no silver bullet: you can clean up accidental complexity with better tools, but you can’t automate away the essential kind.

But that’s really focused on a software development perspective. I think there’s something about that in a product, too.

Product Complexity

We all know that Microsoft Office is complex. The essential complexity is huge because as a general-purpose productivity suite, the surface area of the problem to be solved is gigantic! Microsoft Word can be used to make a letter and the envelope the letter is mailed in! As well as make clip art and send faxes and zillion other things. That’s essential to solving someone’s problem.

The accidental complexity is that you might only use it to type up angry letters to the editor but someone else might use it to send faxes and someone else might use it to make HTML webpages and clipart! But you get everything in one package even if you don’t use it.

One person’s essential complexity is someone else’s accidental (and vice-versa).

Coherence Threshold

The coherence threshold of a feature is the point when the marginal cognitive load imposed on the user by a new feature exceeds the marginal value that feature delivers to them. The essential complexity is overwhelmed by the accidental.

The product’s coherence threshold is the point at which a product’s complexity begins to cost users more than it returns to them - when the burden of understanding what the product can do starts to erode the value of what it does do.

So what does this have to do with agents?

Another Digression on Product Development Loops

Product development functions as an OODA loopWhat’s an OODA loop? Check out my other post: How Winners Win: John Boyd . We gather data, generate hypotheses/tests, perform an experiment, get the results, and go back to step 1.

This takes real, actual time. It takes looking at the data, how people are using the product. You need to talk with them. You need to wrestle with incomplete, inaccurate, or incoherent feedback, using judgment to make decisions without full information. Sometimes users say they want a thing but they don’t. Some users use your product in ways you never intended, some use only small parts while others might strain the bounds of your design.

Either way, there are rarely hard-and-fast rules, almost never only easy decisions to make. Should we build X or Y? Well, that’s a matter of some combination of value (“Return on Investment”), strategy (do we want to do X?), alignment (prioritization, integration with other parts of the company), etc.

When you can go from “Idea” to “Working Feature” as quickly as you can bash out some words in a prompt box, we’re skipping a large part of product development that we used to ask is: should we build this thing at all?

Should we build this thing at all?

Since everything is free to build now, why should we ask this question? What’s the point?

When build costs trend to zero, every feature looks worth adding. But, total product value is asymptotic, not linear.

Coherence Threshold Revisited or Why It’s Zero-Sum Past the Inflection Point

Each feature past the inflection point adds value for some and subtracts it from others.

Why? Varied reasons - but calls back to “one person’s essential is another’s accidental” complexity.

After the inflection point, you’re not accumulating value in the product - you’re just redistributing it:

Snapchat - In 2018 their redesign merged Stories into the inbox. Result? First-ever user loss as a public company, stock dropped 16.5% on earnings and a later-reported 191m -> 188m DAU loss in one quarter. Partial reversalA petition to revert it garnered over 1.2m signatures. within months.

Evernote - They added Work Chat, a Food app, a Hello app, Presentation Mode, and tried to position themselves as enterprise groupware. Paid growth flatlined for 6+ months by 2018. Two major rounds of layoffs (2015, 2018). Eventually sold to Bending Spoons in 2023.

What Do We Do About This?

Product Discernment Is the New Bottleneck

Before features were free, we had implementation time/effort as a bottleneck that forced decisions.

Now that they’re free, we need to learn how to say No.

But, saying “No” to new features isn’t enough on its own. Nor, actually, might we need it as often.

Complexity Has to Be Actively Managed

I’m not alone in noticing a trend:

Elegant point from @edsim:

Velocity is now an org design problem

It’s why you’ll see so many layoffs.

The AI-native companies are lean. Incumbents are simply too bloated for the AI era. Too many layers. Too many stakeholders. Too many KPIs. Too many overlapping teams. pic.twitter.com/eKIPieEUqK

— BuccoCapital Bloke (@buccocapital) March 16, 2026

The bottleneck has so quickly moved from code generation to code review that it is actually a bit jarring.

None of the current systems / norms are setup for this world yet.

— Logan Kilpatrick (@OfficialLoganK) March 17, 2026

im fully convinced that LLMs are not an actual net productivity boost (today)

they remove the barrier to get started, but they create increasingly complex software which does not appear to be maintainable

so far, in my situations, they appear to slow down long term velocity

— David Cramer (@zeeg) March 16, 2026

I give it less than 6 months before Garry stops preaching LOC and starts preaching maintainable code bases.

And with that one move he will go from junior engineer to a bit more senior.

We watching his Eng journey live 🍿 https://t.co/UV9YjSgTtZ

— Jessie Frazelle (@jessfraz) March 17, 2026

We’re all familiar with technical debt - the potential future re-work we have to do to remediate today’s speedily implemented code. We deposit to technical debt intentionally (or accidentally) all the time across our code-bases.

But what about Coherence Debt? It’s not an exact analog of technical debt, but I think it’s close: Coherence Debt represents the potential future product re-work we have to do to remediate today’s cognitive overhead imposed on each user by features that serve other users. That’s a bit of a mouthful but I think you get it.

I like Justin Hilliard’s Product Debt definition:

Product Debt is what happens when you’re not yet successful. Coherence debt is a problem that only occurs when you are (possibly too) successful: you have hit product/market fit but for multiple, divergent customer segments. Each customer segment you successfully serve adds to coherence debt for all other segments. The more segments you achieve PMF with, the more coherence debt you’re running up. That’s what makes it so insidious; it accumulates during periods of success, not failure.

Companies tend to work around this with things like:

• Feature flags: same UI, some features hidden/enabled based on plan/segment/etc. Generates n^2 complexity and often implemented in a way that the users still sense the complexity because the product isn’t quite right for them.
• Role-based access: Admins get a dashboard, Moderators get some additional features, regular Users get something else. It helps segregate discontinuity but ends up being the “junk drawer” of product management.
• Custom software: slow to develop, expensive to maintain, “rots” and - perhaps more importantly - turns you into a “consulting company” which no SaaS product ever wants to be.

Or… we could “fork” the product experience.

The Fork Is Underrated

37signals (now Basecamp) wrote about “How to avoid the upgrade backlash”

…

So they left the older versions of Basecamp still online. If you liked Basecamp 1, you can still use it (so-called Basecamp Classic). And why not? The product doesn’t cost much to run, so it’s free money for Basecamp.

Why force someone to switch - to have an opportunity to consider alternatives instead of your new version - when you can just leave them on the old system, happy? Some startup has a product that does a fraction of what yours does - but does that fraction perfectly, simply, delightfully - and will catch their eye. Or, they’ll get Claude to do it for them.

Unless you want to cede this market to “I’ll just have Claude do it for me”, you’ve got to find a way to retain them.

The fork approach breaks out of the asymptotic feature value trap. Once you detect “too much” coherence debt, time to spin out a new product just for that segment! Sure, maybe 80% of it is the same, but that 20% just for them might turn them from a 7-8 NPS to a 9-10!

“But wait!”, you cry out. Didn’t we just talk about Lean and wastes and all that stuff? How will we maintain all this code? What about documentation? Support complexity? Not to mention how do we brand and market this?

This worked for 37Signals/Basecamp because they have a very specific business model (small team, profitable/self-funded, building for SMBs) and were using/developing Rails. Any developer could work on virtually any product. The support burden was small as existing customers knew the old product and the docs were already written. They had a strong brand and their blog posts and books were written by millions, so “Basecamp 2.0, 3.0, whatever” were easily introduced and sold.

One thing we know in abundance is that LLMs love to write. Spinning out multiple versions of the same product is now easier than ever! Coupled with hyperscalers, internal developer platforms and automation to host and run these easily, service architecture to re-use internal services across apps, developing bespoke featuresets that delight a particular segment but are irrelevant to another is now a thing.

Your enterprise customers can get all the integrations and the convoluted, bonkers workflow they know and love without requiring you to build a workflow-builder-builderAhh, the “custom workflow engine”. The “You figure it out!” homework you give to your enterprise customers. Also: The Big Hit and without requiring your customer to pay proserv to onboard them.

Yeah, you’ll still have to figure out which customers want what features, but that’s a thing you should be doing anyway. And since, in a sense, you’re now competing with every AI lab out there, you’re gonna have to figure out how to identify customer segments and reach them with the right message at the right time with the right positioning. Branding is now more important than ever. Customer retention is more important than ever. You never want a customer to go “Gosh, I wonder if Claude and some markdown do this better…”

Is it a thing we could’ve done before? Yes, but not without making every developer so sad and upset because they have to redo work that they come up with complicated ways to re-use as much code as possible, embiggening a 10 minute feature implementation to a 10 week major refactor.

Now? Just tell the agent to write more code. Don’t like it? Throw it away and build it again. Since you have the luxury of existing tests/workflows/etc. your spinoffs can become more and more “hands-off” than ever before. Agents don’t care.

Conclusion

I started this post by confessing I love creation (a feeling, a vibe, an activity) more than programming (a vocation, a career). Agents have been a gift to people like me; the constraints I always chafed against (the time, the minutiae, the sheer difficulty of getting started building the thing) have essentially evaporated.

Removing these constraints has revealed another one: good judgment.

Overproduction, in the manufacturing sense, is producing more than demand can absorb. It’s considered the worst of the seven wastes in Lean because it creates all the other waste as downstream consequences. Build too much inventory and you need warehouses to store it, logistics to move it, and eventually fire sales to clear it or your lenders come and take it.

Of course, in software products, we don’t have warehouses full of thingers on a shelf, but we do have the same overproduction problems. We have features only a handful of customers use, UX nobody can navigate, a combinatorial explosion of feature flags, and customers who churn because their problem - the one you solved perfectly in the past and made them feel special - became buried under different menus or more difficult to find. And while you were off serving new customers, the old ones quietly churn because that next new feature became the straw that broke the camel’s back.

The teams that win won’t be the ones who merely ship the most. They’ll be the ones who:

• Know which features to say no to (before opening Claude) and which to fork.
• Treat coherence debt as seriously as technical debt by auditing it, tracking it, actively paying it down.
• Are willing to fork - to give a segment the experience built just for them, because now the agent can maintain both.

Could we have done this before? Yes, but this work was generally only profitable in particular narrow circumstances; however now this fork is affordable. Multiple product surfaces, shared infrastructure, and agents doing the grunt work. Mere code production has never been the highest order term in the equation. It was never the main bottleneck.

It was always judgment.