In my large enterprise world, AI adoption hasn't made it outside of the development teams - only developers have access to Github Copilot.

Code takes 6-12 months to make it from commit to production. Development speed was never the bottleneck; it's all the other processes that take time: infra provisioning, testing, sign-offs, change management, deployment scheduling etc.

AI makes these post-development bottlenecks worse. Changes are now piling up at the door waiting to get on a release train.

Large enterprises need to learn how to ship software faster if they want to lock in ROI on their token spend. Unshipped code is a liability, not an asset.

> Development speed was never the bottleneck; it's all the other processes that take time: infra provisioning, testing, sign-offs, change management, deployment scheduling etc.

So much of Management (both mid and executive) still considers Software as if it were an assembly line; "We make software just like how Ford makes cars". Code as a product.

Which isn't to say that most software development isn't woefully inefficient, but the important bits aren't even considered. "The Work" is seen as being writing code, not the research that goes into knowing what code has to be written.

And for AI marketing, this is almost a videogame-esque weakspot. Microsoft proclaims "50% faster code!" and every management fool thinks "50% faster product; 50% faster money!"

> Large enterprises need to learn how to ship software faster if they want to lock in ROI on their token spend.

It's going to be a disaster once ROI is demanded. Right now everyone is fine with not measuring it; Investors are drunk on hype and nobody within the company actually wants to admit that properly measuring software development productivity is almost impossible.

But the hype won't last forever. Sooner or later investors will see the "$2M spend" and demand "$4M net profit", and that's not going to materialize.

Copilot and Claude won't be tackling the real bottlenecks. They're not going to dredge up decade old institutional knowledge, they won't figure out whether code looks bad because it is bad or because it solves a specific undocumented problem, they won't anticipate future uses.

Code just isn't the product. Not the real work. Really, if your codebase is in a healthy state, it's often a literally free output of the design and research processes. By the time you've refined "our procurement team finds the search hard to use" into a practical ticket, the React component for the appropriate search filters has basically already been written, writing up the code is just a short formality. Asking Copilot would turn a 10 minute job into a 5 minute job. Real impressive, were it not for the 6 hours of meetings and phone calls that went into it.

> Large enterprises need to learn how to ship software faster

They haven't even learned that "less code is better" yet, I wouldn't hold my breathe waiting for them to suddenly learn "more advanced" things like that before they learn the basics.

Yep.

I would argue that any sufficiently large system reaches a point where more code is in fact the opposite of what it needs.

Nutrition and calories are only useful up-to a point and then we have diminishing and later on negative returns.

Even-tough it is not the best analogy because we are describing two different system, it helps put a mental model around the fact that churning more is often less.

Side Note: A got a feedback from a customer today that while our documentation is complete and very detailed, they find it to be too overwhelming. It turns out having a few bullet points to get the idea across it better than 5 page document. Now it is obvious.

What's old is new again [0][1][2]

The Theory of Constraints - AI Era

[0] https://en.wikipedia.org/wiki/Theory_of_constraints

[1] https://www.goodreads.com/book/show/113934.The_Goal

[2] https://www.goodreads.com/en/book/show/17255186-the-phoenix-...

Its trickling in slowly to non dev teams. Im consulting with a large fin-tech on Enterprise-wide AI adoption at the moment, and I'm seeing the same parallels though: you have power users that reap disproportionate rewards from it, and then you have the "tab complete" crowd that copy paste things into the prompt.

This was a huge motivation behind me trying to design an AI automation platform that comes "batteries included". I also think a lot of orgs, even engineering orgs do not know how to configure basic things like Claude plugin repositories into their installs.

"release train" ... "learn how to ship software faster"

SAFe is poison.

Unshipped code can't break. How is it a liability and not an asset? The money maker is making money and the changes that potentially would interfere with that are held up at the gate. Seems like a good thing from a business perspective.

It's good to know your experience mirrors mine. Developers are moving faster, but the rest of the organization is holding them back because processes and decisions still rely on other parts of the org. Has anyone else observed the same?

Organizations "born in AI" appear to buck this trend for obvious reasons (no legacy org. to deal with). My two cents.

We have a "two timelines" approach going on and I'm curious if others are seeing the same. There are official "Engineering-supported" services. There development speed is not the bottleneck. Engineers demand clean requirements that take forever to show up. Testing and deployment scheduling also take forever post-development. Important people are so fed-up that they've started hiring people to vibe code and develop services without going through Engineering. Code is shipped much faster here but technical debt accumulates rapidly. The important people are beginning to hire Data Scientists who sit outside of the Tech org to manage the AI code. It's all very interesting.

The Mythical Man Month should really be a mandatory reading for anyone working in software… and I don’t mean reading a Claude summary

But then how will all of the know-nothing management types get their fingers in the pie?

Same here, but instead of the developers having access to Github Copilot, some selected few devs have access to some internal proxy, that goes to Amazon bedrock, where we have "400 request" per week to Claude Sonet :))))

Especially when it waits a month and all the effort is either irrelevant or incompatible with latest changes that finally got through. So much token wastage to top off the recent chaos. Hopefully it improves just as fast as it materialised.

Which is why there's currently a gold rush of "Enterprise AI" startups which implement / offer agents to enterprise businesses.

Do you work in my company? :)

I kept saying this since Day 1 of llms - even 99% of development reduction means almost nothing in our company in speed of delivery of whole projects. And we are introducing generator of code that semi-randomly has poor performance when they have perf bottlenecks and fills the codebase with... sometimes questionable solutions. Sure, one has to check the results all the time, but then time is spent on code reviews, not much less than actual (way more fulfilling, rewarding and career-boosting) development.

Now I understand there are many more scenarios where gains are more realistic and sometimes huge, but it certainly ain't my current working place. So I use it sparingly to not atrophy my skillset but work estimates are so far the same and nobody questions that.

Sounds like the typical ServiceNow paralysis. The “Mother May I” model.

[dead]