logoalt Hacker News

pardstoday at 11:20 AM8 repliesview on HN

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.


Replies

SlinkyOnStairstoday at 12:13 PM

> 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.

show 1 reply
embedding-shapetoday at 11:27 AM

> 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.

show 1 reply
_pdp_today at 11:30 AM

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.

show 1 reply
chrisss395today at 12:34 PM

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.

kj4211cashtoday at 12:34 PM

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.

mattmcknighttoday at 12:13 PM

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

SAFe is poison.

razodactyltoday at 11:50 AM

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.

TrackerFFtoday at 11:43 AM

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