zlacker

>>tablet+(OP)
One thing that really bothered me that the author glossed over (perhaps they don't care, given the tone of the article) is where they said:

> Does an intern cost $20/month? Because that’s what Cursor.ai costs.

> Part of being a senior developer is making less-able coders productive, be they fleshly or algebraic.

But do you know what another part of being a senior developer is? Not just making them more productive, but also guiding the junior developers into becoming better, independent, self-tasking, senior coders. And that feedback loop doesn't exist here.

We're robbing ourselves of good future developers, because we aren't even thinking about the fact that the junior devs are actively learning from the small tasks we give them.

Will AI completely replace devs before we all retire? Maybe. Maybe not.

But long before that, the future coders who aren't being hired and trained because a senior dev doesn't understand that the junior devs become senior devs (and that's an important pipeline) and would rather pay $20/month for an LLM, are going to become a major loss/ brain drain domestically.

>>ang_ci+ae1
How many senior developers understand the minute, intimate details of the frameworks, libraries, languages they use? How many understand the databases they use? TFA says, many (but not all) don't have to care as long as the product ships. That's exactly how code written by LLMs is meant to be tested and evaluated. And if you set up a good enough build/test environment, TFA argues that you can automate most of the schelp away.

>>ignora+En1
In my experience, senior engineers without the curiosity to occasionally dig deeper into their frameworks are significantly worse engineers. No framework, library, or language is perfect. A big part of your job is understanding how your code will execute. Sometimes that even requires, at a very high level, imagining how that code will compile down to assembly once you strip away all the abstractions.

Eventually you will get a memory leak even in a GCd language. Eventually there will be some incredibly obscure, unreported bug in a library. Eventually you will find an issue in unmaintained code you depend on. Eventually there will be performance problems caused by too many layers of abstraction.

You either need to know, roughly, how your dependencies work by occasionally digging into their code/reading the documentation. Or you need intuition to know how it probably works, but you usually build that intuition by actually writing/reading code.

>>deltab+uy1
The people who want to look under the hood even if they have no immediate reason to do so will always exist, and the people who don't care and just learn the bare minimum to produce app features that usually work will always exist. All LLMs do is decrease the skill requirement to be developer B, but they also make it easier to learn what you need to be developer A.

>>kfajds+GV1
I think we will end up with significantly more developer B and significantly less developer A. I can't see the future, I don't know how that would play out long term, maybe it will all even out. But I think in the medium term it will be a lot of headaches for someone like me who spends a significant amount of time reviewing code and steering architecture.

Also, I spend a lot of time mentoring, and I'd like to think A will grow to be more like B over time. But now it feels like it's wasted effort to try mentoring those skills if it won't be valued.

>>deltab+5n3
I definitely think that there will be a far higher % of B than A in the future, but I also think it's accurate to say that the ratio of A:B was much higher in the 70s than now, even though there's a lot more A in absolute terms today. That's just what happens when you lower the barrier to entry.

There's definitely a cohort of on average much lower quality CS graduates though, between COVID and universities not knowing how to deal with AI (I say this as part of that cohort).