[doublerabbit]

The boring parts where you learn. "Oh, I did that, this is now not that and it does this! But it was so boring building a template parser" - You've learnt.

Boring is suppose to be boring for the sake of learning. If you're bored then you're not learning. Take a look back at your code in a weeks time and see if you still understand what's going on. Top level maybe, but the deep down cog of the engine of the application, doubt so. Not to preach but that's what I've discovered.

Unless you already have the knowledge, then fine. "here's my code make it better" but if it's the 14th time you've written the ring buffer, why are you not using one of the previous thirteen versions? Are you saying that the vibed code is more superior then your own coding?

[Refreeze5224]

> The boring parts where you learn.

Exactly this. Finding that annoying bug that took 15 browser tabs and digging deep into some library you're using, digging into where your code is not performant, looking for alternative algorithms or data structures to do something, this is where learning and experience happen. This is why you don't hire a new grad for a senior role, they have not had time to bang their heads on enough problems.

You get no sense of how or why when using AI to crank something out for you. Your boss doesn't care about either, he cares about shipping and profits, which is the true goal of AI. You are an increasingly unimportant cog in that process.

[abustamam]

I actually learn quite a bit from my AI vibe coding and debugging. The other day I had a configuration issue in my codebase that only happened in prod. I didn't understand it (my coworker coded it and he was busy with something else at the time). I asked AI to help and it told me why it was broken and how to fix it, and also fixed it for me.

Since the issue was due to the intersection of k8s and effect, I don't think reading a bunch of docs would have really helped.

Of course I'm sure there's plenty of people who don't care about understanding the bugs and just want to fix things fast. But understanding these bugs helps me prompt/skill the LLM to prevent them in the future.

[Refreeze5224]

> I asked AI to help and it told me why it was broken and how to fix it, and also fixed it for me.

This is just it, you didn't learn anything here. In 3 months, you will only remember that AI fixed some issue for you. You will have none of the knowledge and experience that struggling and thinking and googling and trying things out until it works provides. You may as well have asked some other person to fix it, and they would at least have learned something.

Also, anyone could be plugged into your job when it works this way. All they need is someone who can type into a prompt. Which is much easier to find than someone who actually knows the what and how and why of the code. But hey, you fixed the bug, it ships, boss makes money, the company wins. But you sure don't...

[abustamam]

> In 3 months, you will only remember that AI fixed some issue for you.

That's not exclusive to AI. I've solved plenty of bugs pre-AI that I would go down similar rabbit holes to fix again without AI. I've spent days hunting down bugs like this in the past while only remembering that I spent days on the bug, not anything meaningful. It's not something I enjoy repeating.

> Also, anyone could be plugged into your job when it works this way. All they need is someone who can type into a prompt.

Maybe. The reality is that my coworkers of varying experience levels do attempt to vibecode/debug and are never happy with the results. I don't know what they're prompting, but it just goes to show that it's just as easy as just "typing into a prompt."

> you fixed the bug, it ships, boss makes money

Yeah, that's how it's always been, no? Boss doesn't care how it got fixed as long as it got fixed, and added points if it got fixed quickly so I can work on other features. I may not win long-term if I do use AI, but I certainly don't win short-term if I don't use AI, because I can't afford to spend days to fix a bug that AI can fix in an hour.

[logicprog]

If learning about individual cogs is what's important, and once you've done that it's okay to move on and let AI do it, than you can build the specific thing you want to learn about in detail in isolation, as a learning project — like many programmers already do, and many CS courses already require — perhaps on your own, or perhaps following along with a substantial book on the matter; then once you've gained that understanding, you can move on to other things in projects that aren't focused on learning about that thing.

[logicprog]

> The boring parts where you learn.

It's okay not to memorize everything involved in a software project. Sometimes what you want to learn or experiment with is elsewhere, and so you use the AI to handle the parts you're less interested in learning at a deep and intimate level. That's okay. This mentality that you absolutely have to work through manually implementing everything, every time, even when it's not related to what you're actually interested in, wanted to do, or your end-goal, just because it "builds character" is understandable, and it can increase your generality, but it's not mandatory.

Additionally, if you're not doing vibe coding, but sort of pair-programming with the AI in something like Zed, where the code is collaboratively edited and it's very code-forward — so it doesn't incentivize you to stay away from the code and ignore it, the way agents like Claude Code do — you can still learn a ton about the deep technical processes of your codebase, and how to implement algorithms, because you can look at what the agent is doing and go:

"Oh, it's having to use a very confusing architecture here to get around this limitation of my architecture elsewhere; it isn't going to understand that later, let alone me. Guess that architectural decision was bad."

"Oh, shit, we used this over complicated architecture/violated local reasoning/referential transparency/modularity/deep-narrow modules/single-concern principles, and now we can't make changes effectively, and I'm confused. I shouldn't do that in the future."

"Hmm, this algorithm is too slow for this use-case, even though it's theoretically better, let's try another one."

"After profiling the program, it's too slow here, here, and here — it looks like we should've added caching here, avoided doing that work at all there, and used a better algorithm there."

"Having described this code and seeing it written out, I see it's overcomplicated/not DRY enough, and thus difficult to modify/read, let's simplify/factor out."

"Interesting, I thought the technologies I chose would be able to do XYZ, but actually it turns out they're not as good at that as I thought / have other drawbacks / didn't pan out long term, and it's causing the AI to write reams of code to compensate, which is coming back to bite me in the ass, I now understand the tradeoffs of these technologies better."

Or even just things like

"Oh! I didn't know this language/framework/library could do that! Although I may not remember the precise syntax, that's a useful thing I'll file away for later."

"Oh, so that's what that looks like / that's how you do it. Got it. I'll look that up and read more about it, and save the bookmark."

> Unless you already have the knowledge, then fine. "here's my code make it better" but if it's the 14th time you've written the ring buffer, why are you not using one of the previous thirteen versions? Are you saying that the vibed code is more superior then your own coding?

There are a lot of reasons one might not be able to, or want to, use existing dependencies.

[jen729w]

I think this is a terrible argument.

I assume you use JavaScript? TypeScript or Go perhaps?

Pfft, amateur. I only code in Assembly. Must be boring for you using such a high-level language. How do you learn anything? I bet you don't even know what the cog of the engine is doing.

[doublerabbit]

    variable assumption "wrong"

    switch $assumption {
        wrong { puts "your assumption is wrong" }
        default { puts "perl, erlang, Tcl" }
    }