Comment by silverlake 6 months ago
You’re clinging to an old model of work. Today an LLM converted my docker compose infrastructure to Kubernetes, using operators and helm charts as needed. It did in 10 minutes what would take me several days to learn and cobble together a bad solution. I review every small update and correct it when needed. It is so much more productive. I’m driving a tractor while you are pulling an ox cart.
Senior engineers delegate to junior engineers, which have all the same downsides you described, all the time. This pattern seems to work fine for virtually every software company in existence.
> Another way to look at this is you’re outsourcing your understanding to something that ultimately doesn’t think.
You read this quote wrong. Senior devs outsource _work_ to junior engineers, not _understanding_. The way they became senior in the first place is by not outsourcing work so they could develop their understanding.
I read the quote just fine. I don't understand 100% of what my junior engineers do. I understand a good chunk, like 90-95% of it, but am I really going to spend 30 minutes trying to understand why that particular CSS hack only works with `rem` and not `px`? Of course not - if I did that for every line of code, I'd never get anything done.
Comparing apples to oranges in your response but I’ll address it anyway.
I see this take brought up quite a bit and it’s honestly just plain wrong.
For starters Junior engineers can be held accountable. What we see currently is people leaving gaping holes in software and then pointing at the LLM which is an unthinking tool. Not the same.
Juniors can and should be taught as that is what causes them to progress not only in SD but also gets them familiar with your code base. Unless your company is a CRUD printer you need that.
More closely to the issue at hand this is assuming the “senior” dev isn’t just using an LLM as well and doesn’t know enough to critique the output. I can tell you that juniors aren’t the ones making glaring mistakes in terms of security when I get a call.
So, no, not the same. The argument is that you need enough knowledge of the subject call bs to effectively use these tools.
> For starters Junior engineers can be held accountable. What we see currently is people leaving gaping holes in software and then pointing at the LLM which is an unthinking tool. Not the same.
This is no different than, say, the typical anecdote of a junior engineer dropping the database. Should the junior be held accountable? Of course not - it's the senior's fault for allowing that to happen at the first place. If the junior is held accountable, that would more be an indication of poor software engineering practices.
> More closely to the issue at hand this is assuming the “senior” dev isn’t just using an LLM as well and doesn’t know enough to critique the output.
This seems to miss the point of the analogy. A senior delegating to a junior is akin to me delegating to an LLM. Seniors have delegated to juniors long before LLMs were a twinkle in Karpathy's eye.
No one is an expert on all the things. I use libraries and tools to take care of things that are less important. I use my brain for things that are important. LLMs are another tool, more flexible and capable than any other. So yes, grandpa goes to Best Buy because he’s running his legal practice and doesn’t need to be an expert on computers.
I am pretty confident that my learnings have massively sped up working together with LLMs. I can build so much more and learn through what they are putting out. This goes to so many domains in my life now, it is like I have this super mentor. It is DIY house things, smart home things, hardware, things I never would have been confident to work with otherwise. I feel like I have been massively empowered and all of this is so exciting. Maybe I missed a mentor type of guidance when I was younger to be able to do all DYI stuff, but it is definitely sufficient now. Life feels amazing thanks to it honestly.
If there's something that you don't understand, ask the LLM to explain it to you. Drill into the parts that don't make sense to you. Ask for references. One of the big advantages of LLMs over, say, reading a tutorial on the web is that you can have this conversation.
> would take me several days to learn ... correct it when needed.
If you haven't learned how all this stuff works, how are you able to be confident in your corrections?
> I’m driving a tractor while you are pulling an ox cart.
Are you sure you haven't just duct taped a jet engine to your ox cart?
How did you verify this works correctly, and as intended, in 10 minutes if it would have taken you 2 days to do it yourself?
> It did in 10 minutes what would take me several days to learn
> I review every small update and correct it when needed
How can you review something that you don't know? How do you know this is the right/correct result beyond "it looks like it works"?
Here’s the real rebuttal to my overconfidence in LLMs. Thanks for the link!
I think this fits squarely with the idea that LLM today is a great learning tool; learning through practice has always been a proven way to learn but a difficult method to learn from fixed material like books.
LLM is a teacher that can help you learn by doing the work you want to be doing and not some fake exercise.
The more you learn though, the more you review the code produced by the LLM and the more you'll notice that you are still able to reason better than an LLM and after your familiarity with an area exceeds the capabilities of the LLM the interaction with the LLM will bring diminishing returns and possibly the cost of babysitting that eager junior developer assistant may become larger than the benefits.
But that's not a problem, for all areas you master there will be hundreds of other areas you haven't mastered yet or ever will and for those things the LLM we have already today are of immediate help.
All this without even having to enter the topic of how coding assistants will improve in the future.
TL;DR
Use a tool when it helps. Don't use it when it doesn't. It pays to learn to use a tool so you know when it helps and when it doesn't. Just like every other tool
“ It did in 10 minutes what would take me several days to learn and cobble together a bad solution.”
Another way to look at this is you’re outsourcing your understanding to something that ultimately doesn’t think.
This means 2 things: your solution could be severely suboptimal in multiple areas such as security and two because you didn’t bother understanding it yourself you’ll never be able to identify that.
You might think “that’s fine, the LLM can fix it”. The issue with that is when you don’t know enough to know something needs to be fixed.
So maybe instead of carts and oxen this is more akin to grandpa taking his computer to Best Buy to have them fix it for him?