---
title: "AI Doesn't Come With a User Manual"
description: "Prompt, context, RAG, evals, red teaming: the engineering disciplines born with AI are all the same reverse engineering, under new names and without the original's discipline."
author: "Anderson Henrique"
date: "2026-08-13T10:25:33.177423Z"
updated: "2026-08-13T10:25:33.177423Z"
category: "ai"
tags: ["Reverse Engineering","Context Engineering","Prompt Engineering","RAG","Evals","Prompt Injection","Social Engineering","LLM","NTLabs"]
canonical: "https://www.ntlabs.dev/en/blog/ia-nao-vem-com-manual-de-usuario"
locale: "en"
---

*Reverse engineering is the trunk. Prompt, context, RAG, evals and red teaming are branches that forgot the name of the tree.*

Every day, Chef Juan fills out by hand a sheet listing the lunch trays and dishes. When we decided that sheet would become a shopping list, the question that blocked everything wasn't architectural: it was whether the model can read that handwriting. Kitchen cursive, bad pen, paper stained with grease.

No model card answers that. No API documentation answers that. There is no specification to consult for "behavior on cursive handwriting in an industrial kitchen under fluorescent light". The only way to know is to photograph the sheet, send it, look at what comes back, change one variable, send it again.

That has had a name since the 1970s, and the name is not prompt engineering. It is reverse engineering: probing an artifact whose internals you cannot read, forming a hypothesis about the rule it follows, testing that hypothesis against observed behavior.

Anyone working with AI today does this all day long. And most of the time without admitting that is what they are doing, which is expensive: reverse engineering is an old discipline, with a method, and we are reinventing its pieces one at a time, under marketing names and without the rigor the original demanded.

## The artifact with no source

It's worth being precise about why a model is a reverse engineering target and not merely a badly documented library.

In classical software, the binary derives from source code. The source is the explanation: it states, in language a human reads, what the program does and why. When there is no source, you disassemble the binary precisely to reconstruct that explanation, and there is a correct answer waiting at the end of the work: the logic the author wrote.

With a model, what stands in place of source is weights. And open weights are not open source. You can download every parameter, hold complete physical possession of the artifact, and still have no explanation of why it responds one way and not another. Training is not a specification: it is an optimization process. Nobody wrote the rule. Not even the people who trained the model hold a document stating what it will do with your input, because that document never existed anywhere.

The result is a system whose behavior is accessible only through observation. There is no shortcut through the documentation, because there is no documentation to be written, only measurements to be taken. That is the condition of reverse engineering taken to the limit, and it is the ordinary working condition of anyone building products with AI.

## Prompt engineering was reverse engineering under the wrong name

The name suggested writing: be clear, be well organized, ask nicely. That is why the field produced so much folklore.

What competent people were actually doing was systematic probing. Discovering that the order of examples changes the result. That information buried in the middle of a long context is recovered worse than what sits at the edges. That asking for reasoning before the answer changes the answer, not merely its explanation. That a structured output format reduces hallucination more than three paragraphs of instruction begging the model not to hallucinate.

None of that was read in a manual. All of it was inferred from behavior, exactly as one infers the protocol of an undocumented driver: varying one thing at a time and watching the output.

And that explains the field's most common complaint, that recipes expire. They expire because they were never laws: they were approximate models of one specific artifact. Switching models means switching binaries. The knowledge acquired was never about "AI", it was about that version, at that temperature, over that range of inputs. Whoever treated a heuristic as a law ended up with a library of superstitions, and discovers at every upgrade that the map is gone.

## Context engineering: the teardown with two ends

Context engineering is the central discipline today, and the reason is that it is reverse engineering in two directions at once.

**The first end is the model.** What it already knows and therefore doesn't need to be told, and what it thinks it knows and needs correcting. How much context it actually uses, as opposed to how much it accepts. Where attention degrades. How it resolves a conflict between the system instruction and something appearing in the middle of a retrieved document. Which format it reads best. None of those answers are published, and all of them are obtained by probing.

**The second end is the domain.** To assemble a context you have to decide what a task requires in order to be decidable. Which document outranks the other when the two contradict. What is a rule and what is a tolerated exception. Who has authority over which field. If that sounds like requirements gathering, it is: you are reverse engineering an organization that never wrote down its own rules, with the difference that the recipient of the specification is no longer a programmer but a model, and it does not ask when something is ambiguous. It fills the gap on its own, fluently, and you find out afterwards.

Here is the point I consider the most consequential and the least discussed: **the context you assemble is an ontology.** It defines the slice of world the system is able to act upon. Whatever didn't make it into the window does not exist for that decision. It isn't that the model will ignore it: it is that, for the model, it never happened.

Compare that to the rigor we grant the classical equivalent. A database schema goes through discussion, review, versioned migration, rollback. It is the most protected structure in the system, and all it does is store data. The context, which is the structure that **decides**, is typically assembled at runtime by a retriever, with a top-k picked by feel, chunking inherited from a tutorial, and no record of what was actually sent.

In other words: the most important ontology in the system became a side effect of a similarity search, and nobody versions it.

## A map of the derived disciplines

Once you see the trunk, the branches organize themselves. They all use the same method (observe behavior, infer the rule, test the hypothesis) and differ only in the target of the teardown.

**Prompt engineering** reverses the model: how it responds to format, order, role, example.

**Context engineering** reverses the model and the domain at the same time, which is why it is the harder of the two.

**RAG** reverses the corpus. Chunking is not a parameter: it is a theory about where meaning begins and ends in that particular archive. Cutting every 512 tokens asserts that meaning is uniformly distributed through the text, which is false in practically every real document and catastrophic in contracts, medical reports and regulations, where the exception lives in a paragraph that only makes sense glued to the one before it.

**Evals** reverse the criterion. Writing a good eval is the most uncomfortable operation in the whole process, because it forces someone to declare what "correct" means, and that is precisely the thing nobody ever wrote down. Half the value of an evaluation suite shows up before it runs for the first time, in the meeting where the client discovers that their two in-house experts disagree about the expected result.

**Fine-tuning** reverses the desired distribution: which behavior you want to become the default, inferred from the cases where the current default fails.

**Agent design and tool use** reverse the procedure. It is classical requirements gathering, with the same gap between the official process and the real one, now with an executor that will not improvise the way an intern would.

**Red teaming** reverses the defenses.

**Mechanistic interpretability** is the literal case, with no metaphor at all: decompile the network, look for circuits, name features. It is the only one of these disciplines that used the right name from the start, and not coincidentally the most rigorous.

## Prompt injection is social engineering, no metaphor

There is a structural reason why the most persistent attack against LLMs is a social attack, and it deserves to be said plainly.

Classical social engineering is reverse engineering of human protocols. Kevin Mitnick almost never needed to break cryptography: it was enough to take apart the social procedure around it, the hierarchy, the time pressure, the fear of looking incompetent, the genuine desire to help. He mapped that protocol and wrote a script that executed it.

A language model learned human protocols from human text. It inherited the competence and, along with it, the vulnerabilities: deference to claimed authority, the pressure of urgency, the malleability of role-play, the willingness to be helpful even when it shouldn't. That is why Mitnick's repertoire works against a machine. It is neither coincidence nor anthropomorphism: the target absorbed the very protocol the attack exploits.

And there is an aggravating factor that is architectural, not behavioral. For the model there is no ontological difference between instruction and data. It is all tokens in the same window. The separation between control channel and data channel, which computing spent decades learning the hard way (it is the lesson of the buffer overflow, of SQL injection, of XSS), was undone in one move. Prompt injection is command injection against a parser that was not written but trained, and which therefore cannot be fixed with a prepared statement.

Anyone building an agent with tool access is building a system that executes actions from untrusted text, using an interpreter whose behavior nobody specified. Stated that way, without euphemism, it becomes clear why input sanitization doesn't solve it and why the real defense is architectural: least privilege per tool, human confirmation on anything irreversible, and the working assumption that all retrieved content is hostile.

## The objection I would raise myself

The serious objection is this: reverse engineering presupposes a hidden rule waiting to be discovered. A model has no rule, it has a statistical distribution. Calling this reverse engineering would be romanticism, borrowing prestige from an exact discipline for what is, at bottom, sophisticated trial and error.

The objection is partly right, and what it reveals is worse than what it suggests.

In classical reverse engineering there is an end point. You disassemble the binary until you reach the exact logic, and you know you got there. Here there is no end point, because there is **regularity without a rule**: behavior stable enough to be exploited and unstable enough never to be guaranteed. What you get at the end of the work is not the specification, it is an approximate model with an expiry date, valid for that version, that temperature, that range of inputs.

This doesn't disqualify the method. It changes what you should keep from it. If understanding expires, then the durable asset cannot be the prompt: it has to be the **eval**, which is the only thing that survives a model swap. A prompt is a hypothesis. An eval is the experiment that tests it. Keeping the hypothesis and discarding the experiment is what produces that folder of magic prompts nobody can explain anymore and nobody dares delete a line from.

The second objection is older and applies to the whole field: reverse engineering is the attacker's tool. Defending the practice also defends whoever uses it against you. True, and symmetric: the red teamer and the jailbreaker run the same procedure with the same competence. The difference was never in the method, it is in what you do with the map, and pretending otherwise is the most common professional naivety I know.

## What this changes in the craft

If the activity is reverse engineering, then the discipline of reverse engineering applies, and it is considerably more demanding than that of prompting.

**Treat the model as a system under test, not as an interlocutor.** One variable at a time, hypothesis stated before the measurement, counter-evidence mandatory. "It got better" is not a result, it is an impression. Fluent conversation with the model is what gets most in the way here, because it simulates understanding and discourages measurement.

**Version the context the way you version a schema.** What enters the window deserves a diff, a review and a decision record. A context ADR (what always goes in, what never does, and which wins in a conflict) is worth more than any architecture diagram of the system.

**Log the assembled context, not just the answer.** Without it, debugging is impossible, because you don't have the real input: you have the input you believe you sent. It is the equivalent of debugging a binary without being able to see the call arguments.

**Treat chunking and ranking as ontological decisions.** Write down why the cut is there. Write down what the retriever structurally will never surface, which is your system's list of known losses. A documented loss is engineering; an invisible loss is what makes a system fail confidently while nobody can say why.

**Write the eval first.** It is the specification the domain never wrote, and the only artifact still worth anything after the next model upgrade.

**Build to be taken apart by others.** If the system decides something that affects a person, that person needs to be able to ask on what basis. This is not academic decoration: it is institutionalized reverse engineering, offered by the system instead of wrenched out of it. A system that cannot say which context it decided from is not opaque by technical limitation, it is opaque by design.

## What remains

These systems are installing themselves exactly where the decision matters: between a person and the benefit, the credit line, the diagnosis, the queue. And whoever assembles the context decides which slice of the world the machine sees before answering. That is a choice about what will count as real at decision time, and today it sits buried in a top-k nobody reviewed.

The model doesn't ship with source code. It isn't going to. The competence that separates engineering from superstition, in that scenario, is the oldest one we have: take it apart with method, record what you found, and state in writing what remains unknown.

---

*This piece is part of our reflection on **transparent engineering** at NTLabs: how we build with AI, what we decide to put in the context, and what we acknowledge we are leaving out.*