Hacker News
points by agd 15 hours ago | 0 comments
I’ve seen the opposite. The best devs are aggressively embracing agents - producing more, and at higher quality.
[–] jansport123 7 hours ago
really depends on what you work on and risk profile of such projects and your level. I'm sure if i worked at a startup just responsible for shipping features as fast as possible, i'd be going all in. At my work, finding good ideas is hard and LLM's help in that regard but you can't move as fast as if you knew what to do. In a small company, there is just an endless amount to do.
[–] x3haloed 14 hours ago
This is why, to me, it's more interesting to ask the question "how are good devs attaining outsized successes with AI" than "why are good developers wary of AI?"

Yes, there are real reasons to be careful, but that's already obvious to everyone in the field. The real gold is in discovering how successful devs are managing these risks while also retaining the benefits.

[–] gchamonlive 11 hours ago
Maybe good devs attain success with agents because they are wary of it, keeps them on their toes while maintaining a productivity boost.
[–] mrweasel 14 hours ago
From the article:

> they are not hesitant to use a coding assistant, they are hesitant to go all in and let the agents do all the execution.

They are embracing the use of coding agents, but they still want to be in control. That also matches what I see from my most talented colleagues. They outsource certain tasks to the AI and verify the output.

My somewhat unpopular opinion is that only very good developers are able to use AI coding tools somewhat safely. They could have written the code themselves, but it's faster to have the agent do and then verify. The rest of us couldn't write the code, at least not when we start on a project. When we finish, we have some of the skills and could rely more on the AI tools if we were to do it again.

[–] x3haloed 14 hours ago
I have a suspicion that eventually you won't have to be a developer to successfully create good software. I do think that familiarity with algorithm design will still help a lot. But ultimately, if your verification, testing, and observability regimes are good enough, the exact implementation shouldn't matter.
[–] roncesvalles 7 hours ago
What you're not considering is that software implementation is a 2-way street. The process of reading what you wrote both elucidates something more about the problem, and elicits from you some aspects about the program's behavior that you do care about but didn't consider before.

LLMs for many months have been at a level where if you know exactly what you want, you can simply let the LLM bang out an implementation and never have to read it. But outside of simple problems, you probably don't know what you exactly want.

That being said, I've had considerable success ending every prompt with "ask me for any further details that I haven't considered" or some variation thereof.

[–] 4b11b4 13 hours ago
I'd lean similarly, but those regimes you list aren't likely going to be done by accident.
[–] x3haloed 11 hours ago
Oh, you are 100% correct about that.
[–] jakevoytko 14 hours ago
This is also my experience in my own bubble. Even my friends who were skeptical for the longest started finding ways to perform cool cross-org work with them and accelerate their coding.

The biggest pocket of skilled holdouts I've noticed are in more artisan spaces where the craft of coding is part of the art. Things like old-school indie game developers where they're still sweating the assembly output and clock cycles.

[–] realo 15 hours ago
Yes sir! 100 times this.
[–] archagon 8 hours ago
I've seen devs who I once considered good veer heavily into architecture astronaut and/or "productivity hacking" territory with heavy agentic use, then invariably start posting like a hyperactive Linkedin marketing feed. I'm not sure what they're doing. I think they're building AI tools for other AI people to do AI things. It's certainly not reflected in consumer products in any way.

To be honest, I'm starting to get the feeling that heavy AI use gives you a form of brain damage. See also: https://www.fastcompany.com/91520702/y-combinator-garry-tan-...

[–] senordevnyc 6 hours ago
lol, the list of issues that guy found (ironically using AI) is so minuscule, this honestly sounds like a ringing endorsement for Tan’s approach. Claude Code found all those issues, and fifteen minutes of Opus 5.5 would have fixed them all. Put an automated review step on your PRs and you’re good.

To be honest, if this is what you consider to be a form of “brain damage”, I suspect you might be using reasoning here motivated more by your skepticism (fear? hatred?) of AI than by your colleagues truly going off the deep end.

[–] deadbabe 15 hours ago
The problems is the best devs aren’t the ones doing all the work. You have shitty devs too who are barely thinking or checking anything mixing slop code in with what whatever the best devs are doing, so it all eventually turns to shit.
[–] CharlieDigital 14 hours ago
The job of the best devs is to build the system ("the harness") that let's anyone build near their level of competency by unloading their heuristics into the harness. That is what the most senior, most talented devs on the team need to be doing so that the baseline gets lifted across the board.
[–] deadbabe 6 hours ago
that's a pointless endeavor. The seniors should just be building everything, not wasting time working on a harness that won't guarantee results anyway.
[–] walthamstow 14 hours ago
It won't be long before the best devs are working and the shit ones are not
[–] tonyedgecombe 14 hours ago
Assuming management has the ability to tell the difference and not just count lines of code or commits.
[–] linhns 8 hours ago
How to separate them if the code is already mixed?
[–] ShinyLeftPad 13 hours ago
and if this trend will continue the good ones increasingly aren't going to be working either. hopefully they realize they are getting themselves there by cooperating
[–] EricDeb 14 hours ago
this assumes it's easy to differentiate between the two groups.