Hacker News

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

My larger enterprise world today AI adoption seems to have taken a turn for the worse.

Finance folks reached out asking if they could vibe code their own app using Copilot/Cursor/Claude for finance planning purpose. And because they know my management freezes whenever there are whispers of "our CFO said so" they even paraded that reasoning - "our CFO "tested" Lovable and he is convinced and asking us to vibe code the app".

If that is not enough they ended with a nicely wrapped reasoning of "we need to try this to be sure that using vibe coded app can exist in enterprise finance with appropriate data security and maintainability".

And mind you this is a reasoning at a company with more than 20+ billion in revenue.

It may not be the biggest bottleneck, but if you can have a similar amount of time, but reduce the number of engineers by 30%, that's a huge win.

And having less people involved means there is much less communication and alignment.

Not to say it's a panacea.

> Unshipped code is a liability, not an asset.

"Hey we found this bug and-"

"We already found it with Claude, we're still waiting for out next release."

Or worse, its a bug that doesn't exist in prod, since the code keeps changing, and you wont know about the bug until its out there because there's one niche user with a niche use scenario everyone forgot or didn't even know existed, and he's going to somehow crash the entire system with your next deployment.

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

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.

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

SAFe is poison.

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 :))))

> Code takes 6-12 months to make it from commit to production.

That seems wild, niche/highly specialized field?

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.

Meanwhile in private equity world, they have realized that code is "piling up from 10Xing everyone's performance" and as a result they have solved it by just firing all QA, focusing only on speed to prod, killing signoffs, and scheduling and code review. We are probably going to bankrupt ourselves from an idiotic mistake somewhere here. But nobody will ever know until it happens. Don't take those gates for granted.

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.

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

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.

I don't know who needs to hear this, but: shipped code ia a liability too.

Shipped code can fail. Shipped code can corrupt or delete production data. Shipped code can break your customers trust. Shipped code can lead to literal court cases. Shipped code can force hasty fixes and all nighters.

Some people can afford to yolo their code others can't. Maybe me having programmed for expensive hardware that punches a hole into a brick wall, burns up in a cloud of smoke or hurts people if you make a mistake has to do with the fact that I know.

The LLM won't go to jail for certain things. The one who signed of on the code may.

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.

This will eventually bubble up and get exposed and then things will start to roll fast.

That's enterprise tech also?

I wonder what adoption is like at older non-tech companies.

The office next to mine is being used to teach a bunch of 20-30 year olds how to be insurance brokers using a powerpoint presentation. Copy paste the presentation into an LLM and you just replaced them all. It feels like... things might be kind of dark in 10-20 years if we just keep barreling down this road.

Every line of code is a liability

> lock in ROI

On code you cannot possibly copyright. Yea they're all on the verge of "Locking in."

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

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.

There are so many elements to this. I've worked in nearly every part of software orgs. Development, ops, professional services, pre-sales. There are bottlenecks everywhere. Faster shipping gets you nothing if your customers procurement budgets don't increase and they're not buying anything. You can wow new customers and lure them in with shit you get out the door super quick that appears to work but falls flat after six months of usage, but you damage your reputation in the long run. So how do you guarantee your software will actually work after six months of usage? You have to test it by running it yourself for six months. There is no other way. No automated suite can exercise every single possible customer use case over a long period of time. It's a combinatorial problem.

Just yesterday I was in a meeting with a customer asking if we could make our FOSS virtualization platform work such that if you yank the root disk out of a server and put it in another one, everything will work with no hiccups. Well, provided it's exactly the same model and you're going to put it on the same network with all the same IP assignments, you've got a shot. I've actually tried to do this before for the hell of it and I only needed to account for the MAC addresses of the NICs being different, as long as you have no other drives and everything else is exactly the same. I'm sure I could whip up something that scans for the predictable interface name and changes the old MAC stored in the NetworkManager configuration files (and wherever else they might happen to be) and change them to the newly discovered one before making a DHCP request, and maybe that will work, but how certain can I really be? I can test on servers I have and I don't have every possible combination of data center equipment all of our customers have. There is no feasible way to test every possibility. Having an LLM whip up the code for me instead of writing it myself doesn't change that.

Ironically enough, that customer is making software for another customer and their own requirement is that it has to run on very hardware on an airplane, which they don't have. So they're working on little NUC clusters in their cubes and at their houses instead, because their company doesn't have extra true server racks for them to use and no budget to acquire them, which probably won't change any time soon given the spike in hardware prices. They're all using AI but what good is it doing? They're spinning their wheels because they're targeting a runtime environment that doesn't exist that they can't test on.

It's a weird folly of the Internet age that the largest companies in the software world are all web companies. Mostly, they're media companies in disguise. Their only real product is human attention and they sell it to advertisers. Tech is just the vehicle that allows them to deliver it. We've valorized their "ship as fast as possible" ethic, which maybe matters, maybe doesn't, but it was never the source of their value. Nobody spends ad money on Facebook and Google because of the quality or delivery speed of their software. It's the human users and data they've captured, which to be clear, software plays a huge role in, but it's not a model all software companies can follow. We don't earn revenue from half braindead doomscrollers wasting most of their day with a background drip of vaguely dopamine-boosting noise blasting into their senses while they leak every fact about their lives to media companies. Our customers have to make intentional decisions to spend money out of finite budgets.

There's another story on the frontpage right now of Coinbase laying off a bunch of its employees and using AI to write more code. Okay, great, but the best that can do is reduce labor expense. They only earn more revenue if consumers decide they want to buy more Crypto and hold it in Coinbase. If Coinbase is using AI to write their software, so is everyone else, so that doesn't give them any kind of edge on quality or shipping speed. Their success is going to be determined overwhelmingly by whether or not people want to buy crypto, a broad market trend completely out of their control. No one in any business ever wants to admit this, but we're all at the mercy of these broader trends.

People are all over this thread citing Ford. Ford didn't decline because they couldn't ship fast enough. They declined because the market stopped wanting what they were making except their full-size pickups, and it's largely just Americans that want that. I don't blame them or think they did anything wrong exactly. People love to do these post-mortems contemplating a world in which someone like Ford accurately predicts every single shift in consumer sentiment that will ever happens and always stays ahead of the curve. It'll never happen. Everything that goes into style eventually goes out of style, and your ability to ship out of style shit faster won't help you.

You said you work for a bank and I'm honestly curious. What causes a customer to choose your bank over another? Do you think it has anything to do with software features? I'm lucky I even got a meeting with the customer I was with yesterday. He told me he loves our product and fought hard for it over a chief architect who wanted something else and made them do a long comparison study to prove our product met their needs better. Why did that chief architect prefer the other product? He plays golf with their CTO.

[dead]

1) The game is not ending, it's changing. AI can sling a lot of code but we still need engineers that actually understand what the hell is going on. That's always been the bottleneck. It could eliminate junior positions, but seniors are fine for now.

2) It's been a hard lesson for me to learn because I'm naturally a contrarian, but you are hired to do what management wants you to do. If you resist, your best bet is to hope they don't notice or care, but it's not going to change much.

Seems like the upside is that it makes the job way easier? What am I missing?

There’s an engineering story of being abused by capitalists, but from an Executive perspective the whole thing strikes me as insane except for ‘next quarters bonus’.

Anyone remember what SCO did to the industry as it went under?

The part I still don’t get is where Enterprises are dumping internal ‘secrets’ (code, processes, customer needs, internal politics, leadership dreams), into the hands of startups and untrustworthy conglomerates. MS used to be famous for NDA and deal abuse.

I don’t believe for a second the LLM giants would be shy about training on corporate materials and lying about it. And if they start going under? This gold rush might have a long, ugly, tail.

This is a really bad take, many on hackernews have a very skewed idea of what a CEO thinks about its employees it seems, or why firings happen in the first place.

Quite honestly the firings that are happening are the ones who are not adopting the technologies, if you're doing this you're quite literally just putting yourself in scope.

Just read coinbase today. They are culling those who are not adopting the future because they get in the way of progress. They don't help, they don't push things forward and they hold back those who do.

It kinda racks my brain how a lot of people don't think this way. For example, way before the current state of AI, I wrote my own CLI to make aspects of my job easier and easier to write scripts to automate; some colleagues have noticed my tool and said I should share it, and my diplomatically worded answer is no. I don't share it with anyone because of the negative return in both supporting it and everyone else being able to be as productive as I am. Moreover, leadership will not recognize my ingenuity as an asset, hence no added job security. No way am I going to help my company out of the goodness of my heart to be potentially let go anyway in the near future.

If developers are worried about their jobs with the way the market currently is, they should treat their personal workflows as trade secrets. My example was not specific to AI, but it applies just as much to AI workflows. In a worker's market, it was sometimes fun to share that kind of knowledge with an organization. In an employer's market, they can pay me if they want access to my personal choices.

It sucks to treat the workplace as adversarial, but we unfortunately have to as long as companies have the zero-sum mindset of "wow, everyone is so productive and we're achieving so much, why do we have so many people again?"

And I'm not a "at work we're a family!" guy, but I wish we could just be excellent at our jobs and share it with each other without worrying if I'm digging my own grave.

>but I’m not going to selflessly share my productivity gains with the broader company for free.

If your employer is expecting that you selflessly share your time for free, you’re getting fucked. Most people are paid to do their job. They are, of course, then expected to work for their employers while on the clock.

These "secrets" that are being hidden are basically on the same level as gary tan's list of super uber powerful prompts.

None of it is actually that crazy that everyone else could think up.

What I've noticed in my own experience here is that even when I do share my own prompts/skills few people use them (or alternatively they were so basic that everyone already had their own version).

e.g. If someone doesn't care about xyz before AI, they probably won't after AI even if I serve them it on a silver platter.

Another angle I see is that AI tools start by benefiting the individual and the user captures the increased productivity (you could argue appearance thereof) in the form of slack time. Some tedium almost eliminated here, a problem handed off and crushed over there, and we've got an extra hour or four back in our day.

Does that person rationally go find more work to take on with that reclaimed time? Probably not unless it's their company or exceptional motivating circumstances exist.

[dead]

Eventually whoever is responsible to fix prod incidents and maintain has the ownership. And I agree that’s pretty messy in a world where agents are crossing those boundaries. Will the AI engineer with their horde of agents be responsible to keep everything running? I really doubt so, but we will see

If they create a system to compensate expert AI users wouldn't that career have a problem in that anyone (enticed by the new careers existence and) integrating their advice on any company particulars with a (weeks) more modern approach is basically putting them in the role of domain expert being eliminated.

Well, that's fine until your teammate does all of those things by default and gaps show up between them and the rest of the team.

LLMs can't fail, they can only be failed ... by you!

Even if LLMs write more buggy code they can still bring up software quality in the short to medium term by allowing you to clear out a lot of the backlog of bugs and UI issues that are known but never had enough priority to be fixed

Debugging and developing first fixes is also one of the spaces where current LLMs are the biggest force multipliers. Especially if you have reproduction cases the LLM can test on its own

But long-term it might look very different as more and more of the code becomes LLM written

Make sense to me. I can see how LLMs can help you make better systems. I don't have a christal ball but I can see how focusing on speed (or more precisely volume) can have a lot of unintended consequences.

That already happens here. I am old dev who was the goto guy for people with certain business and technical questions. Not anymore (which is part good, as I'm interrupted much less, and part bad, as sometimes they regard the wrong answer as truth).

I think you hit the nail on the head, it's probably right, most of the time. Or, maybe 89% right, 91% of the time.

The more I use AI, the more I see mistakes. I've noticed others see these same mistakes, correct them, then when queried say "Oh, it gets it right all of the time!". No, having to point out "you got this wrong, re-write that last bit" isn't "getting it right". And it's not that the code is wrong overtly, it's subtle. Not using a function correctly, not passing something through it should (and the default happens to just work -- during testing), and more. LLMs are great at subtle bugs.

So moving forward with this isolation you mention, ensures that maybe the guy in the company, the 'answer guy' about a thing, never actually appears. Maybe, he doesn't even get to know his own code well enough to be the answer guy.

And so when an LLM writes a weird routine, instead of being able to say "No, re-write that last bit", you'll have to shrug and say "the code looks fine, right?", because you, and the answer guy, if he exists, don't know the code well enough to see the subtle mistakes.

In a large codebase it‘s probably next to impossible to get people who fully understand the code to explain it to you with unerring accuracy.

AI can get a pretty good picture, near instantly, whenever you need it.

It’s not just competent-sounding, it is reasonably competent, and certainly very useful for tasks like that.

That's a valid point. Dev/team member isolation, not a great environment to build

Tokens _are_ as cheap as keystrokes. A single keypress by a full-time SWE averages out to $0.005-$0.02 (depending on typing speed and TC). The relationship is obscured because the keystrokes are usually part of a fixed-price subscription plan but they absolutely have a cost. Prior to AI this was in fact a large reason everyone pontificated about concise programming languages and elegantly factoring problems and DRY and...

>If you work on a terrible enterprise codebase... it's very possible that software quality/quantity isn't actually that important to your organization.

It's possible capitalism will drive all enterprise to terrible codebases.

>What about the filesystem developer who fell in love with his chatbot girlfriend

Fear not: he has a place to feel welcome and included!

https://www.newsweek.com/inside-world-first-ai-dating-cafe-1...

Indeed. Any developer who has used copilot knows you can't rely on it 100% The post's head image immediately bothered me. Copilot's strength is not on patching SDLC but to speed up the catching of typos and minor oversights. If you're using it as an integral part of SDLC, it causes problems immediately. So why posit the strawman? Marketing.