My firm has two branches: a consulting group and a small development team. Since tools like Claude Code and Claude Design became available, consultants have started rapidly generating applications with AI. Clients are impressed, executives are excited, and our development team is left fixing bugs and trying to establish some kind of maintainable architecture.
I use AI too, but I make a point of understanding the code it produces and learning anything unfamiliar. That approach is enjoyable and produces better results, but it is obviously slower than generating an application almost entirely through prompts.
After a presentation showcasing nine new AI-enabled applications that the consulting team had produced quickly, I started wondering how other professional developers handle this situation. Are there practical ways to demonstrate the risks of trusting poorly understood, AI-generated code? I would especially like to show why software engineering practices such as version control, separate development and production environments, testing, code review, and long-term design matter.
I have already tried explaining the importance of basic development processes, but nothing has failed dramatically yet, so leadership does not seem concerned. Aside from waiting for a major incident, what strategies, safeguards, or demonstrations have worked for others?
4 Answers
Make the person or team who created the application responsible for its bugs and ongoing maintenance. AI does not change ownership. Also keep a written record of who built each system, what risks were raised, and which decisions were made. That paper trail helps prevent your development team from being blamed later for problems it warned about in advance.
Try to understand the generated code before continuing with another prompt. Otherwise, each new AI instruction can build on assumptions you never verified, leaving you debugging a system that nobody actually understands. If leadership still chooses speed over maintainability, let the decision-makers own that tradeoff and make sure your concerns are documented. Your team should not silently inherit unlimited free cleanup work.
A controlled failure demonstration may be more persuasive than a lecture. Take one of the generated apps and test malformed input, unusual permissions, concurrent requests, missing data, deployment rollback, and dependency failures. Show how quickly it breaks or produces incorrect results, then compare that with a properly tested version. The goal is not to sabotage anything, but to expose the cases that a happy-path demo hides.
Require testing and review as part of the delivery process, not as optional cleanup. Every callable unit should have meaningful tests, including edge cases, and the application should go through QA before anyone calls it complete. Code and tests should also be reviewed by at least two qualified developers who were not involved in writing them. If the consultants claim this slows them down, they can use their fast workflow to generate the tests too.
It also helps to define written engineering standards and enforce them with strict linting and automated checks. That gives the team objective gates instead of relying on arguments about whether the code looks acceptable.