[debois]

I recognize this part:

> I don’t recall what happened next. I think I slipped into a malaise of models. 4-way split-paned worktrees, experiments with cloud agents, competing model runs and combative prompting.

You’re trying to have the LLM solve some problem that you don’t really know how to solve yourself, and then you devolve into semi-random prompting in the hope that it’ll succeed. This approach has two problems:

1. It’s not systematic. There’s no way to tell if you’re getting any closer to success. You’re just trying to get the magic to work.

2. When you eventually give up after however many hours, you haven’t succeeded, you haven’t got anything to build on, and you haven’t learned anything. Those hours were completely wasted.

Contrast this with you beginning to do the work yourself. You might give up, but you’d understand the source code base better, perhaps the relationship between Perl and Typescript, and perhaps you’d have some basics ported over that you could build on later.

[gyomu]

When I teach programming, some students, when stuck, will start flailing around - deleting random lines of code, changing call order, adding more functions, etc - and just hoping one of those things will “fix it” eventually.

This feels like the LLM-enabled version of this behavior (except that in the former case, students will quickly realize that what they’re doing is pointless and ask a peer or teacher for help; whereas maybe the LLM is a little too good at hijacking that and making its user feel like things are still on track).

The most important thing to teach is how to build an internal model of what is happening, identify which assumptions in your model are most likely to be faulty/improperly captured by the model, what experiments to carry out to test those assumptions…

In essence, what we call an “engineering mindset” and what good education should strive to teach.

[im_down_w_otp]

> When I teach programming, some students, when stuck, will start flailing around - deleting random lines of code, changing call order, adding more functions, etc - and just hoping one of those things will “fix it” eventually.

That sounds like a lot of people I’ve known, except they weren’t students. More like “senior engineers”.

[dodos]

I definitely fall into this trap sometimes. Oftentimes that simple order of ops swap will fix my issue, but when it doesn't, it's easy to get stuck in the "just one more change" mindset instead of taking a step back to re-assess.

[vbezhenar]

Can LLM ask to help? I didn't see that. They can ask to clarify something, but they'll never admit they need help.