If You Are Nothing Without the LLM
"If you are nothing without the LLM, you should not have it." Read constructively: the tool should amplify an engineering ability that exists, not stand in for the understanding required to own the result. The strongest opposing view — that fluency with the tool is itself the new skill — is stated and taken seriously.
The situation, the reflex, and why it stalls
Every lesson starts where being stuck starts: someone has a problem, and the first move that comes to mind feels like progress.
What does it mean to be "nothing without the LLM", how would you tell whether it describes you on a given piece of work, and what does the sentence actually ask you to do?
You built the store's checkout in a week with an assistant and it works. A colleague asks how the inventory reservation interacts with payment failure, and you realise you would have to ask the assistant to find out. You are not sure whether that is a problem or just how work is now.
Decide it is just how work is now. The output is real, the customer can check out, and the colleague could ask the assistant too. Insisting on understanding every mechanism sounds like the people who insisted on understanding assembly. The tool moved the line; you moved with it.
The line the tool moved is the one between syntax and mechanism, and the question the colleague asked was about mechanism. Whether reservation survives payment failure is not a fact about the assistant; it is a fact about your store, and nobody can currently state it.
- The line the tool moved is the one between syntax and mechanism, and the question the colleague asked was about mechanism. Whether reservation survives payment failure is not a fact about the assistant; it is a fact about your store, and nobody can currently state it.
- The work looks like engineering and is, at the moment the colleague asked, transcription. The distinction is invisible in the output and decisive in the incident: transcription cannot be debugged by the transcriber (Before You Copy Code).
- "Just how work is now" is also what the assembly people's critics said, and they were right — about syntax. They were not right about mechanism; a compiler hides register allocation, it does not hide whether your program is correct.
- The sentence is dismissed as gatekeeping before its constructive reading is tried, and the constructive reading is the useful one: it says what you should be able to do, not who should be allowed to use the tool.
The move
Precisely enough to apply it to a problem you have never seen — not a slogan.
- Read the sentence as a test rather than a verdict: on this piece of work, if the assistant vanished, what could you still do? If the answer is "state what the system does, why, and how it fails; change it; debug it", you are an engineer using a tool, and the tool is amplifying an ability that exists. If the answer is "nothing", the tool was not amplifying; it was substituting, and the result is not yours in any sense that will survive an incident.
- Separate the two things the tool can do: produce output, and produce understanding. It is very good at the first and, used as a partner, useful for the second — but only if you do the part that makes understanding yours: predict, recreate, explain, verify (Explain It Back). Output without that is a result you are holding, not one you own.
- Apply the test per piece of work, not per person. Nobody is "nothing without the LLM" in general; everyone is, on some piece, at some moment — the presigned-URL flow they never understood, the retry wrapper. The sentence is about those pieces, and its instruction is to find them and go one layer deeper (The AI Dependency Check).
- Take the opposing view seriously, because it is partly right: fluency with the tool — forming questions, judging output, steering a long session — is a real skill with real value, and someone with it and less mechanism knowledge can outproduce someone without it. Where the two views differ is on what happens when the output is wrong, and that is the case the sentence is about.
The claim, walked down a why ladder
The sentence is a claim, and this domain treats claims by asking why until the requirement underneath appears. The ladder below runs it down to what is actually needed, names the simpler thing that meets it, and — because the device demands it — says when the strong form of the claim was right after all.
“If you are nothing without the LLM, you should not have it.”
- ↓Why should someone who depends on it not have it? Because when its output is wrong — and it will be — the person holding the output cannot tell, cannot fix it, and cannot say what the system now does.
- ↓Why does that matter more here than with a compiler? A compiler's output is wrong in ways that are rare, detectable and below the level of your intent. The assistant's output is wrong at the level of intent — the wrong state, the leaked reservation — where only understanding of the problem can detect it.
- ↓Why is ownership the thing at stake, rather than authorship? Nobody needs to have typed the code. Someone needs to be able to state what it does, why, and how it fails, so that the system can be changed and debugged. That is ownership, and it is what the incident will demand.
the claim was right when The strong form is right for a learner whose goal is the ability itself: on a learning project, using the tool for the first attempt substitutes for the exact thing being learned, and "should not have it" is the correct rule until the ability exists (No AI on the First Attempt).
Amplify against substitute
The comparison is the same week of checkout work, with the tool used two ways. The output is comparable; what differs is what exists afterwards besides the output.
Describe the feature; accept the implementation; test the happy path; ship. Afterwards: a working checkout, and a person who has to ask the tool what it does under timeout.
State the invariants and the failure branches; predict what each should do; have the tool draft; recreate the reservation-release logic on paper; verify the timeout branch by injecting one. Afterwards: a working checkout, a found bug, and a person who can answer the colleague.
Both weeks used the tool for most of the typing. The second week did the parts the tool cannot do — prediction, recreation, verification — and those are exactly the parts that make the result ownable. The difference is not how much the tool was used; it is whether the understanding step was done by anyone (Understanding Is Not Delegable).
Where the sentence applies, and where the opposing view wins
The decision below is the per-piece test. Its options are not "use the tool" or "do not"; they are how much ownership a piece requires, which decides how much of the understanding work is mandatory. The opposing view is right in the first row and wrong in the last, and most work is in between.
For this piece of generated work, what happens if the output is wrong in a way I did not predict?
when The result can be verified against known truth — a dashboard total, a formatting helper — and a wrong answer costs a re-run.
cost Judgment about the output is the whole job; tool fluency is the skill; mechanism understanding is optional and the opposing view is right.
when The code will be modified, and a wrong modification is caught by tests and review before customers see it.
cost Recreation and explanation are required; failure modes can be learned when the code is next touched.
when A wrong output is a double charge, a leaked reservation, an exposed file, and it is found by a customer.
cost All four dependency-check answers must be yes before it ships. Here the sentence is a rule, not a slogan.
How to do it
Most important first.
- Pick the piece of your system with the highest blast radius that the assistant wrote most of. Close the tool and answer the colleague's kind of question about it out loud: what does it do when X fails? If you cannot, that piece is the one the sentence is about.
- Keep a short list of "pieces I could not defend without the tool" in the notebook, and pay them down as in The AI Dependency Check. The list shrinking is the constructive reading in practice.
- Once a week, build something small with the tool closed — a slice, a query, a state machine — so that the ability the tool is supposed to amplify is measured rather than assumed (Learning Without AI).
- When using the tool, do the parts only you can: state the problem, predict the answer, verify it. Skipping those is the mechanism by which "using" becomes "being nothing without".
- Notice when the tool is producing understanding versus output, and name it: "this session taught me how presigned URLs work" is different from "this session produced the upload flow", and only the first survives the tool's absence.
Worked on a concrete problem
The move has to produce something. This is what it produced.
- The colleague's question, answered the constructive way. You cannot say whether reservation survives payment failure. You close the tool and read the checkout path: reservation happens before the charge; on failure, a compensating release is called — but only in one of two failure branches. The other branch, a timeout, leaks the reservation. You found a bug and you understand the mechanism; both were unavailable an hour ago, and both came from doing what the sentence asks rather than from arguing with it.
- The opposing view, at its strongest. A colleague builds the analytics dashboard with the assistant in two days and cannot explain the windowing query it uses. The dashboard is correct, checked against known totals, and the colleague's skill — knowing what to ask, catching the two wrong answers, steering the session — is real and produced a result faster than anyone without the tool could have. On this piece, for this purpose, "nothing without the LLM" is false: the ability being amplified is judgment about the output, and it existed. The sentence bites only when the dashboard is wrong in a way the checks do not catch.
- The AI assistant for company documentation, where the sentence bit. Built with the tool, it answers most questions well. One day it starts answering with confident fabrications for a category of questions, and the person who built it cannot say how retrieval feeds generation, so cannot say where the fabrications enter. Two days of asking the tool about its own architecture produce guesses. The fix comes from someone who understood the mechanism, in an hour. The output was real; the ownership was not.
How you know it worked
What now exists that did not before, and what question you can now ask.
- On any piece of the system that matters, you can answer a mechanism question with the tool closed, or you know that you cannot and it is on a list.
- You can say, for a given session, whether it produced understanding or only output, and the ratio is one you chose.
- The tool's absence — an outage, a policy, a plane — slows you down without stopping you.
- You can state the opposing view fairly and say on which pieces of your own work it is right.
The questions you can now ask
The field this whole domain exists for. After this lesson, these are the questions to put to an unfamiliar problem.
- ?If the tool vanished, what could I still do with this piece of work — state it, change it, debug it?
- ?Did this session produce understanding or only output, and which did I need?
- ?Which pieces of my system could I not defend to a colleague without the tool, and which of those matter?
- ?On which of my own work is the opposing view — that steering the tool is the skill — actually right?
What can go wrong
- The sentence is read as a ban, and the tool is set aside on principle. That trades real amplification for purity; the sentence asks for ownership of results, not abstinence.
- The sentence is read as a verdict on people rather than a test on work. Nobody is nothing; some pieces of everyone's work are unowned, and the useful response is a list, not a judgment.
- The test is applied to syntax. Not remembering an API signature without the tool is not the failure the sentence names; not knowing what your system does under timeout is.
- Understanding is pursued for everything equally, and the tool's speed is lost on code that never needed to be owned deeply. Blast radius decides where the sentence applies.
- Taking the sentence seriously slows the pieces it applies to, and those are often the pieces that were going fastest. The speed was borrowed.
- Building without the tool on a schedule costs time that produces nothing visible; it is measurement, and measurement is overhead until the reading matters.
- Stating the opposing view fairly means admitting that on some work, tool fluency beats mechanism knowledge, which weakens the sentence as a slogan. It strengthens it as a test.
- "So people who rely on the assistant are not real engineers." The sentence is about pieces of work, and every engineer has unowned pieces. The response is to find them, not to rank people.
- "Understanding the mechanism means understanding every layer." It means being able to state what your system does and why, at the layer where it fails. The compiler analogy holds below that layer and fails above it.
- "The opposing view is just an excuse." It is a real position with real evidence — the two-day dashboard was good work. It is incomplete, not wrong, and the incomplete part is what happens when the output is wrong.
Where this applies
Problem-solving advice is stated as universal far more often than it is. These labels say what each method is specific to — and where CONTESTED appears, the note gives the strongest form of the opposing view.
- GENERALThe test — what could you still do without the tool — applies to any accelerator: a framework, a library, a senior colleague. The assistant is the case where substitution is most fluent and therefore hardest to notice.
- CONTESTEDThe strongest opposing view: the new engineering skill is fluency with the tool itself — forming precise questions, judging and steering output, catching wrong answers, composing sessions into systems — and someone with that skill and thin mechanism knowledge will reliably outproduce someone with deep mechanism knowledge and no fluency. On this view "nothing without the LLM" is as empty as "nothing without a compiler": the tool is the layer, and understanding below it is optional the way assembly is. The view is at its strongest on well-checked outputs with low blast radius, where judgment about the result is the whole job, and it is genuinely unclear how far up the blast-radius scale it holds.
- ILLUSTRATIVEThe reservation leak, the two-day dashboard and the fabricating assistant are invented to show both readings of the sentence producing consequences; no real team is described.
Where the depth lives
This domain asks the question and hands the answer off by name.
- — The manifesto at /manifesto is the long form of this sentence, and /manifesto/without-ai is its practice. This lesson exists to say where the sentence is a rule, where it is a test, and where its critics are right.