[osigurdson]

I think we might as well just go all in at this point: "LGTM, LLM". The industry always overshoots and then self-corrects later. Therefore, maybe the right thing to do is help it get to a more sane equilibrium is to forget about the code altogether and focus on other ways to constrain it / ensure correctness and/or determine better ways to know when comprehension is needed vs optional.

What I don't like is the impossible middle ground where people are asked to 20X their output while taking full responsibility for 100% of the code at the same time. That is the kind of magical thinking that I am certain the market will eventually delete. You have to either give up on comprehension or accept a modest, 20% productivity boost at best.

[ivanjermakov]

There is a famous advice for balancing in game design by Sid Meier: "double it, or cut it in half" and I think it fits there.

https://www.benguttmann.com/blog/double-it-or-cut-it-in-half...

[ffsm8]

The productivity boost entirely depends on the way the software was written.

Brownfield legacy projects with god classes and millions of lines of code which need to behave coherently across multiple channels- without actually having anything linking them from the written code? That shit is not even gonna get a 20% boost, you'll almost always be quicker on your own - what you do get is a fatigue bonus, by which I mean you'll invest yourself less for the same amount of output, while getting slightly slower because nobody I've ever interacted with is able to keep such code bases in their mind sufficiently to branch out to multiple agents.

On projects that have been architected to be owned by an LLM? Modular modilith with hints linking all channels together etc? Yeah, you're gonna get a massive productivity boost and you also will be using your brain a shitton actually reasoning things out how you'll get the LLM to be able to actually work on the project beyond silly weekends toy project scope (100k-MM LOC)

But let's be real here, most employees are working with codebases like the former.

And I'm still learning how to do the second. While I've significantly improved since I've started one year ago, I wouldn't consider myself a master at it yet. I continue to try things out and frequently try things that I ultimately decide to revert or (best case) discard before merge to main simply because I ... Notice significant impediments modifying/adding features with a given architecture.

Seriously, this is currently bleeding Edge. Things have not even begun to settle yet.

We're way too early for the industry to normalize around llms yet

[CoffeeOnWrite]

While I too am only seeing a boost on the order of 20% so far, I think there are more creative applications of LLM beyond writing code, that can unlock multiples of net productivity in delivering product end to end. People are discovering these today and blogging about them, but the noise about dark factories and agents supervising agents supervising agents, etc, is drowning out their voices.

Every one of us is a pioneer if we choose to be. We have only scratched the surface as an industry.

[acedTrex]

Yes exactly, of all the uses cases for LLMs "writing code" is easily my least favorite. Theres so many other cool things for "stochastic contextual orchestrators"

[zeroonetwothree]

The problem with this is when something breaks and your manager says “why haven’t you figured it out yet” as you spend hours digging into the 200 PRs of vibe slop that landed in the past day.

Now you could say that expectation has to change but I don’t see how—the people paying you expect you to produce working software. And we’ve always been biased in favor of short term shipping over longer term maintainability.

[acedTrex]

yep, as is always the case, it has to break before you can fix it. Bandaiding something along just makes it more painful for longer.