[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

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

[Daishiman]

> I've watched teams go from deploying weekly to deploying 5x/day after adopting AI coding tools. Their velocity metrics looked incredible. Their incident rate also tripled. Not because the code was worse per se, but because they were changing more things faster than their observability and testing could keep up with.

But this an improvement! The features/incident rate improves as you have more incidents but fewer in relation to the increased velocity. This may or may not be a valid tradeoff depending on the impact of incidents.

At least in my org we have an understanding that the product side will have to change drastically to accommodate the different rates of code development.