I was asked to review a public portal largely built through AI-assisted "vibe coding" by someone without much web development experience. Even a surface review uncovered serious problems, so I created a detailed report and used AI tools to help analyze the code. I still verified the findings against the actual implementation and outputs.
The bigger issue is that the problems are architectural and process-related, not just isolated bugs. It's easy to tell an AI tool to "fix these findings" and get a reassuring response, but that doesn't mean the underlying issue was actually resolved. In this case, examples included exposed keys in client-side code, endpoints protected only by a plainly visible SAS key, weak authorization, and business logic that could allow actions such as duplicate submissions.
There also seems to be very little understanding of risk. Concerns are dismissed with arguments like "the data is public," without considering the broader attack surface or operational impact. I'm worried the organization will keep applying one-off fixes until the next failure instead of addressing the architecture and development process.
For those who have dealt with AI-generated software in production or operational environments, what problems have you encountered and how did you manage them? Have you created repository guidance, architecture documents, design templates, review checklists, or automated guardrails? I can see a possible path involving clearly defined architecture, automated security and quality checks, and human review for significant changes, but I'm interested in what has worked in practice.
The difficult part is balancing the claimed productivity benefits with the reality that AI-generated code still requires someone capable of understanding, testing, and challenging the output. Without that expertise, the tool can make poor decisions look polished and complete.
5 Answers
The underlying problem is usually weak architecture and immature delivery practices, not the AI itself. Establish approved design patterns, repository instructions, review requirements, and examples of acceptable implementations. Use lighter review for isolated UI changes, but require experienced human review for new user flows, security-sensitive behavior, and major refactors.
AI works much better when you use it for small, bounded pieces of work rather than asking it to create an entire application. Generate a function or module that is small enough to read, understand, test, and integrate into an existing architecture. It’s a tool, not a substitute for engineering judgment.
Write findings in terms of observable behavior and risk, not just code quality. “The code is poorly structured” is easy to ignore, while “this endpoint accepts unauthenticated requests” or “an order can be submitted twice” gives people something concrete to test and fix. It also makes the report more useful to non-developers.
I did provide concrete examples, including the authorization and duplicate-submission issues. Unfortunately, several were dismissed with “that’s okay,” and the rest were pasted back into the AI tool as a list of tasks. The tool then claimed they were fixed even when inspection showed the underlying problems remained.
The dangerous part is the fast feedback loop: someone asks for a fix, sees a confident response and a green-looking result, and assumes the architectural debt disappeared. Automated checks help, but they need to be backed by people who understand the system and are empowered to reject unsafe work. Otherwise the organization just accumulates plausible-looking patches.
Run the repository through secrets scanning, SAST, dependency checks, authorization tests, and similar automated controls. More importantly, turn non-negotiable requirements into checks that can fail a pull request. AI-generated code should not be trusted simply because it looks clean or the tool says the issue is resolved.
That approach makes sense for a small project, but this system serves millions of people. The hard question is what governance and guidance can constrain the tool without letting people treat “build the whole thing” as an acceptable shortcut. In this case, the honest answer may be that the tool shouldn’t be used for core production development at all.