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

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

> 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 ongoing maintenance and complexity cost. LLMs lower maintenance cost, but if you're generating 10x code you aren't getting ahead. Meanwhile, the cost of unmanaged complexity goes up exponentially. LLMs or no, you hit a wall if you don't manage it well.

I think most public companies will take the short term profits and startups will be given a huge opportunity to take market share as a result.

At 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!

> 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 ago. Also, refactoring is kind of a solved problem, due to IntelliJ et al; what’s an LLM getting you there that decent deterministic tooling doesn’t?

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 confrontational or trying to find errors and it already assumes that its going to work. It won't ever come up with the majority of breaking cases that a developer will by itself, you will need to guide it. Also while fixing those the odds of introducing other breaking changes are decent, and after enough prompts you are going to lose coherency no matter what you do.

It definitely makes a lot of boilerplate code easier, but what you don't notice is that its just moving the difficult to find problems into hidden new areas. That fancy code that it wrote maybe doesn't take any building blocks, lower levels such as database optimization etc. into account. Even for a simple application a half-decent developer can create something that will run quite a bit faster. If you start bringing these problems to it then it might be able to optimize them, but the amount of time that's going to take is non-negligible.

It takes developers time to sit on code, learn it along with the problem space and how to tie them together effectively. If you take that away there is no learning, you're just the monkey copy-pasting the produced output from the black box and hoping that you get a result that works. Even worse is that every step you take doesn't bring you any closer to the solution, its pretty much random.

So what is it good for? It can both read, "understand", translate, write and explain things to a sufficient degree much faster than us humans. But if you are (at the moment) trusting it at anything past the method level for code then you're just shooting yourself in the foot, you're just not feeling the pain until later. In a day you can have it generate for example a whole website, backend, db etc. for your new business idea but that's not a "product", it might as well be a promotional video that you throw away once you've used it to impress the investors. For now that might still work, but people are already catching on and beginning to wise up.

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.

You still need humans to manage the whole lifecycle, including monitoring the live site, being on-call, handling incidents, triaging bugs, deploying fixes, supporting users and so on.

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

I'm a soloist. My plants are getting watered again and I get to finish work earlier and enjoy my home life now instead of sprouting ulcers or staying up til 4am. In the event I did/do have employees, I wouldn't hire anyone who could be replaced by an LLM (nor would I want to because I enjoy keeping my clients happy and having a team that actually feels like they have some sense of security in life—turns out those people are incredibly loyal and hard working).

false dichotomy. neither company will make it. the winner will be some solo dev with a singular vision and ruthless dedication to quality. “teams” do not have visions, individuals do. the more people are involved in a product, the blurrier the vision becomes, the more insidious the vested interest of the organization to profit from the user, rather than align themselves with the user. solo devs do not have such problems, because they’re no different from users, aside from the fact that they were users before the software existed. they make the software because they want to use it, and there is no amount of payroll employees that can replicate the quality and innovation that results from this simple, genuine self-interest.

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.

Public companies are incentivized to fire for short term gains while figuring out long term strategy on the basis that they'll have a cheaper pool to hire from once they figure out how they're going to more effectively monetize their ability to scale with AI.

Companies without the same constraints are well equipped to keep who they've got, pivot them into managing/overseeing agents to scale, and build better products from the outset.

So this'll be a good opportunity for smaller companies (or not-for-profits like co-ops and credit unions) to eat the lunches of bigger companies that'll be slow to adapt.

How much software do you need and how many computers are there to run it on?

After combine harvester, we produced the same food with less people.

At the moment, it seems like hardware is the constraint. Companies don't have access to enough machines or tokens to keep all their devs occupied, so they let some go. Maybe that changes, maybe we already have too much software?

Personally I think we already had too much software before LLMs and even without them many devs would have found themselves jobless as startups selling to startups selling to startups failed and we realized (again) that food, shelter, security, education etc are 'real' industries, but software isn't one if it's not actively helping one of those.

Developers are going to be more productive, just not how you think. If history is going to rhyme, then the software industry will enter into a self-serving productivity craze building all sorts of software tooling, frameworks, ralph wiggum loop variants, MCPs, etc. much like the surge in JS frameworks and variants in the past. Most of those things will not have any business value. Software devs, myself included, love to do things "because I can" and not necessarily because they should.

Smart organizations will not just deliver better products but likely start products that they were hesitant to start before because the cost of starting is a lot closer to zero. Smart engineering leadership will encourage developers into delivering value and not self-serving, endless iterations of tooling enhancements, etc.

If I was a CTO and my competitor Y fired 90% of their devs, I'd try to secure funding to hire their top talent and retain them. The vitriol alone could fuel some interesting creations and when competitor Y realizes things later, their top talent will have moved on.

I find that the arguments of whether or not AI boosts productivity is not very productive.

The more grounded reality is that AI coding can be a productivity multiplier in the right hands, and a significant hindrance in the wrong hands.

Somewhere there exists a happy medium between vibe coding without ever looking at the code, and hand-writing every single line.

Assuming you are primarily selling software.

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

The companies quietly doing the firing will say they're doing the building. The answer you get depends entirely on who you ask and what they're trying to justify.

False dichotomy. If your company is at the point of firing lots of people "to save a buck" its way past the point of caring about delivering a better product.

I have found it very useful in pointing me in the right direction, exploring codebases and writing up boiler plate or other scaffolding. However I do need to review and test, and at the end of the day it’s me who’s responsible for the code. So I only make it write parts of code at a time, not oneshotting a new Github company.

That's assuming every developer can get the same AI efficiency boost and contribute meaningfully to any feature, which is unfortunately not really the case.

Seniors can adjust, but eg. junior frontend-only devs might be doomed in both situations, as they might not be able to contribute enough to business-critical features to justify their costs and most frontend-related tasks will be taken over by the "10x" seniors.

I feel like the ideas have always been the tough part. Finding novel ideas with a good return is extremely tough.

If I were to run the company potentially mostly focus on better products with the exception of firing those that don't adopt the technology.

If it is a big company the answer is and will always be: whatever makes the stock price rise the most.

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

My own experience...

I've tried approaching vibe coding in at least 3 different ways. At first I wrote a system that had specs (markdown files) where there is a 1 to 1 mapping between each spec to a matching python module. I only ever edited the spec, treating the code itself as an opaque thing that I ignore (though defined the intrefaces for). It kind of worked, though I realized how distinct the difference between a spec that communicates intent and a spec that specifies detail really is.

From this, I felt that maybe I need to stay closer to the code, but just use the LLM as a bicycle of the mind. So I tried "write the code itself, and integrate an LLM into emacs so that you can have a discussion with the LLM about individual code, but you use it for criticism and guidance, not to actually generate code". It also worked (though I never wrote anything more then small snippets of Elisp with it). I learned more doing things this way, though I have the nagging suspicion that I was actually moving slower than I theoretically could have. I think this is another valid way.

I'm currently experimenting with a 100% vibe coded project (https://boltread.com). I mostly just drive it through interaction on the terminal, with "specs" that kind of just act as intent (not specifications). I find the temptation to get out of the outside critic mode and into just looking at the code is quite strong. I have resisted it to date (I want to experiment with what it feels like to be a vibe coder who cannot program), to judge if I realistically need to be concerned about it. Just like LLM generated things in general, the project seems to get closer and closer to what I want, but it is like shaping mud, you can put detail into something, but it won't stay that way over time; its sharp detail will be reduced to smooth curves as you then switch to putting detail elsewhere. I am not 100% sure on how to deal with that issue.

My current thoughts is that we have failed to actually find a good way of switching from the "macro" (vibbed) to the "micro" (hand coded) view of LLM development. It's almost like we need modules (blast chambers?) for different parts of any software project. Where we can switch to doing things by hand (or at least with more intent) when necessary, and doing things by vibe when not. Striking the balance between those things that nets the greater output is quite challenging, and it may not even be that there is an optimal intersection, but simply that you are exchanging immediate change for future flexibility to the software?

Gotta fire everyone, or else "too many cooks" will mean that even those temporary productivity gains go up in smoke.

Remember sometimes the most productive thing to have is not money or people but time with your ideas.

>do you fire devs or build better products?

I think that it's more along the lines of "do you fire people" instead of just "do you fire devs". Fewer devs means less of a need for PMs, so they can be let go as well, and maybe with the rise of AI assisted design tools, you don't need as many UX people, so you let some of them go as well.

As for building better products, I feel like that's a completely different topic than using AI for productivity gains, but only because at the end of the day you need buy in from upper management in order to build the features/redo existing features/both that will make the product better. I should also mention I'm viewing this from the position of someone who works at an established company and not a startup, so it may differ.

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

AI just removes the boring stuff. It's like having developers spending their valuable time on typing and then comes a product that removes typing cost and dumb managers are like ha! we now need fewer developers! And the smart ones go, great we can shorten the feedback loop and use existing resources to make more improvements!

Third option:

Not hiring someone?

Why do people keep ralking about AI as it actually worked? I still don't see ANY proof that it doesn't generate a total unmaintainable unsecure mess, that since you didn't develop, you don't know how to fix. Like running a F1 Ferrari on a countryside road: useless and dangerous

"I just got my third coffee and I'm feeling really good about the quality of this code. I don't even bother to look at it. Keeps my tests simple to not test at all. You know, 'in theory'. Of course when the architecture gets genuinely tangled... Just keep your IDE open so the code knows where to go. Whoa, too much caffeine, super sleepy..."

Terafab is suddenly making so much sense!

yes you fire if you are a burned out company that only needs to maintain its product and slowly die...

you hire more if you are growth and have new ideas just never had the chance to implement them as they were not practical of feasible at that level of tech (non-assisted humans clicking code and taking sick leaves)

Productivity really means nothing across companies and the software industry. So we code faster, but honestly problem I see is companies ask us to code stupid or worthless things in many cases.

CTO is rewriting company platform (by himself with AI) and is convinced it's 100x productivity. But when you step back and look at the broader picture, he's rewriting what something like Rails, .NET, or Spring gave us 15-20 years ago? It's just in languages and code styles he is (only) familiar with. That's not 100x for the business, sorry...

You have your devs be engineering managers over the tools.

Why not both?

[dead]

[dead]

[dead]