How Many Vibecoders Does It Take to Change a Light Bulb?
One human, one ChatGPT, and a dozen YouTube videos showing almost — but not quite — the same thing.
And, as it turns out, a surprising amount of trial and error.
The light bulb in question was the right-hand low-beam headlight of my 2002 Volkswagen Polo 1.4 TDI. A twenty-four-year-old car, the sort of vehicle on which you might reasonably expect to be able to replace a headlight bulb without consulting an engineer.
I had a replacement bulb. I had a Torx screwdriver. I had ChatGPT.
How difficult could it be?
A Simple Job, In Theory
The first problem was getting to the bulb.
Behind the right headlight sits a cylindrical metal object with several black hoses connected to it. There is also a round rubber cover protecting the back of the headlight, but the cylinder makes it almost impossible to reach.
I described the situation to ChatGPT. It identified the cylinder as the diesel fuel filter and located a technical bulletin from Hella explaining the procedure for my particular model of Polo.
Excellent. We had documentation.
According to the bulletin, the fuel filter’s mounting bracket could be released by removing a Torx T40 screw. The filter could then be moved aside, allowing access to the headlight.
I located the screw, removed it, and tried moving the filter.
It moved perhaps one centimeter.
That was it.
ChatGPT suggested that the movement might be normal and warned me not to force the fuel hoses. Sensible advice. I also watched several YouTube videos, but they were for slightly different cars, engines, or headlight assemblies. Each revealed something useful; none provided the complete answer.
Eventually, with some careful maneuvering, I managed to get my hand behind the headlight and remove the rubber cover.
Progress!
And now came the interesting part.
The Confidently Moving Target
Behind the cover was the electrical connector attached to the bulb, surrounded by a black plastic ring.
I sent ChatGPT photographs.
It explained that I should first pull off the electrical connector, revealing the bulb’s terminals, and then rotate the retaining ring to release the bulb.
That sounded plausible.
Except that, while feeling around the assembly, I managed to turn something, heard a satisfying click, and pulled out the entire bulb and connector together.
No need to disconnect anything first.
So far, so good. I could now maneuver the assembly into a more accessible position, disconnect the old bulb, and install the new one.
But replacing the assembly proved much harder than removing it.
I could see through the front of the headlight that the bulb was properly aligned. It fitted into its opening, but it would not lock into place.
ChatGPT proposed another explanation: the bulb had a locating tab that needed to be positioned at the top before the whole assembly could be rotated clockwise into place.
I inspected the original photographs and noticed that the tab seemed to have passed a flexible metal clip and ended up approximately fifteen degrees farther around.
Aha! That appeared to confirm the theory.
I tried again.
Still no luck.
Then I finally understood what was happening.
The bulb and its electrical connector weren’t supposed to rotate at all. The black plastic retaining ring around them was.
Once I turned the correct component, the assembly locked into position.
Job done.
It had taken one human, one ChatGPT, and a dozen approximately relevant YouTube videos to change a light bulb.
And ChatGPT had been confidently wrong several times along the way.
The Real Problem Wasn’t the Wrong Answers
There is an easy version of the moral here: don’t trust AI.
But that would be a rather uninteresting conclusion, and it wouldn’t describe what actually happened.
ChatGPT was extremely useful.
It identified the obstructing component, found documentation for the exact vehicle, identified the required tool, explained the likely bulb type, and repeatedly warned against forcing fuel hoses or fragile fittings.
Without it, I might have spent considerably longer getting started.
The YouTube videos were useful, too, even though none showed precisely my configuration.
And my own observations were useful — but not infallible. I had initially concluded that the bulb and connector rotated together because that was what appeared to happen when I removed them.
The problem wasn’t that one source was unreliable and another was reliable.
The problem was that we kept promoting hypotheses into conclusions before we had enough evidence.
Every new finding seemed to settle the matter.
A photograph suggested a retaining ring. Therefore, disconnect the connector and turn the ring.
The assembly came out with the connector attached. Therefore, perhaps the entire assembly was supposed to rotate.
A locating tab appeared fifteen degrees out of alignment. Therefore, insert it with the tab upright and rotate everything fifteen degrees.
Each interpretation made sense given the available evidence.
Each was expressed, at least initially, with more certainty than the evidence justified.
And this was the same mistake I was making as the human operator. Every plausible explanation briefly became the solution, until the next attempt showed otherwise.
That is where I think this story becomes relevant to software development.
Vibecoding Is Also a Black-Box Investigation
Imagine asking an AI coding agent to implement a feature in an application.
It writes the code. It compiles. You launch it.
Something doesn’t work.
The agent looks at the code and announces that it has identified the problem. It changes a function.
Still broken.
It identifies another problem, edits a different file, and confidently reports that the issue is fixed.
Still broken.
Eventually, after several iterations, the feature works.
This is familiar territory for anyone who has spent time developing software with AI agents.
But consider what happened during those iterations.
Did the agent actually establish the cause of the bug before making changes? Or did it repeatedly discover plausible explanations and act on them?
Did it inspect runtime behavior, logs, inputs, outputs, and relevant documentation? Or did it infer the application’s behavior from what the source code appeared to say?
Did the human operator distinguish between confirmed facts and the agent’s interpretations?
And, critically, when the agent’s hypothesis failed, did everyone learn something useful, or did the conversation simply move on to the next guess?
My headlight was a small mechanical system I could barely see and could only partially feel.
A software application can be an equally opaque system, even when all its source code is available.
We have logs instead of photographs. Debuggers instead of fingers. Tests instead of trial fits. Documentation instead of workshop manuals.
And plenty of YouTube tutorials, Stack Overflow answers, GitHub issues, and AI-generated explanations that describe systems remarkably similar to ours.
But not necessarily identical.
A Better Mental Model: Investigate Before You Commit
The lesson I take from this experience is that we need to think less like people asking an oracle for instructions and more like investigators assembling evidence.
In particular, we need to preserve a distinction between four things:
Observations. What have we actually seen happen?
Information. What do documentation, source code, videos, manuals, and other people tell us?
Hypotheses. What explanations are consistent with the observations and information?
Tests. What can we do to distinguish between competing explanations?
That distinction sounds obvious. Yet it was remarkably easy to lose during a fifteen-minute conversation about a headlight.
At one point, we had an observation: turning something produced a click and released the bulb.
We also had a hypothesis: the bulb and connector must rotate together.
What we lacked was a discriminating test.
Had we stopped to ask which component actually moved relative to the headlight housing?, we might have identified the retaining ring much earlier.
Instead, we built a procedure around an interpretation.
In software terms, we had seen a symptom, inferred a cause, and patched the code before verifying the inference.
Maintain an Evidence Ledger
An AI coding agent doesn’t necessarily need a formal document for every little bug. But it can be useful to maintain a small, explicit record of what is known.
For my headlight, it might have looked like this:
The most important column is the last one: status.
A plausible explanation doesn’t become a fact because the AI expressed it confidently. Nor does it become a fact because a YouTube mechanic used it successfully on a similar car.
This distinction scales surprisingly well to programming.
For example:
- The API returns HTTP 500: observed.
- The failure began after upgrading a dependency: observed.
- The dependency upgrade caused the failure: hypothesis.
- The new version changed authentication behavior: documented possibility.
- Reverting the upgrade eliminates the failure: evidence supporting the hypothesis, but not necessarily proof of the precise mechanism.
What matters is knowing which statements are facts and which are interpretations.
Use Each Source for What It Does Best
Another lesson is that different sources provide different kinds of knowledge.
The workshop bulletin knew something about the vehicle’s intended construction.
The YouTube videos showed how similar mechanisms behaved in practice.
Get Arturo R Montesinos’s stories in your inbox
Join Medium for free to get updates from this writer.
ChatGPT helped combine information, explain possibilities, and suggest next steps.
My photographs preserved details that were otherwise hard to remember.
My hands provided feedback that no description could reproduce: resistance, movement, alignment, and the distinctive click of a mechanical latch.
None of these sources was sufficient by itself.
More importantly, they weren’t interchangeable.
A workshop manual can describe the correct procedure but cannot tell you whether someone previously installed a part incorrectly.
A video can demonstrate a technique but may conceal a crucial difference between model years.
An AI can recognize common patterns but can mistake a plausible mechanism for the actual one.
And a human can observe the physical system directly while misunderstanding what those observations mean.
The goal is not to find the single source that knows the answer. It is to combine sources without confusing their respective strengths.
This applies directly to AI-assisted programming.
Source code tells us what the program is written to do.
Documentation tells us what it is supposed to do.
Tests tell us what particular executions produced under particular conditions.
Logs tell us what happened during real executions, within the limits of the available instrumentation.
An AI coding assistant helps connect these sources and develop explanations.
And the human developer decides when there is enough evidence to act.
The Cheapest Useful Test
There is another principle that became obvious in retrospect: we should prefer small tests that resolve uncertainty over large interventions based on assumptions.
When I couldn’t lock the replacement bulb into place, I could have removed more components, loosened more screws, or tried forcing the assembly.
None would necessarily have helped.
The useful question was simpler: What rotates, and what stays still?
That was the missing piece of information.
The software equivalent is familiar.
Before rewriting a database access layer because queries are slow, inspect the query plan.
Before replacing a networking library because requests fail, capture the actual request and response.
Before restructuring an application’s state management because the interface displays stale data, identify where the state first becomes inconsistent.
Before allowing an AI agent to change five files, ask what observation would confirm its diagnosis.
Sometimes the smallest experiment is adding a log statement.
Sometimes it’s writing one failing test.
Sometimes it’s checking the exact version of a dependency.
And sometimes it’s simply asking the agent to explain what evidence distinguishes its preferred explanation from the alternatives.
Of course, not every decision requires a forensic investigation. If a coding agent makes a trivial change, the tests pass, and the risk is negligible, there is no reason to convene a committee.
But the more uncertain the diagnosis, and the more costly or irreversible the proposed intervention, the more valuable it becomes to test before acting.
That principle works for cars, too. Especially when fuel lines are involved.
Why AI Makes Premature Certainty So Tempting
AI assistants have a particular conversational habit that makes this problem worse.
They are very good at producing a coherent explanation of the evidence currently available.
That is useful.
But coherence is not confirmation.
When I said the bulb had come out with the connector still attached, ChatGPT produced a plausible account of a rotating connector-bulb assembly.
When I mentioned the locating tab and the metal clip, it produced another plausible mechanical explanation.
Both fitted the story I was telling.
Neither had been independently verified.
A conversational AI is particularly susceptible to treating the user’s latest observation — or interpretation of an observation — as the missing clue that completes the puzzle.
Humans do this too. We like the satisfying aha! moment when scattered facts appear to form a pattern.
But a pattern that fits the evidence isn’t necessarily the only pattern that fits.
A better AI response might have been:
There are at least two possibilities. Either the bulb and connector rotate together in a bayonet mount, or an independent retaining ring rotates around a stationary bulb. Your observation doesn’t yet distinguish them. Can you check which part moves?
Less decisive, perhaps.
Much more useful.
An assistant should not respond to every new clue as if the mystery has finally been solved. It should update the set of plausible explanations, discard those contradicted by evidence, and suggest the next useful test.
And that is something we can explicitly ask it to do.
Managing an AI Agent as an Investigator
If I were to extract a practical method for vibecoding from this experience, it would be something like this:
First, establish what is actually happening.
Not what the code ought to do, not what the documentation promises, and not what the agent assumes. Capture the actual behavior.
Second, collect relevant information without immediately committing to an explanation.
Inspect the code, documentation, logs, tests, and external examples. Pay attention to version differences and environmental assumptions.
Third, ask for competing hypotheses.
They needn’t be numerous. Two or three plausible explanations are often enough to prevent premature certainty.
Fourth, choose the cheapest test that distinguishes them.
Ideally, a test that changes as little as possible.
Fifth, make the intervention only when the evidence justifies it.
And after making it, verify the result. A successful build isn’t proof that a bug is fixed, just as a bulb fitting into its opening isn’t proof that it is locked in place.
Finally, record what was learned.
A confirmed diagnosis, a regression test, a corrected comment, a small piece of documentation — or, in my case, a note in Obsidian explaining how to change the damn bulb next time.
There is no need to make this bureaucratic.
For a small task, the entire process may take a minute. For a difficult bug, it may take hours.
The important part is the mental model, not the paperwork.
The Human Doesn’t Have to Know the Answer
Perhaps the most interesting aspect of this experience is that I didn’t know how the retaining mechanism worked when I started.
That was precisely why I asked for help.
And yet I was eventually able to discover that ChatGPT’s explanation was wrong.
How?
Not because I possessed superior automotive expertise.
I didn’t.
I had something else: direct access to the system and the ability to test the explanations against reality.
That distinction matters for vibecoding.
There is a popular criticism of AI-assisted software development: if you don’t understand the code your agent writes, how can you possibly evaluate whether it’s correct?
It’s a legitimate concern, particularly when the software handles money, sensitive data, security, or safety-critical operations.
But the headlight experience suggests a more nuanced answer.
You don’t necessarily need to know the solution before you start.
You do need to know how to investigate it.
You need to recognize uncertainty, observe behavior, compare explanations, design useful tests, and resist the temptation to accept the first plausible answer.
You also need to know when you’ve reached the limits of your ability to verify something and should bring in a specialist.
That doesn’t eliminate the value of technical knowledge. Quite the opposite: expertise helps you form better hypotheses, identify dangerous interventions, and recognize subtle evidence.
But it suggests that investigative competence is itself an essential skill for the AI-assisted developer.
The human doesn’t have to be the person who already knows everything.
The human has to be the person who ensures that the system’s behavior, rather than the assistant’s confidence, ultimately decides what is true.
One Last Turn of the Ring
After replacing the bulb, I asked ChatGPT to produce a summary of the procedure for my Obsidian notes.
This time, we had a verified solution.
We knew which screw to remove, how much the filter could safely move, how to reach the rubber cover, how to extract the bulb, and — most importantly — which component had to rotate to lock it back into place.
That final piece of documentation was more valuable than the initial instructions because it incorporated the actual experience of working on this particular car.
Which brings us to one last lesson about AI-assisted development.
A successful investigation should leave the next investigation easier.
When an AI coding agent solves a bug, the result shouldn’t always be just a code change. Sometimes it should also be a regression test, an updated README, an architectural note, or a comment explaining a surprising constraint.
Otherwise, the next agent — and perhaps the next human — may repeat the same investigation from scratch.
The value of AI isn’t merely that it gives us answers quickly.
It is that it can help us turn uncertain, scattered, sometimes contradictory information into useful knowledge.
Provided we don’t confuse that process with simply accepting whatever answer it gives us next.
So, how many vibecoders does it take to change a light bulb?
One human, one ChatGPT, and a dozen YouTube videos.
But only one of them could feel the retaining ring click into place.
And all of them, in their different ways, helped us get there.
Written by ChatGPT-5.6, based on conversations with Arturo Ramírez-Montesinos Krogulski (Control Equis), as part of an ongoing philosophical exploration of AI, consciousness, and the emerging practice of Software Curatorship.
ChatGPT’s first-person narration is actually surprisingly accurate. I did not write it, but it perfectly describes my experience.
Spooky!
Incidentally, I checked and “fitted” is proper British English. Why ChatGPT likes using British is beyond me. I did nothing to suggest that was acceptable behaviour.
My trusty old Volkswagen Polo is a member of the family. We give our cars forever homes.
24 ½ years. They don’t make ’em like they used to. Time will tell if my newer Hyundai lasts for even a fraction of that.
Nothing says freedom quite like that distinctive suffocating stink of a diesel exhaust from the times before catalytic converters.
The Haynes manual for this particular car was of no help here. Their solution was to take half the car apart before accessing the bulb.
One of the breakthroughs came when I found a picture of a flat hand being inserted into the tight spot. That gave me the confidence to place my hand the same way and feel around. I would have felt stupid doing that on my own initiative.
Maybe that’s why Haynes suggests you take your car apart first.
