Live data from Hacker News

Ask HN: AI productivity gains – do you fire devs or build better products?

news.ycombinator.com

171–180 of 244 posts

Re: Ask HN: AI productivity gains – do you fire devs or build better products?

#171
> you start off checking every diff like a hawk, expecting it to break things, but honestly, soon you see it's not necessary most of the time.

I see it's necessary ALL the time. The AI generated code can be used as scaffolding, but it's newer get close to real production quality. The expierence from small startup with team of 5 developers. I do review and approve all PRs, and none ever able to pass AI code review from the first iteration.

Re: Ask HN: AI productivity gains – do you fire devs or build better products?

#172
post #102

> or the boilerplate, libraries, build-tools, and refactoring If your dev group is spending 90% of their time on these... well, you'd probably be right to fire someone. Not most of the developers but whoever put in place a system where so much time is spent on overhead/retrograde activities. Something that's getting lost in the new, low cost of generating code is that code is a burden, not an asset. There's an ongoin…

> Not most of the developers but whoever put in place a system where so much time is spent on overhead/retrograde activities.

Dude that's everybody in charge. You're young, you build a system, you mold it to shifting customer needs, you strike gold, you assume greater responsibility.

You hire lots of people. A few years go by. Why can't these people get shit done? When I was in their shoes, I was flying, I did what was needed.

Maybe we hired second rate talent. Maybe they're slacking. Maybe we should lay them off, or squeeze them harder, or pray AI will magically improve the outcome.

Come on, look in the mirror.

Re: Ask HN: AI productivity gains – do you fire devs or build better products?

#173
post #61

> try it, you might actually be amazed. I keep being told this and the tools keep falling at the first hurdle. This morning I asked Claude to use a library to load a toml file in .net and print a value. It immediately explained how it was an easy file format to parse and didn’t need a library. I undid, went back to plan mode and it picked a library, added it and claimed it was done. Except the code didn’t compile. Th…

Same here. While LLMs sometimes work surprisingly well, I also encounter edge cases where they fail surprisingly badly multiple times per day. My guess is that other people maybe just don't bother to check what the AI says which would cause them to not notify omission errors. Like when I was trying to find a physical store again with ChatGPT Pro 5.4 and asked it to prepare a list of candidates, but the shop just wasn…

>It's great to see the AI reflect on how it failed. But it's also kind of painful...

Keep in mind that the AI is not reflecting, and it has no idea it made a mistake. It's just generating statistically-likely text for "apology" * "ai did not find results".

Re: Ask HN: AI productivity gains – do you fire devs or build better products?

#174

Earlier quoted context omitted.

>Thats not my fault. I don't know that it's useful to assign blame here. It probably is to your benefit, if you are a coding professional, to understand why your results are so drastically different from what others are seeing. You started this thread saying "I keep getting told I'll be amazed at what it can do, but the tools keep failing at the first hurdle." I'm telling you that something is wrong, that is why you…

> I don’t know that it’s useful to assign blame here Oh - I’m blaming Claude not anyone else. I’ve tried again this evening and the same prompt (in the same directory on the same project) worked. > i don’t know if you’re using an ancient version of Claude code, I’m on a version from some time last week, and using opus 4.6 > This is why a lot of people are saying "you'll be amazed at what it can do", and it points to…

I assure you I would have noticed if the result of my Friday effort was something that didn't compile, rather than a service that seems to work just fine. I've reviewed about half the code so far and it seems quite reasonable.

For some reason I'm getting downvoted for trying to help, but regardless, if you can (and want to) post a transcript somewhere of some of these sessions that aren't working out, maybe some of us who are having more success can take a look and see what's up.

Re: Ask HN: AI productivity gains – do you fire devs or build better products?

#177
We went through this exact decision point 18 months ago. But we chose to keep the team. Redirected them. Our threat detection pipeline, which would've taken 8 months to build - surprisingly and luckily shipped in 11 weeks. That's not a productivity stat, that's a product moat.

The companies gutting engineering right now are going to realise too late that AI amplifies what you already have. If you fire the people with institutional knowledge and domain expertise, you're left with an AI that generates confident, well-formatted mediocrity. Agree or not?

Re: Ask HN: AI productivity gains – do you fire devs or build better products?

#178
post #84

Earlier quoted context omitted.

You say it doesn't fail but you also mention all these work around you know and try...sounds like it fails a lot but your tolerance is different.

Providing instruction and context doesn’t seem like a “workaround”.

Agents are LLMs that use tools in a loop

I didn't give my Agent any tools, it hallucinated code.

...well, yes. It's like evaluating a programmer's skill by having one-shot a program on paper with zero syntax errors.

Re: Ask HN: AI productivity gains – do you fire devs or build better products?

#179

We went through this exact decision point 18 months ago. But we chose to keep the team. Redirected them. Our threat detection pipeline, which would've taken 8 months to build - surprisingly and luckily shipped in 11 weeks. That's not a productivity stat, that's a product moat. The companies gutting engineering right now are going to realise too late that AI amplifies what you already have. If you fire the people with…

I've been trying to figure out a formula how to describe the gains AI use gives.

It's not a direct multiplier, because even non-programmers can get stuff done with it just from an idea.

And it's not exactly an exponent either, even though experienced programmers can get absolutely massive gains when they learn to worth with it.

"Replace tools, not jobs" is the best AI slogan I've found yet. Use the VC funded practically free massive language models to quickly write every single small utility, tool, connector and dashboard you've ever wanted.

You know, the ones you've always wanted to do, but could never justify the time spent on them compared to the utility. Specifically in corporate environments. Stuff that used to require a project manager, programmer and a QA person dedicated to some tiny app for a week or two can now be done in two days by a single person with zero coding experience and an idea to a degree where you can be evaluate whether it's worth continuing or not.

Re: Ask HN: AI productivity gains – do you fire devs or build better products?

#180

Solo here, no devs to fire. What's changed is the bar for "worth building" dropped massively. Stuff I'd have shelved as too small to justify the time, I just do now. The risk is that you end up with a lot of half-finished things if you're not disciplined about finishing.

People tend to forget that big businesses have been bootstrapped with worse stuff than some MVP vibe code website.

I have a vague memory of a hotel reservation "app" that was just putting lines in a Google Sheet where the founders grabbed the info, called the hotels themselves and reserved the room.

When they got too many requests to keep up, they slowly automated the bits they could one by one.

Post reply on HN