Complexity is always the thing that needs to be managed, as it is ultimately what kills your app. Over time, as apps get more complex, it's harder and harder to add new features while maintaining quality. In a greenfield project you can implement this feature in a day, but as the app becomes more complex it takes longer and longer. Eventually it takes a year to add that simple feature. At that point, your app is basically dead, in terms of new development, and is forever in sustaining mode, barring a massive rewrite that dramatically reduces the complexity by killing unnecessary features.

So I wish developers looked at apps with a complexity budget, which is basically Djikstra's line of code budget. You have a certain amount of complexity you can handle. Do you want to spend that complexity on adding these features or these other features? But there is a limit and a budget you are working with. Many times I have wished that product managers and engineering managers would adopt this view.

So the question is, are these AI tools primarily creating inherent complexity, or is it a significant amount of accidental complexity?

And if AI tools are writing all of the code, does it even matter anymore?

a bit of a nit but accidental complexity is still complexity, so even if that 1M lines could reduce to 2 kines its still way more complex to maintain and patch than a codebase thats properly minimized and say 10k lines. (even though this sounds unreasonable i dont doubt it happen..)

> The overall level of complexity of a project is not an "up means good" kind of measure.

I never said it was. To the contrary, it's more of an indication of how much more complex large refactorings might be, how complex it might be to add a new feature that will wind up touching a lot of parts, or how long a security audit might take.

The point is, it's important to measure things. Not as a "target", but simply so you can make more informed decisions.