{"by":"Bleiglanz","descendants":101,"id":47475859,"kids":[47479514,47480600,47479500,47480750,47480720,47477478,47477983,47479464,47480496,47480476,47475910,47479449,47477138,47480634,47479809,47479477,47477574,47476951,47476942,47479850,47476896,47477179,47476853,47480354,47477712,47479312,47479714,47476160,47475940,47476298,47477729,47477507,47477309,47478346,47478890,47476223,47476424],"score":69,"text":"i was rolling my eyes at the hype, but reading about this is totally different from experiencing it. if you have any old repos out there - try it, you might actually be amazed.

i'm not sure i buy the long-term "*90% productivity*" claims for complex, legacy enterprise systems, but for the boilerplate, libraries, build-tools, and refactoring? the gain is gigantic. all the time-consuming, nerve-wrecking stuff is mostly taken care of.

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. you just keep your IDE open and feed the "analyze code" output back into it. in java, telling it to "add checkstyle, run mvn verify and repair" works well enough that you can actually go grab a coffee instead of fighting linter warnings.

the theory is that what remains is just the logic and ideas. we'll see how that holds up when the architecture gets genuinely tangled. but for now, letting it branch off, create boilerplate, and write a simple test while you just iterate on the spec works shockingly well. you only write source code when it's too annoying to write down the spec in plain english.

it raises the real question: if your competitor Y just fired 90% of their developers to save a buck, would you blindly follow suit? or would you keep your team, use this massive leverage, and just *dwarf* Y with a vastly better product?","time":1774172250,"title":"Ask HN: AI productivity gains – do you fire devs or build better products?","type":"story"}