← Back to context

Comment by aeon_ai

1 day ago

AI is a change management problem.

Using it well requires a competent team, working together with trust and transparency, to build processes that are designed to effectively balance human guidance/expertise with what LLM's are good at. Small teams are doing very big things with it.

Most organizations, especially large organizations, are so far away from a healthy culture that AI is amplifying the impact of that toxicity.

Executives who interpret "Story Points" as "how much time is that going to take" are asking why everything isn't half a point now. They're so far removed from the process of building maintainable and effective software that they're simply looking for AI to serve as a simple pass through to the bottom line.

The recent study showing that 95% of AI pilots failed to deliver ROI is a case study in the ineffectiveness of modern management to actually do their jobs.

Or maybe it's just not as good as it's been sold to be. I haven't seen any small teams doing very big things with it, which ones are you thinking of?

  • you are not wrong. the only 'sane' approaches ive seen with vibe coding is making a PoC to see if some concept works. then rewrite it entirely to make sure its sound.

    besides just weird or broken code, anything exposed to user input is usually severly lacking sanity checks etc.

    llms are not useless for coding. but imho letting llms do the coding will not yield production grade code.

    • Koko the gorilla understood language, but most others of her ilk simlpy make signs because a thing will happen.

      Move hand this way and a human will give a banana.

      LLMs have no understanding at all of the underlying language, they've just seen that a billion times a task looks like such and such, so have these tokens after them.

      11 replies →

    • POC approach seems to work for me lately. It still takes effort to convince manager that it makes sense to devote time to polishing it afterwards, but some of the initial reticence is mitigated.

      edit: Not a programmer. Just a guy who needs some stuff done for some of the things I need to work on.

  • A team of 9 people made Base44, a product for vibe-coding apps, and sold it for $80M within 6 months.

    https://techcrunch.com/2025/06/18/6-month-old-solo-owned-vib...

    • That's just an example of surfing on the incestuous hype, they created a vibe-coded tool that was bought by Wix to help vibe-code other stuff.

      Is there any example of successful companies created mostly/entirely by "vibe coding" that isn't itself a company in the AI hype? I haven't seen any, all examples so far are similar to yours.

      1 reply →

  • As always, two things can be true. Ignore both the hucksters and the people loudly denigrating everything LLM-related, and somewhere in between you find the reality.

    I'm in a tiny team of 3 writing b2b software in the energy space and claude code is a godsend for the fiddly-but-brain-dead parts of the job (config stuff, managing cloud infra, one-and-done scripts, little single page dashboards, etc).

    We've had much less success with the more complex things like maintaining various linear programming/neural net models we've written. It's really good at breaking stuff in subtle ways (like removing L2 regularisation from a VAE while visually it still looks like it's implemented). But personally I still think the juice is worth the squeeze, mainly I find it saves me mental energy I can use elsewhere.

  • I've seen small teams of a few people write non-trivial software services with AI that are useful enough to get users and potentially viable as a business.

    We'll see how well they scale.

I'm rather tired of this ai apologism bit where every downside is explained away as "it would've happened anyways". AI destroying people's brains and causing paychosis? They would've gone psychotic anyways! AI causing company culture problems? The company was toxic anyways!

Instruments are not inculpable as you think they are.

  • What's your point? We should be more careful with it? This is the "trial and error" part

> Using it well requires a competent team, working together with trust and transparency, to build processes that are designed to effectively balance human guidance/expertise with what LLM's are good at. Small teams are doing very big things with it.

This reads a bit like "you're holding it wrong". If you need your team and organization to already be in a perfect state before AI usage will stop doing damage, what is the point of it in the first place.

Especially if AI is promoted as a "magic bullet" that will likely especially be uses by teams that are already dysfunctional.

  • "change management problem". We can forget AI specifically for a second -- there are teams and organizations that can adapt to change and there are those that cannot. Some orgs have invested heavily in rigid structures and processes and it probably made a lot of sense that time, but these were never going to survive paradigm shifts.

< small teams are doing very big things?

Another claim for AI success, followed by, nothing specific

This so many times over, using/introducing AI in an already managerially dysfunctional organisation is like giving automatic weapons to a band of vikings - it will with utmost certitude result in a quickening of their demise.

A demise that in the case of a modern dysfunctional organisation would otherwise often be arriving a few years later as a results of complete and utter bureaucratic failure.

My experience is that all attempts to elevate technology to a "pivotal force" for the worse is always missing the underlying social and moral failure of the majority (or a small, but important, managerial minority) to act for the common good rather than egotistic self-interest.

  • Vikings acquiring automatic weapons would be a winning strategy, it would not hasten their demise.

    Vikings with drones would endanger commercial airspace.

    Vikings with nuclear weapons would be funny, from a distance.

> Executives who interpret "Story Points" as "how much time is that going to take"

aside, but I have yet to meet a single person (dev, qa, pm, exec) who doesn't do this.

  • so nobody understands why we use "story points" instead of time estimates? I feel like some people do appreciate that its not about the number of points but the quantitive difference between the items up for work.

    • In my experience the vast majority has completely abandoned the idea of story points or team velocity, they are just an (unnecessary) proxy value for time estimates. And god forbid you suggest something like planning poker to make the estimates somewhat accurate.

I saw that study, it was indeed about pilots. When do you ever expect a pilot to immediately start driving big revenue increases? The whole thing is a strawman