The Problem With AI That Agrees With Everything

One of my biggest complaints about working with AI coding assistants is that they're often far too eager to please. Give one a half-baked idea for an application and it'll happily start building it, inventing whatever requirements you forgot to mention along the way. Three hours later, you've got several thousand lines of code, a database schema you never agreed to, and an authentication system that apparently exists because the AI thought it would be nice.

The really annoying part is that the AI probably knew there were unanswered questions. It just decided that making assumptions was more productive than bothering you with them. Sometimes that's perfectly fine. Nobody needs a committee meeting to decide what color a loading spinner should be. Unfortunately, the same enthusiasm gets applied to architectural decisions, security requirements, user permissions, deployment strategies, and all the other things that can turn a perfectly good project into a magnificent pile of expensive regret.

I wanted something that would force an AI to stop making those decisions for me. Not another chatbot that asks three generic questions before declaring it understands everything, but something that genuinely investigates what I'm building, figures out what's missing, and makes me confront the decisions I've been conveniently ignoring.

So I built inquisitor, which is essentially what happens when you give an AI developer a clipboard, a suspicious attitude, and permission to be an absolute pain in the arse.

Meet the Inquisitor

Inquisitor is part of my FKNRTD collection of AI development skills, alongside butcher, conspirator, and odin. Each has a particular job, and inquisitor's is simple: question everything that hasn't already been answered.

When invoked, inquisitor examines the existing project before generating a single question. It reads documentation, project requirements, development notes, and whatever relevant information is already available. This is important because I don't want to spend twenty minutes explaining something that's clearly written in a README file the AI was apparently too lazy to open.

From there, it identifies missing requirements, conflicting decisions, architectural uncertainties, and anything else that could cause problems further down the road. Rather than dumping a wall of questions into a terminal and expecting me to answer them one at a time, inquisitor generates an actual interactive HTML questionnaire.

The result is a self-contained page that I can open in my browser and work through at my own pace. Questions are organized by topic, assigned priorities, and presented with possible answers. When the AI has enough information to recommend an option, it explains what it recommends and why. I can accept its suggestion, choose something different, write my own answer, add notes, or defer the decision entirely.

That last option is particularly useful because sometimes the correct answer really is "I haven't got a bloody clue yet." There's nothing wrong with that, provided we acknowledge that the decision is still outstanding instead of pretending it magically resolved itself.

An Interrogation, Not Another Conversation

The part I particularly like about inquisitor is that it separates the decision-making process from the usual back-and-forth conversation with an AI.

A typical project might generate fifty questions covering functionality, security, interface design, data storage, deployment, and future requirements. Answering those through a CLI would be miserable. You'd spend more time scrolling through conversations than actually thinking about the project.

Inquisitor turns those questions into a structured interface with recommendations, explanations, progress tracking, filters, and the ability to accept suggested answers in bulk. It also distinguishes genuine blockers from important decisions and things that can reasonably be postponed. That means I can concentrate on what actually prevents development from moving forward without getting distracted by whether a settings menu should open from the left or right.

More importantly, the answers aren't lost when the conversation ends.

In Chrome or Edge, I can connect the generated questionnaire to its local folder and have my responses automatically written to an answers.md file as I work. Other browsers can retain the answers locally and export the file when I'm finished. Everything stays in ordinary files, with no hosted service, database, or account required.

When I return to the coding assistant, it reads that Markdown file and treats my answers as the project's decisions. Anything deferred remains unresolved, and anything accepted in bulk can be checked before the AI commits to expensive or irreversible work. If new questions come up later, the questionnaire can be rebuilt without throwing away the answers I've already provided.

It's a fairly straightforward idea, which makes me wonder why more AI development workflows don't work this way.

Why I Built It

I've been building increasingly complicated applications with multiple AI models and coding assistants, and I've discovered that writing code is rarely the biggest problem anymore. Figuring out exactly what should be written, how everything connects, and what the finished product is supposed to accomplish can be considerably more difficult.

AI has made it ridiculously easy to produce code. Unfortunately, producing code and producing the right application are two very different accomplishments.

I can ask an AI to build a complete application and get something surprisingly functional without writing much code myself. What I can't do is expect that same AI to read my mind, understand every little preference I've developed over decades of programming, and magically recognize which decisions I'm going to regret six months later.

Inquisitor helps close that gap. It forces the questions into the open while I'm still in a position to make informed decisions, rather than discovering halfway through development that we apparently have two completely different definitions of what "finished" means.

It also makes working with multiple AI models considerably easier. Once I've answered the questionnaire, I have a reusable set of requirements that can be handed to Claude, Codex, Cline, or whichever model I'm currently experimenting with. Instead of repeating the same conversation every time I switch tools, I can give them the decisions I've already made and tell them to get on with the job.

The Bigger Picture

I'm gradually building a collection of skills that address the things I find most frustrating about AI-assisted development. Butcher eliminates unnecessary token consumption and pointless narration. Conspirator gets different AI coding assistants working together instead of pretending one model knows everything. Odin investigates projects and produces documentation that someone other than the original developer might actually understand.

Inquisitor handles the part that comes before all of that. It makes sure we're asking the right questions before we start producing the wrong answers at an impressive rate.

None of these skills is intended to replace the developer. They're designed to make the developer's decisions more meaningful while removing some of the repetitive nonsense that gets in the way of building something useful.

And if inquisitor occasionally makes me realize that my brilliant new idea has seventeen unresolved architectural problems, no clear deployment strategy, and a security model held together by optimism, then I'd say it's doing exactly what I built it to do.

I'd much rather have an AI annoy me with difficult questions at the beginning of a project than congratulate me on successfully completing something I never actually wanted.

You can find inquisitor, including its source code, installation instructions, and documentation, on GitHub:

https://github.com/nullcromancer/FKNRTD.SKL/tree/main/inquisitor

As always, be good, or don't get caught.