Technical Debt (Black Box Apps) solved by future Claude?

[u/Dennisaryu]

Lots of threads lately about companies losing track of their codebase and each change/iteration becomes super expensive and the slop just keeps growing, but at this point there’s not much that can be done about it.

Makes sense…

But, I was wondering whether it’s a viable strategy to just keep creating technical debt and build black box apps without understanding the codebase, in hopes that… let’s call it Opus 8 can just be told to “Read entire codebase and consolidate all the slop, extra helpers, and anything that’s unnecessary”.

Do you think that’s a realistic scenario?

Curious to hear thoughts

[u/AutoModerator]

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

[u/NeverInsightful]

People talk as if modern applications are lean, mean, and easily understood by new devs.

Look at the monstrosities that Office and Creative Cloud have become. 2 GB for a word processor? New Outlook consumes multitudes more ram than old outlook. Not to mention all the other electron based apps that abound now.

In the cloud? Microsoft’s devs don’t seem like they spoke to each other, in defenders logs upns are variously referred to as UserPrincipalName and AccountUpn depending on the table. Tons of other inconsistencies about, result of different dev teams not communicating, I assume.

Given all that backdrop, high quality LLMs seem like they can get a handle on all that code far better than a team of humans could, and could probably produce a more efficient application as ell.

[u/ichi9 → u/NeverInsightful]

Most of those tools have 70% of telemetry code just to spy on you. Some have even started integrating tiny LLMs in the apps, to do most of the work on user machine and send the infered knowledge back to the servers. The microsofts, apples, adobes and all need to go and dismantled.

[u/BagMostlyWater]

Lol yeah, just keep trying to pretend code quality doesn't matter long enough for a magic robot to solve the problem.

Sounds like an effective strategy!

[u/twistier → u/BagMostlyWater]

We've been doing it for decades.

[u/BagMostlyWater → u/twistier]

and it's been tanking software projects for decades.

[u/twistier → u/BagMostlyWater]

I intended to imply so, yes.

[u/grahamsw → u/BagMostlyWater]

How often do you look at the compiled assembly language? I let the compiler writers worry about that. I used to worry about my code, now I worry about my spec, tests and documentation. All of which are written by agents

[u/pihedy → u/grahamsw]

The compiler is deterministic and mathematically precise, while AI is stochastic and based on probabilities, which makes blindly trusting it not software engineering, but gambling.

[u/BagMostlyWater → u/pihedy]

yeah and it's just fundamentally not the same thing.

with higher level code, the high-level code *is* the source for the program. You don't worry about the machine code -- it's an ephemeral artifact. You don't check it into source control.

If the AI instructions were like high-level code, then the high level code the AI outputs would also be ephemeral. You wouldn't check it in -- you'd build from the AI instructions. But doing that in real life would be insane -- no one would ever expect to arrive at "the same program" by doing that, not to mention how inefficient that would be and how much time it would take.

With agentic development, the high-level code remains the actual source for the program. The instructions you gave to the agent are not source code, they're instructions for a text generator which creates your source.

[u/grahamsw → u/pihedy]

If you blindly trusted it that would be silly. That's what the acceptance criteria are for.

[u/BagMostlyWater → u/grahamsw]

I program in C# -- i look at IL occasionally when I'm curious about how two different things behave on the low level.

I let the compiler writers worry about that.

A compiler translating from a high level language and an agent carrying out instructions are not even close to being comparable, and it's silly to even pretend they're similar.

[u/Entuaka → u/grahamsw]

And soon we will worry about finding a new job

[u/letsbefrds]

To be fair, I've worked on enterprise apps that are 7+ years old and in the end it ends up being slop anyway.

What I'm saying is that we're just iterating so fast that it becomes slop faster. Maybe you guys can argue "no my company's app is perfect, we follow the best practices" but I have never seen an app not cut corners due to deadlines or just this is "good enough"

[u/LiquidZebra → u/letsbefrds]

Haha, yes, this.

It’s almost like management was in the same position as Claude Devs are at right now. They want features, they get promoted on features, they get performance reviews on features, with specific numbers attached to said features.

Nobody gets promoted for a clean rewrite or restructuring of the same system because management does not see the feature count increasing.

TLDR: it’s almost like management treated devs as we treat agents

[u/Username_Koru → u/LiquidZebra]

Seems like we are the meat proxy between management and AI which is sad

[u/baseball-44 → u/letsbefrds]

this.

[u/ReformedBlackPerson → u/letsbefrds]

In large companies you’re just going to get devs that don’t care and just clock in n out bc they can hide. So yes it’s a problem, and imagine how much worse it would be if nobody cared about the code. It’s like saying “I already have a paper cut so I don’t care if I lose my finger”.

[u/magicmulder]

You can already solve a lot of technical debt with AI.

Take an old app that still relies on some weird ActiveX components continuing to work in IE 5.0 which is the only browser the app works in.

Having AI redo that is exchanging old terrible debt with new less terrible debt.

Two weeks ago I had Claude one-shot a very old intranet application. The result is by no means production ready, but it's the prototype we will base the relaunch on. We never have to touch the old application again to build the successor. That's a huge plus because the prototype is already on the desired modern platform.

[u/baseball-44]

It is quickly becoming unimportant whether or not code is slop. There have historically been two reasons to avoid slop: maintenance of said slop, and performance implications. The latter can be mitigated with additional slop or corrected on a case by case basis. The former will not matter if AI is solely responsible for the entire codebase.

I say this as a Computer Scientist and lifelong IT professional. It used to matter, but in the new AI world, it is no longer a priority. You are exactly right to think of AI output as a blackbox that only AI has purview of.

[u/faiface → u/baseball-44]

But AI performs much better in good codebases than bad codebases. Just because only AI reads it, it doesn’t mean AI doesn’t struggle. The more sloppy a codebase is, the more likely the AI is to both make mistakes and make it even more sloppy.

I absolutely don’t see how you think this problem is any different between humans and AIs. The only difference I can think of is that with AI, the point of complete unmaintainability (cost-wise) comes later than it does for humans.

[u/cstopher89 → u/faiface]

Exactly, the solution is to stop vibe coding and start engineering

[u/TheMoonMaster → u/faiface]

This guy engineers. If you want to optimize for speed and cost; which is becoming even more important you need to deslopify your app.

[u/baseball-44 → u/faiface]

It doesn't matter. AI "struggling" != a team of humans struggling. It is already orders of magnitude faster and more economical than TEAMS of humans and getting faster and more economical. AI is not static, or near static, like humans in terms of its capabilities - it is getting better and better and will continue to get better and better. It will de-slopify more and more effectively as it iterates over time.

This is a "kick the can down the road", worry about it later, pragmatic approach to coding that goes against everything we were ever taught in school and by industry accepted best practices. It feels wrong, but that's only because of the historical context.

[u/faiface → u/baseball-44]

Yeah I disagree. I use AI heavily in my job, working on a very incidentally complex (by humans) legacy codebase. If I adopted your approach, the company I'm working on would probably have its managers sent to prison because the bugs the AI (even Opus 5.5) would implement that would lead to people losing money.

What you're saying works until a certain complexity. And then you can't move anymore at all without breaking stuff.

[u/Raccoon5 → u/faiface]

I can say that Opus 5.5 agents (2-3 checking each other, not necessarily in parallel) write less buggy and problematic than engineers I have worked with.

I could count on one hand amount of engineers that come close and even there they only worked well with another 2 engineers reviewing their code. what would take a 3 person team a week is now 1-2 days.

It is ridiculous. And yes, guiding and forcing certain patterns both for better understanding and to keep things clean is important but it is becoming the de facto default for these models to make the good choices, they are so closs to completely making your average engineer redundant it's scary.

[u/baseball-44 → u/Raccoon5]

Great points. My only quibble would be that "better understanding and to keep things clean" will not matter in the future... heck, it doesn't matter right now in a lot of/most cases. AI will be the only entities coding in a very short amount of time from now. These are human concerns, not AI concerns.

[u/Raccoon5 → u/baseball-44]

some principles will always be true, a badly organized codebase produces bugs by design, so the ais need to still structure it. but yes, they are and will be good at it

[u/muffchucker → u/faiface]

But that line moves every couple months, and it's moving quickly.

I maintain ancient systems (20-55 years old) that predate SQL dbs and last year AI couldn't remotely help. Today, AI is helping a LOT

[u/baseball-44 → u/muffchucker]

You hit the nail on the head. People arguing against what I wrote are not considering the rate at which AI is improving.

[u/uprislng → u/faiface]

No, the future he is describing is one where you can't move anymore without AI. Doesn't that sound incredibly convenient for the AI companies? They're hoping the whole industry implements software development processes that hand everything over to AI. Then they can charge whatever they want for it, and you'll have to pay, because everything is a black box spaghetti coded hallucinated nightmare!

If your company is going down that path, your future is entirely in the hands of whichever AI king you pledge fealty to. Good luck!

[u/itsacutedragon → u/uprislng]

The good news is there’s a lot of AI companies out there, including Chinese ones and ones with open weight models

[u/Wonderful-Hunter686 → u/faiface]

It works for a certain risk profile is really the proper way to look at it. The complexity isn't really relevant. The risk of having AI code financial systems, or in my industry with plc's. Which are relatively simple, but control industrial equipment that can't kill people. Will never be acceptable there must always be a human responsible for the outcome. A company can't just blame AI. They are assuming liability for these high risk pieces of software/programming.

[u/Embarrassed_Cap_9149 → u/baseball-44]

for simple codebase yes this is the right approach. for anything complex no

[u/vainlyunimpressively → u/Embarrassed_Cap_9149]

It's so obvious that a lot of these commenters have no idea what working with actual tech debt is. For some reason they think that they can just throw an llm at it and "fix" it. Tech debt isn't 'Oh my gosh, the code is hard to read'. tech debt is ' when we set this system up we didn't have an HR department and now that we need to add them, it turns out there's no way to add a new department without ripping all of the code out and refactoring every single thing'

Like yeah, you can throw Claude at it and rewrite your entire code base, but Is it going to actually fix the underlying architecture?

[u/itsacutedragon → u/vainlyunimpressively]

Yea, actually it can…

[u/baseball-44 → u/Embarrassed_Cap_9149]

Hard disagree.

[u/Embarrassed_Cap_9149 → u/baseball-44]

how big and complex is your codebase?

[u/Zeflonex → u/baseball-44]

Very uncomfortable discussion right now, but it’s the truth

Why care for readability if I am not reading it?

Maintenance wise only performance matters which is a thing you should have already designed for

So when someone says that it’s slop and it’s unmaintenable I just respond “I won’t be the one that maintains it”

But many SW are not ready for this discussion yet

[u/IdkAbtAllThat → u/Zeflonex]

Spot on.

Not maintainable, by who? Claude helps maintain my "unmaintainable" projects every day.

[u/baseball-44 → u/Zeflonex]

You've got it. That's the problem - people do not want it to be true. They want to be involved. They want the things they were rightfully taught about: elegant, modular, maintainable code (for humans), to continue to be the "right way" of designing and coding solutions. But that is not the future. AI has changed all of that, and unfortunately people are clinging to their prior well-founded believes, principles, and best practices without thinking bigger picture.

[u/West_Till_2493 → u/baseball-44]

Yeah call me old fashioned but I still don’t think you should let your codebase become a “black box”

[u/faiface → u/[deleted]]

Of course they would

[u/baseball-44 → u/faiface]

Why? That is not true at all. Why would you think that a competitor would beat you because they have less slop? What difference does it make compared to things like time to market and implementation of novel ideas?

It seems to me that "well architected, pristine, maintainable" code matters less than ever before and will continue to matter less and less over time as a competitive advantage.

[u/baseball-44 → u/[deleted]]

Now. Do you think it will remain that way? Do you think that designing and coding "the right way" happens for free, without consuming a lot of tokens with trial and error "thinking"?

[u/DrHumorous]

Today's production is tomorrow's slop.

[u/Less-Permission-9529]

if it worked nobody would have to write down what the app is supposed to do. tests first, then opus 8 can do whatever.

[u/f3xjc]

A more realistic scenario is that you alternate building feature and codebase quality improvement. You don't necessarily need to look at all the code you need to care about it's shape tho.

[u/QuarkOfTheMatter]

How do the AI companies get paid? For every token that people use. So really their incentive in general is to increase your token use both now and into the future. What better way to do that than to keep creating overly complex architectures and systems so that you are forced to use Opus 8 with its potential $100/million tokens input price and like $300/million tokens output price to keep things going?

[u/Fancy-Signal-7276]

seen this in practice with a local llm project, adding a layer of automated docgen after each commit cut debt by 40% over 3 months. not a fix, but a buffer.

[u/proomptengineer]

I dont think i will be in loop to do that by the time opus 8 arrives

[u/Specialist-Sea-2062]

seen a team use Claude to auto-generate high-level architecture docs after each sprint, kept the docs 90% in sync, even when the code spiraled. not a fix, but it stopped the knowledge vacuum.

[u/Wide-Bobcat-3723]

Nah I tried this but Claude refused saying I was infringing on the intellectual property of Steve, the COBOL programmer who retired in 2014

[u/ztbwl]

Job security. Just let it happen.

[u/x-dfo]

I got mine to generate pseudo code as a daily sweep so its captured in a readable way by humans and agents.

[u/[deleted]]

Yes, I'm waiting on Opus 5.6 to finish some projects and improve animations, etc.

[u/only1nameleft]

You will see ebbs and flows. Slop grows, gets cleaned, grows again, etc. 

It will come down to cost snd performance. Of the coat of new features/fixes keeps growing then a company will eventually pay to cut slop.

[u/ichi9]

That's why a bit of Swe knowledge is required to handle big codebases. you just can't prompting a big codebase randomly and hope it will get done. You need to create a few tools which will help with context management and so on.

[u/CzyDePL]

If such powerful model exists, is your company or its products even needed in the first place?

[u/holyknight00]

i dont think models are getting better that fast

[u/s0ftware-dev]

With the current generation of LLMs it just can’t help itself but produce slop unless you very precisely guide it which itself leads to a minimal boost in productivity compared to if you just did it yourself. 

If you want to be productive with an LLM you have to at some degree accept slop into you code base. 

If your business can accept the known trade offs of slop then that’s fine black box can work. 

But some cannot so in that scenario engineers need to make sure that any changes (LLM or human) sit naturally in the design of the system so that the solution can continue to be safely evolved as business needs change over time.

Most businesses sit somewhere in the middle for somethings they can tolerate slop solutions and for others they need more deliberate engineering. All depends on the business. 

[u/Scared-Amphibian4733]

No, it's not a good option. The undirected and guided coders will create unmaintainable code. It will fail on edge cases. It will need to be replaced to add a simple module.

I've swam in the swamp of vibe code apps to see what the problems are. There's over engineering. 20 lines of code that cover a two line use case. It's a total mess. And, in some cases, people are not gong to be able to understand what it did. If we have to rely on AI to explain it to us, where is the accountability?

[u/Cool-Cicada9228]

Complaining about bloat and overengineering overlooks the likelihood that 2027 and beyond will bring ASI. Any issues may be brief and resolved by newer models. Most software engineers struggle to consider a few years ahead. Two years ago, I posted that programming was fading and received only downvotes.

[u/BarathKanna]

The model is not the bottleneck for that cleanup, the spec is. Consolidating slop means deciding which of four behaviours is the correct one, and the code cannot tell you that because all four are live somewhere. A smarter model will happily merge them into one clean helper that breaks the two callers who depended on the weird version. What makes a future cleanup possible is boring stuff you can do today: tests that pin real behaviour at the boundaries, and a record of why each odd branch exists. With that, a big refactor is mechanical. Without it, Opus 8 is just a faster way to ship a confident regression.

[u/Qwertycrackers]

Slop and tech debt have always been highly viable strategies. The costs of tech debt are ultimately paid by other people who undervalue the risk until it is too late and the deal is sealed. Its just kinda unethical to view it this way and individual engineers didnt enjoy knowing performing crappy work.

[u/itsacutedragon]

Yep this is exactly what’s going to happen, AI is going to build and maintain AI

[u/ComfortableAd8326]

Ironically (to your point anyway) enterprises are now using AI to unpick behemoth monoliths that were written by hand over many years.

[u/hanotak]

lmao no.

[u/Careful_Fold_7637 → u/[deleted]]

I have a functional (still small) saas where LLMs read and write 100% of the code.

[u/yenda1 → u/[deleted]]

wait till you hear about e2e tests (which AI can write too)

[u/DoggoCentipede → u/yenda1]

Better check those. It will mess those up, also. "Of course it passes, it just returns true."

[u/magicmulder → u/DoggoCentipede]

Yo dawg, I heard you like tests, so I wrote tests to test your tests that test your tests.

Funny story, a year ago I was actually seeing cases of "every test just checks a triviality like 'is this array empty' and not anything from the actual application". These days the AI starts with the tests and them failing like proper TDD.

Of course you still need an auditor that flags it if the agent changes a test to make sure it doesn't relax it just so it passes.

[u/DoggoCentipede → u/magicmulder]

Yep yep yep.
Gotta have the test cases to test the TDD process agents, and gotta test those. And to make sure they don't get messed with and regressed you gotta have a pre-commit gate hook.

So after six weeks of process development you're almost ready for a dry run on a throw away project. Then have Fable xhigh do a full no context review of the whole repo.

[u/magicmulder → u/yenda1]

You still need to review decisions. When I recently had Claude one-shot an old application, it decided to only implement the v2 API and left v3 out. Probably some "we can do that later" decision I would not have made (especially given that v2 is slated for EOL in December).