If AI writes your tests, you can't debug the failures

The argument. Hussein Naser opens with a warning: the joy of programming comes from crafting instructions and debugging them, and AI-assisted development is quietly removing that feedback loop. His broader claim is that abstractions, not just AI, hide reality. He is not anti-tool. He is arguing that anything which hides complexity will eventually leak, and engineers who do not understand what is underneath cannot fix what breaks.

The production example. Naser, a senior principal product engineer at Esri, spends his days tuning queries across SAP HANA, Oracle, SQL Server and Postgres. He recounts a recent Amazon Aurora Postgres failure where identical data ran in milliseconds locally but maxed CPU in Aurora. The cause was stale statistics: data was copied but vacuum analyze never ran, so the planner chose full table scans. Running vacuum analyze fixed it. The lesson is operational, not exotic: database statistics and plan choices matter more than raw capacity.

The ORM trap. His critique of object relational mappers is the strongest practical signal. An ORM makes a constructor that fetches one item look simple, so a junior developer loops over 100 IDs and fires 100 queries when one IN clause would do. Then the abstraction leaks: selecting 150 fields, sorting 100,000 rows in the back end instead of in the database, and hiding the volume until CPU and memory say otherwise. He calls this the illusion of simplicity.

The AI boundary. Naser uses AI the way he used Google: to get the query for listing table locks in DB2 or to remind himself of reduce parameters. He refuses to use it for test cases, because if AI writes a test and it fails, he cannot debug code he did not write. This is a useful line for teams: use AI for disposable lookups, not for the artifacts you must own and maintain.

The leadership read. The interview is short on benchmark data and long on one practitioner's experience, so treat the strong claims as hypotheses, not proven policy. But the organizational implication is clear: code review and training budgets should focus on whether engineers understand the systems behind the tools. AI amplifies speed; it does not replace the need for fundamentals.

The trade-off. Readability always costs something. Naser is willing to write ugly SQL for performance, but a team cannot scale that preference without structure. The practical response is not to ban ORMs or AI, but to review for hidden volume, require knowledge of the underlying database, and keep humans responsible for tests. That is where the joy and the critical thinking actually live.