I Use AI to Build Software. I Still Don't Trust the Code.

I use AI to build software. I also don't trust it. That might sound strange considering most of my recent projects involve AI, LLMs, agents, RAG systems, and AI-assisted development. But after building several projects this way, I have learned something simple: Getting AI to generate code is easy. Knowing whether that code is actually good is the difficult part. One of the biggest changes for me has been how quickly I can move from an idea to a working prototype. I can describe a feature, give the AI some context, review what it produces, run it, find a problem, and continue the process. This is incredibly useful. It is also dangerous if you stop thinking. A few hundred lines of generated code can appear convincing even when you don't fully understand what is happening underneath. The application may run. The UI may look good. The API may return the expected response. And you can still have a bad system. That is the part that took me time to understand. When I started using AI-assisted development more seriously, it was tempting to use a simple rule: If it works, keep it. I don't think that rule is good enough anymore. Something working in one situation doesn't mean the implementation is correct. AI-generated code can contain: unnecessary dependencies duplicated logic incorrect assumptions weak error handling inconsistent patterns security problems unnecessary complexity code that works only for the example used in the prompt The problem is that these issues are not always visible from the interface. A nice-looking application can hide a messy backend. A successful API request can hide poor validation. A working AI response can hide a broken retrieval process. That is why I started treating generated code differently. Now I try to ask better questions. I want to know which files changed and why. AI doesn't actually know my intentions unless I provide enough context. If the requirements are incomplete, it will fill the gaps. Sometimes those guesses are reasonable. Sometimes they are completely wrong. The happy path is easy. Real applications have: invalid input missing data API failures timeouts authentication problems unexpected model responses database errors external service failures The system needs to handle those situations too. This has become one of my personal tests. If I cannot explain what an important piece of generated code is doing, I shouldn't blindly accept it. I don't need to memorize every line. But I should understand the important decisions. I don't think the useful question is: "Can AI code for me?" It obviously can. The more interesting question is: "What should I let AI do, and what should I still understand myself?" For me, AI is extremely useful for things like: exploring implementation approaches generating boilerplate explaining unfamiliar code creating initial versions of features refactoring writing tests finding possible bugs debugging with additional context generating documentation trying different approaches quickly But I don't want AI making important architectural decisions without understanding the consequences. The more important the decision, the more carefully I review it. Building an AI application adds another layer of uncertainty. A normal software bug can sometimes be reproduced consistently. AI systems can have problems at several different levels. For example: text User ↓ Application ↓ Agent / LLM ↓ Tools ↓ Database / APIs ↓ Retrieved information ↓ Final response Something can go wrong anywhere in that chain. The model might misunderstand the request. The retrieval system might return poor information. A tool might return unexpected data. The application might pass the wrong context. The final response might sound convincing even though the underlying information is incomplete. That means building AI systems requires more than just writing a good prompt. This is why my projects became more complicated When I look at the AI projects I have built, there is a noticeable pattern. I started with the obvious question: "How do I make the AI do this?" Then the questions became: "How does it get the information?" "What tools should it use?" "What should it remember?" "How do I know the answer is reliable?" "What happens when the tool fails?" "How do I control what the agent can do?" "How do I test the whole workflow?" That shift changed how I think about AI development. The model is only one part of the application. The surrounding system matters just as much. AI didn't remove the need to think This is probably the biggest lesson I have taken from AI-assisted development. AI reduces the amount of code I have to type. It does not remove the need to understand the problem. In some situations, it actually creates a new responsibility. When someone writes every line manually, they at least have a reason to encounter the implementation details. When AI generates those details, it becomes much easier to skip them. That can make development faster. It can also make mistakes easier to hide. My current rule I don't try to avoid AI. I use it heavily. But I try not to confuse generated code with understood code. For me, the workflow is becoming something like: Something can go wrong anywhere in that chain. The model might misunderstand the request. The retrieval system might return poor information. A tool might return unexpected data. The application might pass the wrong context. The final response might sound convincing even though the underlying information is incomplete. That means building AI systems requires more than just writing a good prompt. This is why my projects became more complicated When I look at the AI projects I have built, there is a noticeable pattern. I started with the obvious question: "How do I make the AI do this?" Then the questions became: "How does it get the information?" "What tools should it use?" "What should it remember?" "How do I know the answer is reliable?" "What happens when the tool fails?" "How do I control what the agent can do?" "How do I test the whole workflow?" That shift changed how I think about AI development. The model is only one part of the application. The surrounding system matters just as much. AI didn't remove the need to think This is probably the biggest lesson I have taken from AI-assisted development. AI reduces the amount of code I have to type. It does not remove the need to understand the problem. In some situations, it actually creates a new responsibility. When someone writes every line manually, they at least have a reason to encounter the implementation details. When AI generates those details, it becomes much easier to skip them. That can make development faster. It can also make mistakes easier to hide. My current rule I don't try to avoid AI. I use it heavily. But I try not to confuse generated code with understood code. For me, the workflow is becoming something like: The AI can help with almost every step. But I still need to be responsible for the result. The uncomfortable part AI makes it possible to build things much faster than before. That is genuinely useful. But it also makes it possible to build something you don't understand much faster than before. That distinction matters. I would rather have a smaller application that I understand than a huge application that I can only operate by repeatedly asking another AI what went wrong. I'm still learning this. I don't consider myself an expert who has figured out the perfect AI development workflow. I'm simply building, breaking things, fixing them, and trying to understand what actually works. And honestly, that is probably the most useful thing AI has changed for me. It has made experimentation cheaper. Now the important skill is knowing what is worth experimenting with, what needs to be verified, and what should never be trusted blindly. Final thought I don't think AI-assisted development is about choosing between: "Humans code" and "AI codes." The more useful model is: Humans decide. AI helps execute. Humans verify. At least, that's the approach I'm trying to follow. Because when something breaks in production, "the AI wrote it" probably isn't going to be a particularly useful explanation. About me I'm an AI-focused developer building applications around LLMs, RAG, agentic workflows, automation, and modern web technologies. I document what I learn while building these systems, including what works, what doesn't, and the problems that appear along the way. Portfolio: My Portfolio GitHub: My GitHub AI disclosure: This article was prepared with AI assistance for drafting and editing. The ideas, experiences, and technical perspective are based on my own development work, and I reviewed the content before publishing.