Vibe Coding and the IKEA Effect
Text
1. The claim
The IKEA effect is the finding that people place higher value on things they assembled themselves. The interesting part for engineering is not the valuation. It is that the sensation of competence produced by assembly is nearly indistinguishable, from the inside, from the sensation produced by comprehension.
Both feel like understanding. Both produce accurate answers to “what does this do”. They diverge on one question, and it is the only question that matters during an incident: how does this fail?
2. Three kinds of knowledge
| Knowledge | What buys it | When it is needed |
|---|---|---|
| What it does | Reading the interface, or watching it run once | Every day. Cheap and sufficient most of the time. |
| How it does it | Reading the implementation, or reconstructing it from behaviour | During extension and optimisation. Assembly sometimes supplies this by accident. |
| How it fails | Reading the error paths, or surviving them in production | During incidents, and only then. Assembly never supplies it. |
The third row is where the argument lives. Error paths are the least-read code in any system: they are rarely exercised in development, rarely covered by the happy-path tests that assembly produces, and rarely present in the example the code was modelled on. Generated and copied code inherits this bias, because it is trained on and drawn from code that is itself mostly happy path.
perceived actual competence competence|###########| |####| |###########| |####| assembly done what it does working system how it fails: 0
3. Why the confidence signal misfires
Effort is the proxy the mind uses for depth of understanding, and integration work is genuinely effortful. Getting four components to agree on a data format, an auth scheme and a deployment target is hard, absorbing, and produces a legitimate sense of achievement. The proxy is not stupid. It is measuring the wrong quantity.
Two effects make it worse in current practice.
3.1. The feedback loop is fast and one-sided. A generated module that compiles and passes the tests you asked for arrives in seconds, and the loop closes on “it works”. Nothing in that loop ever asks what happens when the upstream returns a 503 mid-stream.
3.2. Review inherits the same bias. A reviewer reads a diff for correctness against the stated intent. If neither author nor reviewer has read the error paths, the review confirms the happy path twice and records it as two independent confirmations.
Figure 2. Ranked from code review, not measured. The bottom row is the claim; the others are context for it.
4. The remedy, which is not “write it yourself”
Refusing generated or borrowed code is not available and would not be correct. Every engineer working today assembles from parts they did not write, and that has been true since the first shared library. The remedy is to buy the third kind of knowledge deliberately, because it is the only kind assembly never supplies for free.
4.1. The prediction test. Before merging, state in one sentence how this component fails: what it does on timeout, on partial write, on malformed input, on a dependency returning success with an empty body. If you cannot answer without running it, you have assembled it and not read it. That is fine, and now you know which one you did.
4.2. Read the error paths only. A full read of generated code is often not worth the time. A read of every branch that handles a non-success condition almost always is, and it is a small fraction of the lines.
4.3. Put the failure mode in the pull request. One line, in the description. It makes the gap visible to the reviewer, converts an assumption into a claim, and is the artefact that pays off during the incident eighteen months later. See 5.11.
4.4. Add one adversarial test per component, not per function. Not coverage. One test that does the rude thing: kills the connection halfway, sends the wrong content type, returns 200 with an empty body.
5. The strongest objection
6. What this paper does not claim
Generated code is not lower quality. In my experience it is often better than the median hand-written equivalent on the happy path, and the engineers using these tools are not less skilled than the ones who do not. Reading is not always worth the time either; Section 4.2 exists precisely because it usually is not.
The claim is narrow. Assembly produces two of the three kinds of knowledge in Section 2, the missing one is the one incidents require, and the feeling of understanding does not report which of them you are holding.
Retirement conditions
This paper MUST be retracted if any of the following is demonstrated.
| § | Condition |
|---|---|
| 1 | A blind study in which engineers who assembled a system without reading its generated internals diagnose induced faults in it at the same rate and speed as engineers who wrote the equivalent system by hand. |
| 2 | Evidence that the confidence gap in Section 3 closes with tooling rather than with reading, for example a generation workflow whose users predict failure modes as accurately as authors do. |
| 3 | A demonstration that the effect is about ownership rather than comprehension, appearing at equal strength for code the engineer merely selected rather than assembled, which would make this a paper about a different mechanism. |
Revision history
| Date | Change |
|---|---|
| 2026-08-14 | Text written: the three kinds of knowledge, why the confidence signal misfires, the four practices, and the library objection. Retirement conditions added. Confidence unchanged. |
| 2026-05-02 | Listed in Section 5 with a title, a summary and a confidence value. No text. |