[credit_guy]

I think you should reconsider.

LLMs are here to stay. Banning them in your organization is like banning IDEs, because, you know, real programmers use plain text editors and print statements.

Yes, junior programmers will take a bit longer to learn. But assuming they will always rely on LLMs is a bit dismissive. I grew up in Eastern Europe, without internet, and basically without TV either. All I had was books, and I read lots of it. When I came to America, I saw that nobody around me had read anything close to how many books I had read, and I felt a bit smug. But I got over it: I realized that people's brains still mature even if their knowledge consumption comes in form of movies, or the internet, or in the more modern days, TikTok, or LLMs. Yes, maybe being able to read Umberto Eco novels will always be beyond the reach of the TikTok-generation, but then reading Cervantes or Cicero in the original was always beyond my reach. I'm still living a fulfilling life even without first-hand knowledge of the classics, it's entirely possible the LLM generation could become decent programmers without internalizing Kernighan and Ritchie.

[fzwang]

I agree in part with what you're saying. I do think LLMs are here to stay and will be part of most programmer's toolkit. What my team and I are trying to figure out is where is it helpful, where does it break, and what are the long-term consequences. From an accountability perspective, we do allow senior folks to pick the tools they use, including LLMs. But they also need to be responsible for the outcomes. The consensus so far is that the fuzziness of understanding that LLM tools introduce causes harm in the long-run, in ways that are hard to trace back. It's like radiation and cancer. So if someone is using it, they better have a good rationale.

Your analogy with book reading is very interesting, although I interpret it differently. It seems like you enjoyed reading longform books, but the environment you moved to (US) is not reading-heavy (much more visual, like TV/phones). The skills you developed was not as valued in this new environment. The issue is the skillset-environment mismatch. If you had moved to a reading-rich culture/community, you'd have appreciated your past reading experiences.

In software engineering, I think the skillset is more like longform writing, where you have to build the mental model of the story and also be able to dig down to individual words. The more experience you have building these models from scratch and learning from other good builders, the better off you will be. People can certainly get by and "coast" on just using outputs from LLMs, the same way that there will be many LLM storywriters. But I'm concerned it'll put a ceiling on what they can accomplish. They are not developing the skillset needed at a higher level. They're stuck in-distribution, and never venture out. They may not even know what "out" is.

I guess some programmers are OK with that. And some orgs may be perfectly fine with LLM-based engineering (ie. Think of how many dysfunctional engineering teams there are. is adding LLMs that much worse?). They are willing to risk the tradeoffs. But they may later discover that it's a shrinking pool with a lot of newcomers, and to advance their craft and profession, they may have to write some code from scratch and read Kernighan and Ritchie.

[archagon]

Not OP, but I view LLMs in the same broad category as Electron: a cost-cutting measure (based on genuinely cool technology) that leads directly to enshittification, unless very carefully cultivated. An expert may use them to accelerate their work; a novice will pump out unscrutinized PRs riddled with garbage code.

Makes perfect sense to me to keep juniors far away from that stuff.

[credit_guy]

> a novice will pump out unscrutinized PRs riddled with garbage code.

They will. But not forever. Presumably their PRs need to be approved by someone more senior, and they'll be told they've made some mistakes, and learn from that. Either they learn, or at some point, they'll lose their job. But that's how it goes with or without LLMs.

[fzwang]

We've experienced this scenario a few times, where someone used AI generated code which had significant bugs or mistakes.

- Telling them about the mistake is not as helpful as you think. It's the same as taking an exam, getting something wrong, and looking at the answer key immediately. You feel like you learned something, but it's not as strong, and you're more likely to make the same mistake in the future. Doing things by hand, although painful, is still a strong check on your understanding of the problem.

- It's very frustrating for the person reviewing the code. Reading someone else's code is not easy, esp when they can't articulate what they were aiming for, or there's a big discrepancy from what they think they wrote vs what's actually written. In many cases, the reviewer is thinking "Why did I even bother with this? I should've just vibe-coded this myself. At least I know what should've been done. This isn't even worth it for mentoring purposes, because they did't actually learn anything."

- Using threat/punishment based incentives create a lot of bad vibes and culture. People are less likely to talk about mistakes and spend more time thinking about how to hide their mistakes.

- Eventually, the consensus converges to the position that the best way to learn is to do things manually and it's better when junior folks didn't rely on these tools from the beginning. It's important to explain to them why or else it can seem hypocritical when more experienced people are allowed to use LLMs more freely.

[archagon]

Having worked in corporate, the very last thing I want to be doing is reviewing code that no one actually understands.

If a PR contributor uses AI, they need to be able to intelligently discuss and justify every line of code. Otherwise, I'm the one having to reason about all the havoc it's going to wreak.