What if the code sucks, because it was vibe coded by an LLM over a dozen disparate sessions?

If it performs the overall function but the code is a mess, then you can ask the model to describe parts of it, the structures and what the structures are for. When it shows you something that is messed up, suggest a better framing for the same thing and ask the model to implement the better framing without regressing on already passing tests.

I'm going through this right now on a very difficult to implement task, the original was python and very verbose. But had facilitated a rust implementation that produced byte identical outputs. Then I asked it for what data was being passed around, placing restrictions on what passed between interfaces I could tell it what parts should be immutable and what parts should have no presence outside it's local context. Placing those limitations while having a exemplar of what it should be doing gives it little choice but to make better code if it meets the conditions set while at the same time not regressing.

I say things like 'this field is a implementation detail in a declarative data structure, it should not exist here.

This can mean hours of work with no observable change in program function, yet it is directly addressing the limitations that prevents it from being used in larger tasks.

This sounds like coding manually would take less time.

I think you would be incorrect. While AI could not write what what I have so far on its own. Neither could I.

But coding manually would use fewer tokens.

Then that's the point. You know the code sucks, the guy who vibecoded it either didn't know or didn't care. That's the added value.

But how would you know? If you're an inexperienced developer you may well end up ingraining bad patterns without even realizing it.

Yes, how does the LLM make a difference there? Inexperienced developers write bad code. Hell, experienced developers who are outside their domain write bad code too, then you later realize that it's hard to read, or that it leads to architectural problems or such, and hopefully learn from the experience.

In the context of what I was replying to:

> This is a chicken and egg problem I find hard to resolve with LLMs. If we're pushed to delegate most work to them, how do you build that expertise?

Learning from LLM written code is significantly and meaningfully different from struggling on your own or learning from more experienced human co-contributors. Especially in a large, complex, iteratively developed codebase.

Worse, once you're in that situation you are now at the juxtaposition of: "I did this. I understand what my reasoning was, and now I know why it is wrong and how to fix it" vs. "An LLM did this, I don't know why it did this, I'm not sure what it was trying to do or what pattern it followed and I'm not sure how to make it better because I didn't write or understand the original implementation either"

Is it impossible to learn and gain experience this way? Not at all. But it's definitely not equivalent.

Claude, make this codebase less ass

That will actually work pretty well.

I legitimately caught Claude calling things "ass" while a friend was using it earlier, which I think is pretty funny.

Then fix it using the llm

Reading it is good, but working with it more directly seems to help retention.