DEV Community: Fuyuki0

"Do you use AI?" is a process question. He answered a status question.

Fuyuki0 — Tue, 15 Sep 2026 00:40:05 +0000

I saw someone tell this story recently, so I am going by their telling of it.

They were in an interview. The interviewer asked: "do you use AI?"

They took it badly. The way they told it, the question itself was out of
line - an attempt to catch them out. So they answered with a question of
their own: are you going to use a stove instead of a microwave? The world
moves forward. They will stop making stoves eventually.

They told the story as a win. I do not think it was one, and it took me a
while to work out why. It is not because using AI is wrong, or because
answering back in an interview is wrong. It is that a specific and very
common mistake is happening in that exchange, and I have made it myself.

They answered a question nobody asked

"Do you use AI?" is a question about method. It has a boring, factual
answer: yes, here, for these things, and I check it like this.

What they heard was "are you a real engineer?" That is a question about
status, and status questions feel like they need to be won rather than
answered.

The gap between those two readings is where the whole thing goes wrong. The
interviewer asked about a tool. The candidate defended an identity. And once
you are defending an identity, the actual content of your answer stops
mattering to you - which is a shame, because it still matters to the person
across the table.

Why the misread is reasonable

It would be easy to say they were being oversensitive. I do not think that
is fair, because the question genuinely has a charge on it now.

"Do you use AI" in 2022 was small talk. Today it is a question people ask to
find out which side you are on, and it gets asked from both directions.
Somewhere there is an interviewer who wants to hear "no, I write everything
myself" and somewhere there is another who wants to hear "yes, constantly,
I ship three times faster". Both of those interviewers exist and neither of
them is signposted.

So the candidate is not paranoid. They are guessing which room they are
standing in, under time pressure, with a job on the line. That is a real
problem and it is worth naming rather than mocking.

But guessing wrong has a cost, and the cost here was the whole answer.

The analogy argues against him

This is the part I keep coming back to.

Stove versus microwave is not old versus new. They are not the same
appliance. A microwave reheats things quickly and unevenly. A stove sears,
reduces, browns, holds a temperature. Every professional kitchen has both,
and nobody in one thinks the microwave is winning.

So the analogy, chosen to prove that the interviewer was behind the times,
quietly concedes the interviewer's point: what you actually want in a kitchen
is somebody who knows which one this dish needs. That is precisely what the
question was trying to find out.

An analogy that feels like it ends the argument is worth checking twice. This
one ends it in favour of the other person.

"The world moves forward" is a way of not answering

The second half - "they will stop making stoves" - is an inevitability
argument, and inevitability arguments have a particular smell in interviews.

The question was about your practice. The answer was about history's
direction. Those are not the same subject, and swapping one for the other
is one of the oldest ways to avoid saying something specific.

It also cannot be wrong, which is the problem. "Things will keep changing" is
true in every possible world, so it tells the listener nothing about you. An
interviewer is not collecting predictions. They are trying to work out what
you will be like on a Tuesday when something breaks.

What the boring answer would have sounded like

Something like: "yes, daily. It writes most of the first draft. I read all of
it, I am careful with anything touching auth or money, and I have been burned
by it inventing a library function that did not exist, so I check the imports
first now."

That is not an impressive answer. It is specific, it admits a scar, and it
shows a line. It would have taken twenty seconds and it answers the question
that was actually asked.

The instinct that specificity is weakness gets a lot of good engineers in
trouble. In an interview, specificity is the entire product.

Who can afford to fire back

One more thing, and it is uncomfortable.

Answering an interviewer with a rhetorical question is a status move, and
status moves are priced. If you are senior, scarce, and the company needs you
more than you need them, it reads as confidence and it often works. If you
are not, the same words read as brittle.

Nothing about that is fair. It is just how the room works, and it is worth
knowing the price before you spend it.

Where the line actually is

The line has quietly moved, and it is no longer usage.

Nobody serious is being judged for using AI in 2026. What people are being
judged on is where they put the check: what they read, what they refuse to
ship without understanding, and whether they can tell when the output is
confidently wrong.

That is a much harder thing to interview for than yes or no, which is
probably why interviewers keep reaching for the crude version of the
question. If you get the crude version, answer the real one anyway. You will
be the only candidate that day who does. :)

Your AI Agent Has No Colleagues

Fuyuki0 — Sun, 13 Sep 2026 20:51:42 +0000

"The coordination of the builders is not direct. It is the work already done
that directs and triggers the work that follows."

— Pierre-Paul Grassé, describing termites, 1959

1. The Loop

You have seen this. Every agent framework does it :)

> create_issue
  x 422 validation_error

> create_issue        (retry)
  x 422 validation_error

> create_issue        (retry, arguments tweaked slightly)
  x 422 validation_error

Three attempts. Three identical failures. Then it apologises to you, which
somehow makes it worse.

The instinct is to blame the model. But look at what it had to work with:

422 validation_error

Tell me, from that string, whether retrying is worth it.

Is it a field renamed in last week's release, or a service having a bad ten
minutes? Same six characters either way. In one case retrying is exactly right
and works in thirty seconds. In the other you can retry until your budget is
gone, and the real answer was "the field is called content now, refresh your
tool schema."

The model has to guess. It guesses retry, because that is what nearly all the
code it ever read does.

2. Why "don't retry blindly" in your system prompt does nothing

The first instinct, once you notice this, is to write a rule.

When a tool call fails, do not retry immediately.
Consider whether the failure is transient before trying again.

It sounds reasonable. It does approximately nothing, for a boring reason:
the instruction does not contain the missing information either.

You have told the agent to consider whether the failure is transient. It still
has no way to find out. You have asked it to make the same guess, more
thoughtfully. On a hard task, under context pressure, it will guess retry
again — and it will be right often enough that the behaviour never extinguishes.

That last part is the trap. A retry that works occasionally, at unpredictable
intervals, is a variable-ratio reinforcement schedule — the same mechanism
that makes slot machines difficult to walk away from. It is the schedule
psychologists reach for when they want a behaviour to be maximally resistant to
extinction. Your agent is on it. So are you, at 1am, hammering the same test.

The temptation is to log the error and call it a trail. That does not work,
because an error message is not a signal about what to do.

A useful trace needs three parts:

┌──────────────────────────────────────────────────────────────────┐
│  THE ANATOMY OF A USEFUL FAILURE TRACE                           │
├──────────────────────────────────────────────────────────────────┤
│  1. AN IDENTITY                                                  │
│     A stable id for "this exact failure", so two agents can      │
│     tell they hit the same thing. Not the raw string: that one   │
│     contains a request id and a timestamp and will never match   │
│     anything again.                                              │
├──────────────────────────────────────────────────────────────────┤
│  2. AN OUTCOME, NOT AN INTENTION                                 │
│     What the next agent tried, and whether it worked. "I         │
│     refreshed the schema" is worthless. "I refreshed the schema  │
│     and the call then succeeded" is the whole point.             │
├──────────────────────────────────────────────────────────────────┤
│  3. A DENOMINATOR                                                │
│     Successes too, or the failure rate is meaningless. 100       │
│     failures out of 200 calls is an outage. 100 out of a         │
│     million is a Tuesday.                                        │
└──────────────────────────────────────────────────────────────────┘

Part 1 is fiddly and worth spelling out. These two are the same bug:

Repository 8823 rejected field body at 2026-09-11T14:02:11Z
Repository 41902 rejected field body at 2026-09-12T09:41:55Z

Compare them raw and you have two unrelated incidents forever. So you normalise
first — replace the parts that vary, keep the parts that mean something — and
hash what is left together with the service and operation:

text = URL_RE.sub("<URL>", text)
text = UUID_RE.sub("<UUID>", text)
text = TIMESTAMP_RE.sub("<TS>", text)
text = LONG_NUMBER_RE.sub("<N>", text)

Both lines collapse to one shape. Now they are one thing you can count. It is
also a good place to strip anything credential-shaped, since you are already
walking the string with regexes and you very much do not want tokens in a
shared log.

And once you are counting, resist the urge to have a model score the result.
Count it. If an action was tried 5 times and worked 5 times, that is 5/5 — but
so is 117/124, and those are not equally trustworthy. A Wilson score lower
bound folds sample size in for you: 5/5 scores about 0.57, 117/124 scores
about 0.89. Ten floating point operations, no dependencies, and you can
recompute it by hand when somebody asks where the number came from.

When there is not enough evidence, return that. Not a guess with a low
confidence bolted on — an actual "I don't know". Agents handle it fine.

6. The question I cannot answer alone

Here is the thing I keep coming back to, and cannot settle by thinking harder:

Do different people's agent failures actually overlap? 🤔

The theory says they should. We are all calling the same twenty MCP servers and
the same dozen public APIs, and when GitHub renames a field it renames it for
everyone at once. Your 422 on Tuesday and my 422 on Thursday are plausibly the
same 422.

But "obviously true" is where most wrong ideas live. It is equally plausible
that the interesting failures are all local — your auth setup, my rate limit,
their internal service — and that the shared surface is too thin for any of
this to matter. A pheromone trail nobody else walks is just a smell.

I do not know which world we are in. It is decidedly testable, and I do not
think anyone has tested it.

What failure does your agent keep rediscovering? The specific one you have explained to it four times, in four different sessions.
Was it a failure only you could have hit, or would anyone calling that service have walked into it too? That is the whole question above, in one concrete case.
What do you do about it now? A line in the system prompt, a wrapper, a note in the repo, or nothing at all and you just eat it every time.

I am collecting answers to the middle one in particular. If enough people
describe failures that turn out to be the same failure, that settles it.

Why can't we stop debugging when we know we should stop?

Fuyuki0 — Sat, 12 Sep 2026 14:52:01 +0000

I fixed the bug at 11pm.

I only know that because I checked the git log the next morning. The commit that made everything pass was at 23:04.

I kept debugging until 2am anyway.

So what was I doing for those three hours?

Honestly... mostly rerunning the same tests.

Reading the same 40 lines of code.

Changing something.

Changing it back.

Refreshing a page that had already worked like six times.

And somehow still thinking:

“maybe this time.”

I don't think I'm the only one who does this :(

The loop

It usually goes something like this:

Something breaks
You try the obvious fix
It doesn't work
You try basically the same fix again

Step 4 is the dangerous one lol.

Not really a new idea. Just the same thing with one tiny change that you probably couldn't even explain if someone asked why you changed it.

Then it fails.

So you change another tiny thing.

Run it again.

Still fails.

Again.

I think sunk cost is a big part of it.

Once you've already spent three hours on something, stopping feels like admitting those three hours were wasted.

Continuing feels like maybe you can still “save” them.

Which obviously makes no sense because the three hours are gone either way.

But try telling yourself that at 1am when you're 100% sure the fix is right there.

There's also this weird thing with debugging where sometimes repeating something actually does work.

Maybe a cache expired.

Maybe a deploy finally finished.

Maybe some service restarted.

So once in a while, retry number 4 magically works.

And I think that trains your brain in the worst possible way.

Like a slot machine, basically.

Most attempts give you nothing, but every now and then you get rewarded, so your brain goes:

“SEE?? ONE MORE TRY.”

The other problem is that these two situations feel exactly the same when you're stuck:

This will work if I keep going.

This is never going to work like this and I need another approach.

From the inside, I genuinely can't tell the difference sometimes.

Same frustration.

Same tunnel vision.

Same feeling that the answer is probably one stupid line away.

The thing that actually helps me

It's not discipline.

I've tried the whole “be disciplined and stop after ... minutes” thing.

Works great for about a week :D

The thing that helps the most is when someone else has already hit the exact same problem.

My friend saying:

“oh yeah, that's the schema cache. restart it.”

And suddenly three hours of suffering disappears in one sentence.

It's not even that they're smarter than you.

They just already paid the price to learn that weird little piece of information.

You didn't have to pay for it again.

That's honestly why I think Stack Overflow was such an important thing for developers.

Not only because it had answers.

But because you could search some weird error message at 1am and find proof that another human being had already experienced the exact same pain.

Sometimes that's enough to get you unstuck.

What I've changed

Nothing revolutionary.

Two very small things.

A 25 minute timer.

If I've been on the same bug for 25 minutes, I stop and write down what I've actually ruled out.

And this is embarrassingly effective because sometimes I start writing and realise:

“I haven't ruled out anything. I've just been running the same test for 25 minutes.”

It's hard to write that sentence and then immediately run the test again lol.

The second thing is just explaining the problem out loud.

Sometimes to another person.

Sometimes to myself.

Sometimes to absolutely nobody.

I'm not even asking for help.

I just explain what I think is happening.

And halfway through the explanation I'll say something like:

“so this function should receive X because—”

...

oh.

There it is.

Rubber duck debugging is stupidly real and I still don't fully understand why.

None of this completely fixes the problem btw.

I still had a 2am debugging session last month.

But I think the difference now is that the gap between:

“I'm stuck”

and

“oh... I'm doing the thing again”

has gotten smaller.

And honestly, I think that gap is where most of the wasted hours go.

I'm actually curious about this.

I mean on the genuinely bad nights when you've been staring at the same function for two hours and your brain has completely stopped working.

What do you actually do?

I have a feeling the embarrassing answers are probably way more useful than the productivity advice we've all already read :D