[rkozik1989]

Has anyone else considered that producing code faster isn't necessarily a good thing? There's a lot that goes into getting a solution correct that has nothing to do with programming. Just because you can scale code production doesn't mean you can scale things like understanding user wants and expectations. At a point you're more work for your self/organization because unless you get everything perfect the first time you're creating more work than you're resolving.

[seanalltogether]

I just went through this exact thing this week. We've been working on a new feature, that if vibecoded as soon as the docs landed in our lap, would have resulted in a lot of duplicated functionality and an expanded data model. The more we worked through the solution with other engineers the more we realized the problem had been solved by another team and our solution could be small and elegant.

I can't claim that AI has no benefit to our organization, but I do think that as my career has matured, I find myself spending more time thinking about how code changes will effect the system as a whole, and less time doing the actual coding.

[ssgodderidge]

I agree that it isn't always a good thing. The assumption is that writing code, at some level, is one of the bottlenecks to delivery. If you "widen" the bottleneck by removing the time it takes to generate the code, your new throughput is going to create stress on other delivery areas: gathering feedback, testing, validation, approval processes, etc. I think the most effective results would come from a holistic approach to removing other bottlenecks in addition to reducing time required for producing code

[Ensorceled]

> Has anyone else considered that producing code faster isn't necessarily a good thing?

This has been an relentless goal of the industry for my entire 40 year career.

> At a point you're more work for your self/organization because unless you get everything perfect the first time you're creating more work than you're resolving.

Nothing is correct the first time (or rarely). Accelerating the loop of build, test, re-evaluate is a good thing.

[threethirtytwo]

I think you captured yet. Not many people agree but the real world metrics speak the truth, and that is trying and failing faster gets you further then methodological planning and structured approaches.

There IS experimental evidence on this and anyones anecdotal opinion is instantly blown to smithereens by the fact that this was tested and producing code faster is provably better.

[oytis]

Yes, but also a lot of work in software is solving solved problems. It would be nice if we could apply AI just to that, but all humanity's previous experience with digital technology tells me that we won't

[echelon]

No. It can't be anything but a good thing.

Code was always a limiting factor. It's why we built large companies.

Now we can do more with fewer engineers. This will enable small teams and small startups to be even more nimble.

[boesboes]

This must be why KLOCs are considered such a great indicator of productivity and why churn is used to measure code quality /s

I've worked in multiple start-ups and more mature companies, they always slow down because producing code is easier then building a product. More code is only better when quality hardly matters, which is basically never

[echelon]

OKRs are the indicator of productivity and these models let you crush more OKRs per human headcount.

[jolt42]

I'll try things I wouldn't otherwise try to get a better solution. I generate more throw-away code that actually gets thrown away, that's a win.

[poszlem]

But oftentimes you actually CAN understand user wants and expectation faster by deploying and iterating faster, though.