Hacker News new | ask | show | jobs
by 63 136 days ago
I have no problem with experienced senior devs using agents to write good code faster. What I have a problem with is inexperienced "vibecoders" who don't care to learn and instead use agents to write awful buggy code that will make the product harder to build on even for the agents. It used to be that lack of a basic understanding of the system was a barrier for people, but now it's not, so we're flooded with code written by imperfect models conducted by people who don't know good from bad.
3 comments

the number of experienced, senior programmers though, who are in “anti-LLM” camp, is still fairly staggering.
Why is that staggering? That feels like a pretty dramatic expression. Is it a foregone conclusion that one must use agents?
one does not have to use anything at all… but if someone is “senior” and is incapable of using llms for some parts of her/his job then senior part is just age related and not tied to skill level
You originally said being "anti-llm", but you now refer to being "incapable". Surely you can see that those are different things?
I mean when the tag line is "this will replace senior engineers and you, the senior engineer, must be forced to use it"

Then yeah, it makes sense.

Yeah I’m baffled why people are surprised that senior+ engineers who are being told in one breath they will be replaced by this tool and also they MUST use this tool to make it better to replace them aren’t happy about it or want to use it willingly.

I also find it wild how we’re sleepwalking into this, but I’m also part of the problem and using these things too.

If you're forced to use it by company mandate then that's fine. If you're not forced and still use it being fully aware, then I wish you well.
I’m forced to yes. It’s tracked.
as nvidia CEO wisely said - you won’t be replaced by these tools, you will be replaced by folk who excel at utilizing these tools
Where are you encountering all this slop code? At my work we use LLMs heavily and I don't see this issue. Maybe I'm just lucky that my colleagues all have Uni degrees in CS and at least a few years experience.
> Maybe I'm just lucky that my colleagues all have Uni degrees in CS and at least a few years experience.

That's why. I was using Claude the other day to greenfield a side project and it wanted to do some important logic on the frontend that would have allowed unauthenticated users to write into my database.

It was easy to spot for me, because I've been writing software for years, and it only took a single prompt to fix. But a vibe coder wouldn't have caught it and hackers would've pwned their webapp.

You can also ask Claude to review all the code for security issues and code smells, you'd be surprised what it finds. We all write insecure code in our first pass through if we're too focused on getting the proof of concept worked out, security isnt always the very 1st thing coded, maybe its the very next thing, maybe it comes 10 changes later.
> We all write insecure code in our first pass through

no, we don't

Yes we do, you don't just start a brand new web project and spit out CORS rules, authentication schemes, roles, etc in one sitting do you? Are you an AI?
> are you an AI?

no, I'm a competent engineer

maybe you've not worked with any

Yes I really do, because this has been a solved problem for a while. Also it’s necessary to get right because retro fitting it later is a pain.
I actually do build all of those things before standing something up in prod. Not doing that is insane. Literally every web framework has reasonable defaults baked in.

Any competent tech company will have canned ways to do all of those things that have already been reviewed and vetted

I don't. I pull in or bake in the security and ACL on day 1.

Features come after I have tested authn and authz.

The first feature runs with full security.

The issue isn't when the programmers start using it. It's when the project managers start using it and think that they're producing something similar to the programmers
We're in a transition phase, but this will shake out in the near future. In the non-professional space, poorly built vibecoded apps simply won't last, for any number of reasons. When it comes to professional devs, this is a problem that is solved by a combination of tooling, process, and management:

(1) Tooling to enable better evaluation of generated code and its adherence to conventions and norms (2) Process to impose requirements on the creation/exposure of PRDs/prompts/traces (3) Management to guide devs in the use of the above and to implement concrete rewards and consequences

Some organizations will be exposed as being deficient in some or all of these areas, and they will struggle. Better organizations will adapt.

The unfortunate reality is that (1) and (2) is what many, many engineers would like to do, but management is going EXACTLY in the opposite direction: go faster! Go faster! Why are you spending time on these things