One thing AI has changed for me as a software engineer is how much code I can produce in a day. Sometimes, a task that would have taken me hours is done in a fraction of that time.
I can give the model detailed instructions, explain the architecture, point it to the "SKILLS.md" files and tell it exactly how I expect things to work. The results can be impressive.
AI can generate hundreds of lines in one go. Reading every line carefully takes time, and the more code it generates, the more time I spend reviewing it. At some point, I wonder how much of the time saved during implementation I'm giving back during review.
I sometimes wonder if we'll reach a point where reviewing every line of AI-generated code becomes almost futile because the models will be so good at producing reliable code. We're not there yet, in my opinion, but the pace of improvement makes me wonder how far away that point really is.
That raises another question: where do we draw the line today? Is AI now good enough that we can trust more of its output when we've given it precise instructions and enough context? Or should we still read every line?
Testing makes this even more interesting. Should we write every test by hand? AI can generate tests too, but if the implementation and its tests share the same misunderstanding of the requirements, a passing test suite might give us false confidence.
The level of scrutiny probably depends on what the code touches. Authentication, payment flows and data integrity carry different risks from a small UI change. Tests, static analysis and type checking help, though they can't answer every question about whether the code does what we intended.
As a senior engineer, I still have to make those calls and stand behind what ships. AI has increased my output, but it has also changed how I need to think about reviewing that output.
How do you handle this in your own work? Do you read every line AI generates, focus on the parts that carry the most risk, or just ship and hope for the best?
Top comments (1)
I've landed on risk-tiered review too, with one change: for backend work I stopped reviewing the diff and started reviewing the boundary. I ask the same few questions every time. Did a new route appear? Does it check the caller before it touches data? Is input validated before the query? What does the error path return? They're quick to answer, and they're where the expensive mistakes hide. Line-by-line reading I keep for auth, payments and migrations, like you said.
On tests, your point about shared misunderstanding is the big one. What's worked for me is writing the test names myself, the behaviour I expect in plain words, and letting the model fill in the bodies. If the model writes both the spec and the code, it's grading its own homework.
For "does every route check auth", a deterministic check beats another model reading the diff, because it gives the same answer every run. I build one (https://wyro.in/scan?utm_source=devto&utm_medium=comment&utm_campaign=r100). Even a CI grep for route definitions that skip your auth middleware is a good start.