sixwhyo

sixwhyo is an open source code review tool that approaches your code the way a six year old might, by asking why about everything. It is designed to catch overengineering, unclear naming, and unnecessary complexity by forcing you to justify decisions you might otherwise take for granted. If a pattern or abstraction cannot survive a simple question about why it exists, that is a signal worth paying attention to. The name comes from the creator's own six year old child, Andy, whose relentless questioning about everyday things inspired the approach. Children do not accept complexity without explanation. Neither does this tool.

The problem sixwhyo addresses is one that plagues most codebases over time. Code tends to accrete complexity. Developers add abstraction layers because that is what good architecture looks like. They create helper functions because reuse is a virtue. They implement design patterns because the books say to. But often these additions do not serve the actual problem at hand. They were added out of habit, or because someone anticipated a requirement that never materialized, or because the developer was showing off rather than solving the problem simply. The result is code that is harder to read, harder to maintain, and harder to onboard new people into. sixwhyo exists to push back against that tendency by making you justify every piece of complexity to an entity that refuses to assume your decisions were correct.

The tool works in three modes, each targeting a different need. The main sixwhyo mode runs as an interactive code reviewer that walks through your code and asks questions about complexity and clarity. It will ask why a function needs to be three hundred lines. It will ask why you introduced a factory pattern when you only have one implementation. It will ask why a variable is named x instead of something descriptive. The questioning is relentless in the way children are relentless. A simplify mode called sixwhyo simplify takes a file and reviews it in one shot, then rewrites it to be simpler and exits. You get the simplified version without the back and forth. A summarize mode called sixwhyo summarize produces a one to two line plain language explanation of what a file does, then exits. This is useful when you need to quickly understand an unfamiliar file without reading through all the implementation details.

Under the hood, sixwhyo uses language model capabilities to analyze your code. But the framing matters more than the underlying technology. Rather than positioning itself as an expert telling you what to do, it plays the role of someone who genuinely does not understand why you made your code complicated. This reframing changes how you receive the feedback. When a static analyzer tells you a function is too long, you can argue with it. When something frames the observation as genuine confusion about why anyone would do what you did, you are forced to explain yourself. And in the process of explaining, you often realize the explanation does not hold up. The complexity was there because you copied it from another project, or because you thought you might need it someday, or because you did not stop to think about whether it was necessary.

The target user is a developer who suspects their codebase has grown more complex than it needs to be. Maybe you have inherited a project with layers of abstraction that no longer serve a purpose. Maybe you are reviewing your own work and want a fresh perspective that is not polite about pointing out when things could be simpler. Maybe you are preparing for a major refactor and want to identify the areas that have the most unnecessary complexity before you start. The tool works across programming languages since it is focused on conceptual clarity rather than language specific syntax rules. It does not care whether you are writing Python or Rust or JavaScript. It cares whether your code can justify its existence to a curious child.

What makes sixwhyo different from linters and traditional code review tools is the persona. Linters check syntax and enforce style rules. They tell you that your indentation is wrong or that you forgot a semicolon. They do not ask you why your architecture makes sense. Most automated code reviewers try to sound authoritative. They present their findings as facts about your code quality. sixwhyo tries to sound confused, which paradoxically makes its observations harder to dismiss. You can tell an authoritative tool that it does not understand your use case. You cannot really tell a confused questioner to stop asking why without confronting the reality that you do not have a good answer.

sixwhyo is completely free and open source. You install it via package manager using pi install git:github.com/hxii/sixwhyo and run it from the command line. It supports multiple harnesses including OpenCode, Oh My Pi, and Codex, with additional installation instructions available in the GitHub repository. The creator, who goes by hxii, is reachable via Telegram at @MrPaul for questions, feedback, or contributions. Development happens on GitHub where you can report issues, suggest features, or contribute code. For anyone tired of codebases that are more complicated than they need to be, sixwhyo offers a way to force yourself to justify that complexity, one why at a time.