Hacker News Reader

Comment by silverlake | Hacker News Reader

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.

View on HN

“ 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?

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.

True, but I bet grandpa knows enough to identify when a paralegal has made a case losing mistake ;)

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.

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.

The second part of my response addresses why your response isn’t analogous to what we’re discussing.

> 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.

Of course the junior should be held accountable, along with the senior. Without accountability, what incentive do they have to not continue to fuck up?

Dropping the database is an extreme example because it's pretty easy to put in checks that should make that impossible. But plenty of times I've seen juniors introduce avoidable bugs simply because they did not bother to test their code -- that is where teaching accountability is a vital part of growth as an engineer.

> 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.

You are moving goalposts significantly here -- a small CSS hack is a far cry from your docker infrastructure.

I am going to put it out here: Docker and other modern infra is easier to understand than CSS (at least pre flex).

My take from this comment is that maybe you do not understand it as well as you think you do. Claiming that "other modern infrastructure" is easier to understand than CSS is wild to me. Infrastructure includes networking and several protocol, authentication and security in many ways, physical or virtual resources and their respective capabilities, etc etc etc. In what world is all of that more easy than understanding CSS?

When did I say I was blindly allowing an AI to set up my docker infrastructure? Obviously I wouldn't delegate that to a junior. My goalposts have always been in the same place - perhaps you're confusing them with someone else's goalposts.

How about a CEO delegating the work to an Engineer ? CEO does not understand all the technical detail but only knows what the outcome will look like.

I have been coding 10+ years, surely it is fine for me to vibecode then?

Only if you don’t mind what comes out :)

I mean I love it.

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.

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.

> I’m driving a tractor while you are pulling an ox cart.

Or you’re assembling prefab plywood homes while they’re building marble mansions. It’s easy to pick metaphors that fit your preferred narrative :)

>you’re assembling prefab plywood homes while they’re building marble mansions

Which one are there more of nowadays, hm?

Maybe the least interesting question to ask. Instead: Which ones are more lucrative to work on? Which ones are more fun to work on?

> 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?

But you would have learned something if you invested the time. Now when your infra blows up you have no idea what to fix and will go fishing into the LLM lake to find how to fix it

> 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"?

If it would have taken you days to learn about the topic well enough to write a bad implementation, how can you have any confidence you can evaluate, let alone "correct", one written by an LLM?

You just hope you are on a tractor.

https://kompose.io/

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

This is such an arrogant take.

Reply on news.ycombinator.com