Stop Reasoning Blindly

In a blog post titled 'Stop reasoning blindly,' the author argues that tackling complex problems with AI, such as RAG systems or AI agents, requires building benchmarks first to avoid reasoning blindly. The post emphasizes that without data, teams rely on convincing stories rather than results, and advocates for creating test and validation sets to evaluate components independently and measure improvements. The author concludes that defining evaluation methods is often harder than building the first solution but is essential to avoid going in circles.

Blog /blog Stop reasoning blindly. How I tackle complex problems with benchmark driven development. Stop reasoning blindly. Especially with AI. The harder the problem, the more dangerous it becomes. I see this in every difficult problem I tackle: complex RAG over domain-specific data, AI Agents doing nuclear engineering, or drone systems mixing mechanics, electronics, sensing, and control. Imagine that you start building a simple RAG system with your team. Sounds simple, right? Well, no. Which embedding model will you use? How will you chunk your documents? How will you parse your PDFs? Should you add reranking? A knowledge graph? Several agents? Or should you simply give the agent a filesystem? Every solution sounds plausible. Then one of your teammates gives you an example of a query that worked and a query that did not. What do you do with that? Probably nothing. You have no way to know whether this is a rare failure, a fundamental problem, or just a bad example. The same thing happens with AI architectures. Someone adds skills, specialized agents, memory, reflection, and sophisticated orchestration. They say it improves performance. On what grounds? They tried it. It felt better. Maybe the demo worked. Without data, they do not have a result. They have a convincing story. Had you built a benchmark from the beginning, you could have vibe-coded ten different solutions while keeping a clear way to check which one actually worked. You could evaluate every component independently, then measure its impact on the complete system. You could answer three simple questions: compared with what, on which cases and by how much, and is the improvement worth the added complexity? You would create a test set and a validation set, as you would in machine learning, and use them to optimize your code. Because yes, code is a bit like the weights of an AI model. It needs to be tuned, and it should not be tuned blindly. The benchmark also becomes the memory of the project. We always forget why we chose one solution over another. Sometimes it is fine to make a decision without enough evidence. But the decision, the assumptions behind it, and the lack of evidence must be recorded. Defining how to evaluate a hard problem can be difficult and time-consuming. It is often harder than building the first solution. But that is precisely the point. If you or your agent cannot accurately evaluate progress, you will fix one thing, break another, and go in circles forever. Reason as much as you want. But build the benchmark first.