Live data from Hacker News

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

news.ycombinator.com

61–70 of 244 posts

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

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

Three iterations later of trying to get Claude to make it compile (it changed random lines around the clear problematic line) I fixed it by following the example in the readme, and told Claude.

I then asked Claude to parse the rest of the toml file, whereby it blew away the compile fix I had made..

This isn’t an isolated experience - I hit these fundamental blocking issues with pretty much every attempt to use these tools that isn’t “implement a web page”, and even when it does that it’s not long before it gets tangled up in something or other…

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

#62

> boilerplate Ruby on Rails and its imitators blew away tons of boilerplate. Despite some hype at the time about a productivity revolution, it didn’t _really_ change that much. > , libraries, build-tools, Ensure what you mean by this; what bearing do our friends the magic robots have on these? > and refactoring Again, IntelliJ did not really cause a productivity revolution by making refactoring trivial about 20 years…

And for a lot of AI transformation tasks, for a long time I've been using even clever regex search/replace, and with a few minutes of small adjustment afterward I have a 100% deterministic (or 95% deterministic and 5% manually human reviewed and edited) process for transforming code. Although of course I haven't tried that cross-language, etc. And of course, we didn't see a massive layoff after the introduction of sa…

I just had a relevant experience. I asked Claude to add “trace(‘$FunctionName’) {}” to all Composable functions in my app. Claude spent some time doing something. In between, I was like shoot, I could just do a deterministic regex match and replace.

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

#63

> boilerplate Ruby on Rails and its imitators blew away tons of boilerplate. Despite some hype at the time about a productivity revolution, it didn’t _really_ change that much. > , libraries, build-tools, Ensure what you mean by this; what bearing do our friends the magic robots have on these? > and refactoring Again, IntelliJ did not really cause a productivity revolution by making refactoring trivial about 20 years…

couldn't have said it better. all of the people clamoring on about eliminating the boilerplate they've been writing + enabling refactoring have had their heads in the sand for the past two decades. so yeah, i'm sure it does seem revolutionary to them!

There have been a handful of leaps - copilot was able to look at open files and stub out a new service in my custom framework, including adding tests. It’s not a multiplier but it certainly helps

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

#64

I use it near daily and there is definitely a positive there, BUT its nothing like what the OP statement would make it up to be. If it is writing both the code and the tests then you're going to find that its tests are remarkable, they just work. At least until you deploy to a live state and start testing for yourself, then you'll notice that its mostly only testing the exact code that it wrote, its not confrontation…

This is the most insightful comment in the thread.

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

#65
post #63

Earlier quoted context omitted.

couldn't have said it better. all of the people clamoring on about eliminating the boilerplate they've been writing + enabling refactoring have had their heads in the sand for the past two decades. so yeah, i'm sure it does seem revolutionary to them!

There have been a handful of leaps - copilot was able to look at open files and stub out a new service in my custom framework, including adding tests. It’s not a multiplier but it certainly helps

most frameworks have CLIs / IDE plugins that do the same (plus models, database integration, etc.) deterministically. i've built many in house versions for internal frameworks over the years. if you were writing a ton of boilerplate prior to LLMs, that was on you

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

#66
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…

This is fascinating to me. I completely believe you and I will not bother you with all the common "but did you try to tell it this or that" responses, but this is such a different experience from mine. I did the exact same task with claude in the Julia language last week, and everything worked perfectly. I am now in the habit of adding "keep it simple, use only public interfaces, do not use internals, be elegant and extremely minimal in your changes" to all my requests or SKILL.md or AGENTS.md files (because of the occasional failure like the one you described). But generally speaking, such complete failures have been so very rare for me, that it is amazing to see that others have had such a completely different experience.

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

#67
post #17

In certain industries, increasing productivity by 90% does not mean 90% increase in profit. This is because growth depends on market TAM and growth rate. Another way of increasing profit is to simply reduce your headcount by 90% while keeping the same profit.* Hence, I think some companies will keep downsizing. Some companies will hire. It depends a lot. *Assuming 90% productivity increase.

In companies like the oil industry, doubling productivity would mean reducing the expected life span. Costs tend to catch up with profits, especially due to taxes. Layoffs happen inevitably. Is it the same with tech? Facebook has 3 billion monthly active users. No amount of tech will bring that up to 6 billion. If you were to double the amount of time someone spends on Facebook, or double the ads they see or double t…

That's assuming a company is constrained, to not expand its portfolio.

Taking the example of Facebook. They are in social media, messaging, AI, VR/AR hardware and software, a few other things, meta universe whatever that was, now left with the name. Facebook isn't delivering or successful on all its ventures, it knows that, it keeps investing in other segments.

More productivity would mean at least diversifying, they have some of the best engineers, it would make no sense to not simply attempt to hit the jackpot by playing more machines.

What fewer people talks about is that the entire tech industry is tertiary services. Ads, entertainment, communication, etc. If/when hard industries take a hit, tertiary takes a hit. If it isn't clear to you that the overall economy has already started to take some irreversible dents, and that those will accelerate, know that the capital is well aware.

Or we can continue wishful thinking and seek comfort that monetary tightening is just temporary, investments will flow more into tangent ventures and growth is around the corner, the U.S still is and will remain the world's strongest economy.

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

#68
post #63

Earlier quoted context omitted.

There have been a handful of leaps - copilot was able to look at open files and stub out a new service in my custom framework, including adding tests. It’s not a multiplier but it certainly helps

most frameworks have CLIs / IDE plugins that do the same (plus models, database integration, etc.) deterministically. i've built many in house versions for internal frameworks over the years. if you were writing a ton of boilerplate prior to LLMs, that was on you

Habe they? I’ve used tools that mostly do it, but they require manually writing templates for the frameworks. In internal apps my experience has been these get left behind as the service implementations change, and it ends up with “copy your favourite service that you know works”.

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

#69
post #21
post #9

Earlier quoted context omitted.

Because it's working for a lot of people. There are people getting value from these products right now. I'm getting value myself and I know several other folks at work who are getting value. I'm not sure what your circumstances are but even if it's not true for you, it's true for many other people.

It's interesting that the people IRL I encounter who "get the most value" tend to be the devs who couldnt distinguish well written code from slop in the first place. People online with identical views to them all assure me that theyre all highly skilled though. Meanwhile I've been experimenting using AI for shopping and all of them so far are horrendous. Cant handle basic queries without tripping over themselves.

If you are a 2600 chess player, a bot that plays 1800 chess is a horrendous chess player.

But you can understand why all the 1700 and below chess players say it is good and it is making them better using it for eval?

Don't worry, AI will replace you one day, you are just smarter than most of us so you don't see it yet.

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

#70

AI tooling does not provide productivity gains unless you consider it productive to skip the boilerplate portion of software development, which you can already do by using a framework, or you never plan to get past the MVP stage of a product, as refactoring the AI spaghetti would take several magnitudes more work than doing it with humans from the beginning. Amazon has demonstrated that it takes just as longer, or lo…

It's disappointing that this is clearly being downvoted due to disagreement - it's a valid perspective. We have very little evidence of the overall impact of aggressively generating code "in the wild" and plenty of bad examples. No one knows what this ends up looking like as it continues to meet reality but plenty are taking a large productivity improvement as a given.
Post reply on HN