Earlier quoted context omitted.
so where are these one man products lauched in a month? not talking about toys or vibecoded crap no one uses.
[flagged]
Ask HN: AI productivity gains – do you fire devs or build better products?
51–60 of 244 posts
Re: Ask HN: AI productivity gains – do you fire devs or build better products?
#52Re: Ask HN: AI productivity gains – do you fire devs or build better products?
#53Amazon has demonstrated that it takes just as longer, or longer, to have senior devs review LLM output than it would to just have the senior devs do the programming in the first place. But now your senior devs are wasted on reviewing instead of developing or engineering. Amazon, Microsoft, Google, Salesforce, and Palantir have all suffered multiple losses in the tens of millions (or more) due to AI output issues. Now that Microsoft has finally realized how bad LLMs really are at generating useful output, they've begun removing AI functionality from Windows.
Product quality matters more than time to market. Especially in tech, the first-to-market is almost never the company that dominates, so it's truly bizarre that VCs are always so focused on their investments trying to be first to market instead of best to market.
If Competitor Y just fired 90% of their developers, I would have a toast with my entire human team. And a few months later, we'd own the market with our superior product.
Re: Ask HN: AI productivity gains – do you fire devs or build better products?
#54> 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…
Re: Ask HN: AI productivity gains – do you fire devs or build better products?
#55> 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 of course, we didn't see a massive layoff after the introduction of say, StackOverflow, or DreamWeaver, or jQuery vs raw JS, Twitter Bootstrap, etc.
Re: Ask HN: AI productivity gains – do you fire devs or build better products?
#56In 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…
I think most companies are making the right call by downsizing instead of staying same size. Let people go to where there is more potential for growth.
Re: Ask HN: AI productivity gains – do you fire devs or build better products?
#57Situation a/ llm increase developer's productivity: you hire more developers as you cash profit. If you don't your competitor will.
b/ llm doesn't increase productivity, you keep cruising. You rejoice seeing some competitors lay off.
Reality shows dissonance with these only possible scenarios. Absurd decision making, a mistake? No mistake. Many tech companies are facing difficulties, they need to lose weight to remain profitable, and appease the shareholders demand for bigger margins.
How to do this without a backlash? Ai is replacing developers, Anthropic's CEO said engineers don't write code anymore, role obsolete in 6 months. It naturally makes sense we have to let some of them go. If the prophecy doesn't turn true, nobody ever get fired for buying IBM.
Re: Ask HN: AI productivity gains – do you fire devs or build better products?
#58For greenfield development you don't need as many software engineers. Some developers (the top 10%) are still needed to guide AI and make architectural decisions, but the remaining 90% will work on the lifecycle management task mentioned above.
The productivity gains can be used to produce more software, and if you are able to sell the software you produce should result in a revenue boost. But if you produce more than you can sell then some people will be laid off.
Re: Ask HN: AI productivity gains – do you fire devs or build better products?
#59Re: Ask HN: AI productivity gains – do you fire devs or build better products?
#60At my company, we are maintaining our hiring plan (I'm the decision maker). We have never been more excited at our permission to win against the incumbents in our market. At the same time, I've never been more concerned about other startups giving us a real run. I think we will see a bit of an arms race for the best talent as a result.
Productivity without clear vision, strategy and user feedback loops is meaningless. But those startups that are able to harness the productivity gains to deliver more complete and polished solutions that solve real problems for their users will be unstoppable.
We've always seen big gains by taking a team of say 8 and splitting it into 2 teams of 4. I think the major difference is that now we will probably split teams of 4 into 2 teams of 2 with clearer remits. I don't want them to necessarily delivery more features. But I do want them to deliver features with far fewer caveats at a higher quality and then iterate more on those.
Humans that consume the software will become the bottlenecks of change!