upvote
This makes sense in a way; why design for potential future growth in an environment of fast-paced technological and business development, bringing greater risk?

It seems the problem is the solution, and vice versa.

reply
Data correctness. You can purge and re-prompt your codebase any time. You can't your data.
reply
We had DRY for a long time. Now it's sloppy wet
reply
This is something I've been thinking about more and more. Since Opus 5.5 came out, I feel we've crested the hill and the answer for "who's going to maintain this slop going forward" is obvious - the LLMs will. Whether or not its slop, is extensible, maintainable, or forward looking almost doesn't matter anymore. Does it solve the problem today? If so ship it, and use the agents to solve the future problems. I am not quite sure this is a good idea, but assuming LLM progress doesn't stop means its probably the bet I would take.

I watch a YouTuber who is homesteading and builds everything. Often times I see him doing things in ways I know will break or fail eventually, but it doesn't matter because he is there and will fix it when it does. You could argue this is a waste of energy, and for a human it might be. For an LLM however I do not think it is.

reply
Why would it not be a waste of energy for an LLM? It must still be a waste, but perhaps the cost of the waste is so low that it’s much easier to justify
reply
Yes, the cost of fixing it when the actual problem arises is IMO lower than the cost of spending energy and human time up front to make it maintainable and extensible. I know it sounds crazy when I write it out like that, but this is something I've been thinking a lot about recently. Agentic coding is a paradigm shift and we have to rethink a lot about what use to make sense.
reply
I know it’s kind of a hot take and it might also be hazardous to my career if I’m right, but I kind of agree. If you create a code base that has some significant flaws, and a bug or change request arises later, it is definitely possible that “Super Fable” or GPT-7 Multiverse or whatever can, for $500 of tokens or whatever, perform a refactor of all the related modules, and create and thoroughly test all the necessary data migrations, as a prerequisite to fixing the bug.

I also think that if we’re being completely fair here, we have to acknowledge that most codebases that are more than a couple of years old are giant piles of tech debt already even with 100% human code. At least in all of my jobs, none of which were FAANG, nor run by extremely elite engineers. YMMV.

reply
This is just correct engineering practice.

"Oh no! We're making so much money off the massive number of customers we have that we need to redesign our system!"

Most companies never make it to that stage.

Get there to that point, don't fall victim to second system syndrome and spend 3 years on the rewrite, and you'll be fine.

reply
I (slightly joking) think this is amenable to zero-one-many. The first time your user base grows tenfold, rewrite. The second time, you need to rewrite again to plan for arbitrary scaling!
reply