I'm completely fine with it. Currently I work with a set of principles that I try to uphold when working with agents (many of which are existing principles that tries to scale for the volume of code being written).
* Code is meant for reading, not writing. You will spend more time reading code so optimise for reading. I got this advice from a previous Principal Engineer and it has stuck with me ever since. Yes you can generate slop, but you have to be able to read it. Otherwise, for me, sloppy code becomes the context for the next feature, then the feature after that, until the codebase is really messy and brittle.
* The other principle I work with is that more code means more bugs and more recently security vulnerabilities. We're churning more and more code, and looking less at the code. Another agent can very easily find vulnerabilities in your website or app. Sometimes I feel that this is inevitable with the way folks are doing things
* Then my most recent principle. Always add value, know your customer, know your product, know your business metrics. I'm seeing more and more the statistic of "I merged X PRs in a day/week". Just like before AI, these things are very superficial. How many tokens did it cost? How many dollars did it cost? How much revenue did it earn? How many customers are adopting the feature? This applies to internal and customer facing features. The amount of vanity metrics that AI can create now is astounding, and people are still falling for it regularly.
* In a new project, I start with a few commits to see if the agent understands my desired architecture. Once that passes, everything else falls into place and slowly trust the code more and more. Sometimes when I need to add a complex feature, I would sit more with the design than the implementation, then I would skim the generated code to see if it's adjusting accordingly.
* Code is meant for reading, not writing. You will spend more time reading code so optimise for reading. I got this advice from a previous Principal Engineer and it has stuck with me ever since. Yes you can generate slop, but you have to be able to read it. Otherwise, for me, sloppy code becomes the context for the next feature, then the feature after that, until the codebase is really messy and brittle.
* The other principle I work with is that more code means more bugs and more recently security vulnerabilities. We're churning more and more code, and looking less at the code. Another agent can very easily find vulnerabilities in your website or app. Sometimes I feel that this is inevitable with the way folks are doing things
* Then my most recent principle. Always add value, know your customer, know your product, know your business metrics. I'm seeing more and more the statistic of "I merged X PRs in a day/week". Just like before AI, these things are very superficial. How many tokens did it cost? How many dollars did it cost? How much revenue did it earn? How many customers are adopting the feature? This applies to internal and customer facing features. The amount of vanity metrics that AI can create now is astounding, and people are still falling for it regularly.
* In a new project, I start with a few commits to see if the agent understands my desired architecture. Once that passes, everything else falls into place and slowly trust the code more and more. Sometimes when I need to add a complex feature, I would sit more with the design than the implementation, then I would skim the generated code to see if it's adjusting accordingly.