[palmotea]

> ...and [1] codebases for production code will be so low in quality that they will be unintelligible to humans, and [2] LLMs, too, will have trouble maintaining them. [3] At that point, coding will become a valuable skill again.

You are a very optimistic person. IMHO, claims #1 & #2 will happen, but #3 won't. People, especially business leaders, will just adjust their expectations downwards (or be forced to do so).

Just think of how often some "new and improved version" drops some important feature you used without providing a good replacement? We'll get more of that. If the codebase is unmaintainable, they'll just regenerate a new pile of garbage that will change stuff randomly and call it an improvement.

[weatherlite]

> Just think of how often some "new and improved version" drops some important feature you used without providing a good replacement? We'll get more of that. If the codebase is unmaintainable, they'll just regenerate a new pile of garbage that will change stuff randomly and call it an improvement.

Most production systems dont have such a high tolerance for embarrassing bugs. Startups can completely fail if they have too low quality. Established businesses can lose to competition if orders don't arrive, compliance has bugs etc etc. So quality has to be good enough, that's a constraint that wont go away.

[mewpmewp2]

Having worked at a company with thousands of microservices, I feel like most of it is just a bunch of boilerplate riddled with tons of ridiculous business logic, security and otherwise bugs. It seems like people were historically more concerned about Java inheritance and spreading everything around different files and directory hierarchies, while ignoring common sense business requirements completely. With each service being on separate older version, many being very difficult to start up locally, I don't see how LLMs could do worse than that, and that is a profitable, working business.

Funnily enough AI is the one discovering all those glaring issues now, and everyone is overwhelmed with getting it fixed. You could allow AI to attempt fixing it, but even though all of it was human written it is still hard to review, and even locally spin up or test because no one any more knows the true business requirements as people have rotated etc, so it's a nightmare.

The code on the first sight looks good, but what could be a simple config map, is spread out abstraction that is impossible to understand. Think just massive amounts of boilerplate to make a proxy call to another microservice etc.

[zingar]

The 1500 line react component that my unsupervised agentic coding side project produced says that it can get worse than we have now.

[mewpmewp2]

I swear I see far worse from humans for working businesses, and in much worse ways than just duplication of code. At least AI tends to be smarter about React intricacies even if it does create huge files. For my personal projects however I have straight token limits per file, whether it is backend or frontend so AI can't do that many lines of code. And I have specifically token limits so it would avoid hacking with formatting. And for React specifically I force it to put hooks in separate files and component files to be presentational only with max 1 hook usage.

[Izkata]

> At least AI tends to be smarter about React intricacies even if it does create huge files.

Oh no it's not. You just haven't seen where it goes when barely supervised by someone new to React. I've seen a level of spaghetti code with excessive useEffect and useMemo, reinventing two-way binding, I didn't even know was possible in React.

Spent months detangling weeks of AI-generated work earlier this year. Eventually got to the point we were actually fixing bugs by accident that previously neither they nor the tool could figure out.

[mewpmewp2]

I feel like I've seen people frequently doing the mistake of keeping way too many things in state that could and should be computed, but instead they would useEffect to read to dependencies change to update the state. And frequent useEffect infinite loops. I guess it depends heavily on how you would set up the initial prompts I suppose, but yeah if someone is new to React, maybe AI will do that you are right.

But also I see people constantly baking in more and more stuff into a single component and more and more useEffects and convoluted stuff, without no one ever daring or deciding to split up the file, because it doesn't seem like part of the ticket. And it never will.

At least to AI I can set guardrails and rules/logic to follow, to keep files small, but many people working on many random things one small ticket a time, where no one is there doing the refactor, things will also get crazy.

At least I feel I can use AI with guardrails to keep the codebase in a better shape than 100s of people working on the same monorepo.

[theshrike79]

24000 line central function in a mobile game that did 6 figure revenue monthly.

Made by an actual human, before OpenAI was a household name.

I'm 99% sure any SOTA LLM could've refactored that in a day to something actually manageable. It could've done it on a weekend.

[fn-mote]

The difference is, if you tell the LLM that the component is too big and ask it to use some strategies to break it up, it will.

Humans? Also maybe, but I always suspect the humans actually don’t know a better way. The LLM does, just that pathway wasn’t activated.

[palmotea]

> Funnily enough AI is the one discovering all those glaring issues now, and everyone is overwhelmed with getting it fixed. You could allow AI to attempt fixing it, but even though all of it was human written it is still hard to review, and even locally spin up or test because no one any more knows the true business requirements as people have rotated etc, so it's a nightmare.

No. It's just screwed up priorities. Those "glaring issues" were always a problem for the people maintaining those apps. It's just that no one gave a shit about those people or cared to make their job easier or them more successful (see the challenge or prioritizing tech debt remediation), but those same people are some reason willing to whatever it takes to make the machines successful.

There's a lot of contempt for humanity in the business world. It probably stems for a contempt for labor and a fetishization of capital.

[pydry]

We've been on this merry go round before with the "outsourcing to the cheapest programmers in india" boom.

That slopfest ended with a new executive dogma of "hire only the best programmers" as so many of those projects were humiliating disasters which had to be junked. I do not think that was coincidental.

Executive fashions can remain remarkably consistent and irrational for years as they try to make reality conform to their expectations before doing a complete 180.

[wtfHN26]

Funny you say that.

Outsourcing to India never ended. The Indian Service companies kept growing over last two decades.

Now many Western companies are setting up Global Capability Centers driving strategic innovation, IT, and R&D.

So the work going to India has moved up from "outsourcing to the cheapest programmers in india" to "we will hire the best talent in India directly and set up our company's base there".

To give some credit to your point, moving some low efficiency work to India since early 2000s freed up resources for many Tech companies to invest their best programmers into more profitable ventures.

But with the GCCs being set up in India, even a lot of the innovation and R&D work is now moving to India.

If that's any indication to your parallels with companies investing in AI. Something similar can happen with AI - where low end work moves to AI first, and the over time as the Technology develops more challenging and innovative tasks move to AI.

[citrin_ru]

Outsourcing never ended but it did happen in waves. Right after ZIRR ended but before the AI panic multiple companies started to layoff in developers in western countries and double down on outsourcing to India. During ZIRP they employed more people in the US/EU and less work was outsourced.