Oh, yeah.

I'm reconciling with the fact, that, if I let AI write a bunch of code, I have to depend on that AI to maintain it.

I just spent the last week, hunting down memory issues in the app I'm writing. I had a lot of help from an LLM. It rewrote most of the view controller that implements the map screen. That view controller is now 4,000 lines long (but half of that is comments), but it works extremely well. It took many context resets and rewrites to get here.

I would not have done it that way, but then, I probably also wouldn't have fixed the issue. The issue was really in Apple's MapKit, and I needed to do some gymnastics, to keep it from jetsaming my app. It's not particularly good code; but it works.

I've made the difficult choice to leave the sloppy view controller in the project, with the option of completely ripping it out, in the future, and replacing it with less "intense" code. It's pretty much "firewalled." It won't be that difficult to do it, assuming I have the bandwidth (and Apple finally fixes the memory hog issue, which seems to have been around for a long time).

There's all kinds of options that I could have (and still can) explore, but I feel that this is the best one.

But this article is absolutely correct. I think we will have a "slopocalypse," when it comes time to pay the piper for the thousands of vibe-coded applications that are certain to be authored in the next couple of years.

▲

magicalhippo 4 hours ago | parent [-]

So far my take has been that there is code that isn't very important, in the sense that if it works it works, it won't be modified or extended much if at all, and it's easy to verify that it works as expected. This type of code I'm happy with letting the AI go wild on.

Then there's important code, like business logic, security related stuff and such. For that I'll happily use AI to brainstorm ideas and avenues, do code reviews where I'm prepared for it to be wrong and help with library suggestions etc, but where I want to write the code myself so I understand what's going on.

We'll see how it changes, been a wild ride so far.

▲

skydhash 4 hours ago | parent [-]

I’ve never seen code that is unimportant. It’s either being used or not. If it’s boilerplate, it can be abstracted away. There are domains that are riskier than others (debug logging vs crypto for auth), but sometimes bugs in a somewhat safe place can lead to some catastrophic issues (you do not have to break a crypto algorithm if the key can be leaked via logging).

	▲	magicalhippo 16 minutes ago \| parent [-]
		As I said, I think it depends on what's being made. I've made a few internal web browser-based tools recently, and I let Codex and Claude handle the entire frontend. Don't really care about the details there. Tool is not exposed to the internet and they had limited scope. I handled the important details on the backend myself, and I reviewed the integration tests carefully. These tools would just simply not been made without Claude and Codex. YMMV as they say.