7 ms·

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 mont

• embedding-shape 5mo ago
  > 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.
  • forinti 5mo ago
    More code means more support and more maintenance. If your team is already overloaded or if it's going to be reduced because of AI, things are going to get tough.
    • lxgr 5mo ago
      My bigger concern is actually that, if a company isn't careful, the bloat (complexity, amount of code, other artifacts etc.) will just balloon and largely cancel out any gains. Feedback is often only considered once something is already on fire (financially, functionally, or literally).
      • nkrisc 5mo ago
        That’s the game plan for the AI companies: once companies have massive codebases of critical AI generated code and a skeleton crew of prompt engineers they’re going to be locked in to the AI product to develop anything new. They’re not even selling shovels, they’re selling subscriptions for shovels.
        • lxgr 5mo ago
          I don't think there needs to be any intentional evil scheme for this dynamic to be worth considering and mitigating. For example, there's also no cabal behind memory prices dropping (ignoring the development of the past months, of course), which in turn enabled web and game developers to use more memory and make their software non-viable on older devices.
  • arkh 5mo ago
    With the factory allegory: code is stock. Stock costs and is a liability hence Lean manufacturing.
    • jen20 5mo ago
      Worse: it's typically work in progress.
  • dawnerd 5mo ago
    Exactly. Everyone keeps talking about how much velocity they have with AI but no ones talking about quality for bugs that come from it. Just how fast they can ship.
    • Ekaros 5mo ago
      Or building what is actually needed or makes sense. Most efficient investment is one you do not have to make...
  • darth_avocado 5mo ago
    From the article: > The whole thing dies if it turns into employee scoring All ICs know this and some management does, but I’m willing to put money that it will 100% become employee scoring.
• _pdp_ 5mo ago
  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.
  • razodactyl 5mo ago
    Seeing this too. Machines are great at pumping out content. Tl;dr's, quick references / QuickStarts / cheat sheets and FAQs are also some things they're great at generating.
    • yetihehe 5mo ago
      Like in that comic strip[0], where one side uses AI to inflate his bullet points to make it look better and have more content in the email, then other side uses AI to summarize it to bullet points. [0] https://marketoonist.com/2023/03/ai-written-ai-read.html https://marketoonist.com/2023/03/ai-written-ai-read.html
      • 2ndorderthought 5mo ago
        This happens a probably a billion times a day. I shudder to think of the cost of it. Especially after knowing how LLMs aren't great at summarizing nor are they flawless at expanding information
  • WorldMaker 5mo ago
    > I would argue that any sufficiently large system reaches a point where more code is in fact the opposite of what it needs. I have absolutely worked on code bases I would describe as "marbleized bricks" where the best thing I can do is carve out the statue they already contain. There's a great satisfaction in making PRs that mostly delete things, but the later result is a program that works faster, has fewer bugs/edge cases, is easier for the next person to debug. The LLMs certainly can add more layers of marble. Companies don't often know how much more they need an artist with sculpting tools more than a bricklayer.
• TrackerFF 5mo ago
  Which is why there's currently a gold rush of "Enterprise AI" startups which implement / offer agents to enterprise businesses.
• razodactyl 5mo ago
  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.
• mattmcknight 5mo ago
  "release train" ... "learn how to ship software faster" SAFe is poison.
  • zbentley 5mo ago
    What do release trains have to do with SAFe? I've worked in a few places that have the notion of a release train (roughly a mutex for "changes being shipped and a burn-in window afterwards" plus some optional batching of changes based on risk level or urgency). Only one of them even gave lip service to SAFe; others had different methodologies/levels of devops for releases/"Agile"-ness (whatever that means). Release trains seemed like a mechanical release implementation detail in all cases; not the product or requirement of a given SDLC or process brand.
    • mattmcknight 5mo ago
      > What do release trains have to do with SAFe? An Agile Release Train (ART) in SAFe is a long-lived, cross-functional "team of teams" (typically 50–150 people) that plans, commits, and delivers value together on a synchronized, fixed-schedule cadence.
• SlinkyOnStairs 5mo ago
  > 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.
  • thfuran 5mo ago
    >Sooner or later investors will see the "$2M spend" and demand "$4M net profit", and that's not going to materialize. I think this is probably going to happen at the same time that the providers start really jacking up token prices to extract all the value they can.
    • 5mo ago
• chrisss395 5mo ago
  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.
  • impjohn 5mo ago
    I'd say there's bottlenecks within the developer processes without even considering org processes. Code review, release, post release ceremonies. Feels like they absorb much of the gained productivity in the coding phase.
  • aryehof 5mo ago
    I think while developers are moving faster, they are moving more dangerously. Perhaps the rest of the organization holding them back is a good thing?
• kj4211cash 5mo ago
  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.
  • samothrace 5mo ago
    Sounds like your company has bad or missing business analysts and/or product owners. Someone's supposed to be working between the stakeholders and engineering to develop those requirements and commit resources for testing. These "important people" are re-inventing the wheel and will be mired just as bad or worse until they figure this out.
    • kj4211cash 5mo ago
      I agree with you in general. And have a good chuckle when the vibe coders get derailed by some roadblock that would've been obvious to a professional engineer. But it's a bit one-sided to say that we have bad or missing analysts and product. Even good product can't keep up with how fast AI allows you to go. At an established company, maybe you shouldn't go as fast as AI allows you to go, but try telling that to the "important people."
• dev360 5mo ago
  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.
• heymijo 5mo ago
  What's old is new again [0][1][2] The Theory of Constraints - AI Era [0] https://en.wikipedia.org/wiki/Theory_of_constraints https://en.wikipedia.org/wiki/Theory_of_constraints [1] https://www.goodreads.com/book/show/113934.The_Goal https://www.goodreads.com/book/show/113934.The_Goal [2] https://www.goodreads.com/en/book/show/17255186-the-phoenix-project https://www.goodreads.com/en/book/show/17255186-the-phoenix-...
  • pards 5mo ago
    Yep, it's 100% a theory of constraints issue. Any optimization not done at the bottleneck (post-development) only serves to worsen the bottleneck.
• reactordev 5mo ago
  Sounds like the typical ServiceNow paralysis. The “Mother May I” model.
• dgellow 5mo ago
  The Mythical Man Month should really be a mandatory reading for anyone working in software… and I don’t mean reading a Claude summary
  • Henchman21 5mo ago
    I asked who hadn’t read that in an engineering meeting recently. No one had heard of it. Now, I have been in tech for my entire life. That book was given to me in 1993 as I was just starting out in college. NO ONE in my meeting was familiar with the title or author. I felt a little more impending doom upon realizing that.
    • jorisw 5mo ago
      Does everyone need to have read it though, in order to understand its premise? Surely they were at least aware of the basic premise that adding people doesn’t necessarily speed up delivery?
      • zanderz 5mo ago
        An analogy I saw once: can 9 women make a baby in 1 month?
      • Henchman21 5mo ago
        In a meeting where "adding more people to speed up delivery" was exactly the topic and the reason I brought up the book, nah.
      • dgellow 5mo ago
        > Does everyone need to have read it though, in order to understand its premise? Yes, it isn't a long read. You can reduce the book into one sentence if you want but that's a very low resolution understanding of the discussion at hand. Why is adding people not speeding up? Assuming that's true, what can be done about it? Why people still believe that adding more people will actually be beneficial? Also, it's just generally a good read. Engaging with nuance is essential IMHO, in a world where AI is incentivizing us to summarize everything
• redsocksfan45 5mo ago
  [dead]
• Mashimo 5mo ago
  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 :))))
• wildrhythms 5mo ago
  But then how will all of the know-nothing management types get their fingers in the pie?
• kakacik 5mo ago
  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.
• butlike 5mo ago
  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.
  • pards 5mo ago
    It's an investment that is not generating returns. It's inventory sitting on the shelf requiring ongoing maintenance costs but generating no income.
  • impjohn 5mo ago
    Code gets stale really fast. Re-gathering context and re-aligning on old code is sometimes more painful than starting from scratch.
    • dawnerd 5mo ago
      Also more chance for scope creep.
  • ambicapter 5mo ago
    You spent money making it, and now it's not making any money. It's pure liability (in the accounting sense, not the legal liability sense).
    • butlike 5mo ago
      It's potentially making money if I don't have to lie to the board/shareholders about having new features and ideas "in the works." New features show growth, life, progress of the business. If those features are being worked on then the business isn't stagnating. The actuality becomes all upside: risk to the money-maker is averted, and shareholder's fears are allayed with "Loud announcement, quiet rollout"-style features.
• giancarlostoro 5mo ago
  > 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.
• thisisit 5mo ago
  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.
  • highfrequency 5mo ago
    What’s wrong with the finance team (vibe) coding a janky prototype for planning?
    • JohnMakin 5mo ago
      prototypes/mvp's often become the production version
      • sandeepkd 5mo ago
        This seems to be the default path which is encouraged/suggested lately, only happy path until you acquire customers
        • JohnMakin 5mo ago
          I think it’s fairly normal at least in my career - rush to ship something, lots of “we’ll polish this later,” two years go by, get called into vp/cto/whoever’s office when the debt comes calling like “what the fuck why is this like this???” and I have to say “that ‘later’ we decided is now I guess”
          • sandeepkd 5mo ago
• ge96 5mo ago
  > Code takes 6-12 months to make it from commit to production. That seems wild, niche/highly specialized field?
  • pards 5mo ago
    Nope. Banking.
  • zbentley 5mo ago
    Incredibly common outside of startups and low-risk small-to-medium sized webtech shops.
  • froh 5mo ago
    probably software of old where bugs are expensive, thus a thorough process was created, V model with consistency reviews; add manual hand overs and subsystem tests and you easily get months to production release. PayPal started greenfield so they baked the qualification and consistency checks into the process and had it automatic. banks ho ooops. Same for Tesla: they created a hand over free code to (testing) road flow. and they were capable of thinking like that because their roots are software. GP below confirms traditional finance.
  • kakwa_ 5mo ago
    Pretty standard in highly regulated fields like aerospace, finance/banking or industry. Sometimes for good reasons, like thorough validation need or operational constraints like spaced-out maintenance windows. Sometimes for bad reasons, like a complete absence of unit tests and very old and brittle code bases requiring a lot of manual QA and several iterations for a version to be in a releasable state.
• nazcan 5mo ago
  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.
  • soks86 5mo ago
    That's an interesting take I don't see anyone else bringing up. It would also, I would think, make it easier for the 30% fewer engineers to earn a better living in the long run and reduce human management effort. This makes the most sense to me. So far AI, being fallible, can only augment humans so you can have less humans to do the same work (or tasks where accuracy can be less than 100%, like lower level support calls/questions). Next comes the task of re-balancing the distribution of labor or teaching other departments to utilize AI. To me that rings the most true because where AI saves me the most time is in never having a bug that takes more than a few hours to pinpoint, even if I'm looking in the wrong place, because with enough clues the AI will look in the right place before I think of doing so. Like finding a needle in a haystack. It doesn't suddenly make me 100x more productive, but it saves a lot of time on some time consuming tasks.
    • nazcan 5mo ago
      The debugging improvements have been huge for me too. I was debugging some financial software, and while it took a few shots, just with access to my code and not to the database that showed the issue, it found a fairly complex problem.
    • selicos 5mo ago
      This was my thinking. It's a tool with many options like digital spreadsheets. It can still be used 'wrong' or poorly, but you better know how to use it on some level.
• ericmcer 5mo ago
  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.
  • QuercusMax 5mo ago
    A lot of Bullshit Jobs[1] are going to be replaced by AI - it's not clear whether these "brokers" who can be trained with a powerpoint presentation are actually doing anything useful for society or even for the economy. 1: https://en.wikipedia.org/wiki/Bullshit_Jobs https://en.wikipedia.org/wiki/Bullshit_Jobs
    • ericmcer 5mo ago
      Yeah but I mean... My dog gets excited and barks to let me know whenever someone is at the door. It might crush his spirit if he knew he is just a useless pet and his contribution is meaningless.
      • badc0ffee 5mo ago
        If nothing else, it signals to people approaching your door that there is a dog they may not want to have to deal with.
  • pards 5mo ago
    It's scary. Our society is not set up to deal with mass unemployment.
• agloe_dreams 5mo ago
  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.
• themafia 5mo ago
  > lock in ROI On code you cannot possibly copyright. Yea they're all on the verge of "Locking in."
• perarneng 5mo ago
  This will eventually bubble up and get exposed and then things will start to roll fast.
• nonameiguess 5mo ago
  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.
• __loam 5mo ago
  Every line of code is a liability
• atoav 5mo ago
  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.