# The Dangerous Illusion of the 'Solo AI Developer' > Why handing a whole project to an AI agent leads to vulnerable software and how to work with one as a co-developer. - Author: Vibhek Soni (https://vibheksoni.com/) - Published: 2026-01-23 - Tags: ai security, devsecops, software engineering, opinion - URL: https://opendoors.wtf/blog/security-risks-of-fully-ai-written-apps/ ## The Trap of "It Just Works" Tools like Claude Code, Cursor and GitHub Copilot let us ship features faster than we ever could by hand. I use them every day. But I keep seeing a pattern in open-source projects and in enterprise codebases where the person writing the prompt stops being part of the process. It goes like this. You treat the AI as somebody you hired and can trust to get it right. You prompt. You copy the result. You deploy it. If it compiles it ships. That is how you end up with security holes you could drive a truck through. I found client-side authentication, unvalidated file paths and unrestricted shell access in several web UIs that were, by their authors' own description, fully AI generated. Locked doors with the key taped to them. ## AI Is a Junior Developer on Speed Imagine a junior developer who types a thousand words a minute and knows every library that exists. Now give them two more traits. They have no idea what a security problem looks like unless somebody tells them. They also never say they do not know something. They will hand you a confident answer that is wrong. Would you let that person push to production without anybody reading it? Of course not. That is exactly what a solo AI project does. The model is very good at solving the thing in front of it and it has no reason to think about what happens when somebody sends a request you did not plan for. A path parameter with `../../` in it is not part of the task you asked for so it never enters the picture. ## The Loop That Breeds Bugs The failure mode I see most is the context loop. You give the AI a bug. It gives you code. The code still fails. You paste the error back and get a fixed version. Five rounds in you have something that runs. You also have a pile of patches that each solved one symptom and the model has lost the shape of the system it started with. It is now fitting code to your error message rather than to the design. This is where the vulnerabilities get in. In the push to make the tests green a permission check gets dropped. Input validation disappears because it was getting in the way. A key gets hardcoded because the environment variable was annoying. Nobody notices because everybody is watching the failing test go green. ## How to Actually Use AI The fix is not using less AI. It is staying in the chair. You are the lead engineer and the AI is the person you are pairing with. [Image: A five step review loop between a person and an AI agent, with a rejected draft going back for another try] ### Don't Accept Code You Cannot Explain If the AI writes a block you do not understand then stop. Ask it to explain the block line by line. If you still cannot say why it is safe then assume it is not. That one rule catches most of the damage before it lands. ### Push Back on the Output Talk to it like a colleague who wrote something sloppy. - "You removed the CSRF token in this refactor. Why did that need to go?" - "This input handler looks vulnerable to XSS. Rewrite it with sanitization." - "You are using `dangerouslySetInnerHTML` here. Is there a safer way?" The last one is worth saying out loud because the model will repeat whichever pattern it used last. Naming the problem is often enough to get a better answer on the next pass. ### Read the Diff Do not just read the final file. Read what changed. Did it delete a permission check while it was cleaning something up? Did it drop a validation call because the happy path did not need it? Models work inside a context window and they quietly lose constraints you set two hours ago. A diff is the only place that shows you what left the building. ### Keep the Checks Outside the Chat A model can be talked into believing a test passes. Your CI cannot. Authentication and authorization checks belong in the code and in the pipeline where the agent has to satisfy them. Input validation belongs at the boundary where the data arrives rather than in a prompt you hope it remembers. ## Conclusion AI makes a strong engineer much faster and it makes a careless process fail faster. If your intent is to ship something now and see what happens then the model will help you do exactly that. If your intent is to ship something that holds up then it will help with that too. The intent is yours either way. You drive. The AI reads the map and argues with you about the exit and that argument is the useful part.