The Interrogation Protocol: Developer Intelligence in the Age of AI

The Wrong Skill

Everyone is learning to "use AI." Prompt engineering courses. Copilot certifications. Tutorials on writing the perfect prompt to generate a React component in 30 seconds.

They are developing the wrong skill.

They are learning to give orders to a machine. But a machine that executes orders flawlessly is dangerous in the hands of someone giving the wrong order.

The problem has never been execution speed. The problem has always been understanding what to build.

The Poisoned Intuition

Every project starts with an intuition. Someone — a founder, a product manager, a client — thinks things should be done a certain way. They have a vision. They know what they want.

Or so they believe.

90% of the time, the request that reaches a technical team is a solution disguised as a requirement. "I want a button that does X." "I need a report with these fields." "Build an app that does this."

None of these are needs. They are all solutions. Solutions designed by someone who doesn't know the space of technical possibilities. Someone who, in good faith, operates within the perimeter of what they can imagine.

And this is where the gap opens.

The operator takes the request and implements it. To the letter. Clean code, green tests, automated deploy. Perfect.

The interrogator stops. Opens an investigation.

I Don't Know What I Don't Know

Socrates said it twenty-five hundred years ago: the real problem is not ignorance — it's the ignorance of one's own ignorance.

Whoever makes a technical request operates inside a limited mental model. Limited not by stupidity, but by the lack of knowledge of what is possible. If you don't know that a completely different way to solve your problem exists, you can't ask for it.

The client says:         "I want an Excel with updated data every morning"
The operator builds:     A script that generates an Excel and sends it by email
The interrogator asks:   "What do you do with that data once you open the file?"
The real answer:         "I check if a number exceeds a threshold"
The real solution:       An automatic alert that notifies only when needed

The Excel file was never the need. It was the only solution the client could imagine.

Completely redesigning the information protocol — not following the request, but understanding the real need and the space where there's room for movement — is the true value add. And it's exactly what no AI model can do, because the context is not in the prompt. It's in the conversation, in the hesitations, in what's left unsaid.

The Interrogator's Techniques

In a real interrogation, an agent never asks "did you do X?" They ask open-ended questions, observe reactions, build a complete picture before reaching conclusions. The effective developer operates with the same discipline.

Technique 1: Never Accept the First Answer

The first request is always a symptom, not the diagnosis. It's not the starting point — it's the initial clue.

• "I need a CRM" → Why? What's broken today?
• "I want to migrate to microservices" → What specific problem are you having with the monolith?
• "Add AI to the product" → To do what, exactly? For whom?

Technique 2: Read What's Not Said

The requirements document tells you what they want. The conversation tells you what they need. The difference lies in:

• Hesitations: "Yes, but... actually..." signals that the official request isn't the real one
• Repetitions: If they insist on a point, there's a hidden fear underneath
• Omissions: What didn't they mention? Who's not in the room but should be?

An AI model reads the text. The interrogator reads the person.

Technique 3: Challenge the Premise

The most powerful question is not "how do we build this?" but "why does it have to be this way?"

Every requirement has an implicit premise. Often that premise is a constraint that no longer exists, a habit, or a decision made years ago by someone who no longer works there.

Implicit premise:   "Reports must be generated at night"
Question:           "Why at night?"
Answer:             "Because the database slows down"
Question:           "Why does the database slow down?"
Answer:             "Because the queries are heavy"
Real solution:      Optimize the queries, not schedule the reports

Technique 4: Map the Territory, Not the Map

Before writing a single line of code, the interrogator maps:

• Who actually uses the system (not who requested it)
• Where the real operational friction is generated
• When the process breaks (not when it works)
• What would happen if we built nothing

The last question is the most important. If the answer is "nothing serious," maybe the thing to build is something else entirely.

Technique 5: The Socratic Inversion

Your job is not to have the answers. It's to help the other person discover what they actually need. This means:

• Reformulating the request in different words and asking for confirmation
• Proposing alternative scenarios: "What if instead of X, we did Y?"
• Making consequences visible: "If we build this, we give up that. Is that okay?"

You're not contradicting the stakeholder. You're guiding them outside their mental model.

The AI Paradox

An AI model executes any prompt flawlessly. It generates correct code, tests included, impeccable documentation. But it cannot do the most important thing:

Recognize that the prompt is solving the wrong problem.

This is the human advantage. Not speed. Not syntax. The ability to perceive that something is off even when everything compiles. To sense that the requirement has a hole even when the Jira ticket is perfectly written.

The better AI gets at executing, the more human value concentrates on:

• Context error perception — the code works, but it's not what was needed
• Reading the interlocutor — understanding the unsaid, the fears, the internal politics
• Domain knowledge — knowing what the training data doesn't cover
• Judgment — deciding what not to build

How to Build Interrogators

These skills don't develop through a course. They are built through intentional practice:

• Code review as interrogation: Don't ask "is the code correct?" but "why did you solve the problem this way?"
• Pair debugging: You don't debug the code — you debug the understanding of the problem
• Domain rotation: A developer who understands the business asks better questions than one who only understands the code
• Solution post-mortems: Not just "what went wrong?" but "did we build the right thing?"

Conclusion

In a world where anyone can generate code in seconds, scarcity is not in production. It's in comprehension.

The most valuable developer is not the one who writes the fastest. It's the one who stops, opens an investigation, and discovers that the real problem is three levels below the initial request.

The best code doesn't come from the best prompt. It comes from the right question, asked to the right person, at the right time. And that question is not generated by any model — it's generated by someone who knows the context, perceives the error, and has the courage to challenge the premise.

---

This is operational doctrine. Deploy accordingly.