logoalt Hacker News

bthornburyyesterday at 5:48 PM3 repliesview on HN

Why does there seem to be such a divide in opinions on AI in coding? Meanwhile those who "get it" have been improving their productivity for literally years now.


Replies

paulhebertyesterday at 6:39 PM

I think there are a number of elements:

- What you are working on. AI is better at solving already solved problems with lots of examples.

- How fast/skilled you were before. If you were slow before then you got a bigger speed up. If AI can solve problems you can’t you unlock new abilities

- How much quality is prioritized. You can write quality, bug free code with AI but it takes longer and you get less of a boost.

- How much time you spend coding. If a lot of your job is design/architecture/planning/research then speeding up code generation matters less

- How much you like coding. If you like coding then using AI is less fun. If you didn’t like coding then you get to skip a chore

- How much you care about deeply understanding systems

- How much you care about externalities: power usage, data theft, job loss, etc.

- How much boilerplate you were writing before

I’m sure that’s not a complete list but they are a few things I’ve seen as dividers

show 1 reply
rgloveryesterday at 10:03 PM

I've been using it every day for nearly two years now, with your suggested productivity boost observed.

The difference is that I'm not just letting agents willy nilly commit code. I treat them more like a companion and guide their steps (I use Cline w/ Sonnet/Opus 4.5/4.6). Not only do I save a ton of money on tokens, but the results end up being infinitely better than the "yolo" mode outcomes (even with excellent prompting/context).

From my POV, the only divide is between a willingness to be an accountable professional versus someone who just "lets the AI do it" and whistles-with-hands-in-pockets when that code inevitably blows up in a way you couldn't predict (because you weren't checking, only the AI was, which you swore was "good enough").

That approach works if you're just sitting on your couch hacking up toys to dice roll on X. But if you're trying to build reliable, deterministic systems that aren't constantly buzzing you awake at 3am, you're asking for a serious humbling if no one in your organization can explain how or why anything your business relies on works the way it does (that's operationally suicidal, imo, but hey—America).

That gets misinterpreted as being a "luddite," when really it's just having been down the rabbit hole enough times to know that if you can't point to and understand why it's happening (and ideally, whodunit), you don't know shit.

kaydubyesterday at 7:37 PM

There's a lot of reasons. There's a lot of breadth to "software engineering" (FAANG, web dev, embedded, OS, small business, etc.)

I'm sure there are some places where LLMs are bad due to lack of training data. There are some places where the LLMs are bad because the code base is terrible (and there's always "rockstars" at these jobs that severely overestimate their skills because they're always the one fixing the mess... which they also probably caused). Some devs/engineers feel threatened. Many devs/engineers think they're special and super smart so surely no machine can do their job.