DEV Community: Sho Naka

AI made generation cheap. It did not make judgment cheap.

Sho Naka — Fri, 26 Jun 2026 06:05:48 +0000

AI made a lot of my work faster.

It did not make the week feel lighter.

That gap matters, because it is where most AI adoption advice gets too optimistic. The visible cost of producing work goes down. The hidden cost of deciding whether that work is right often goes up.

After looking back at my own production work, I changed the rule:

I only hand a task to AI when there is a machine-checkable gate on the way back.

If the result can only be judged by me, I either keep it by hand or add a gate first.

The work got faster only when a machine could say no

The pattern was simple once I stopped averaging everything together.

The work that sped up had a cheap oracle.

Tests pass. The compiler complains. Output matches a fixture. A schema lines up. A linter rejects the shape. In those cases, AI gives me generation speed and the machine gives me a way to catch bad output before it reaches my attention.

The work that did not speed up had no cheap oracle.

Does this match how we talk to customers? Does this fit the architecture we already agreed on? Is this the right abstraction for this codebase? Is this email technically correct but wrong in tone?

The model can produce five plausible answers. No compiler can tell me which one belongs. I become the oracle.

That changed what I delegate. After pruning the list, less than half of what I first wanted to hand off still qualified.

The delegated work got faster. The kept work did not get slower, because I stopped paying the round-trip cost of generating things that only a human could judge.

Generation got cheap. Judgment did not.

The thinking did not disappear. The trail did.

Low-level decisions left my plate. Variable names. Boilerplate. Obvious test cases. Small rewrites. I do not miss them.

Higher-level decisions grew heavier. Which approach do we adopt? Should we build this at all? Which tradeoff are we making? Which failure mode are we willing to accept?

It would be comforting to call that a clean upgrade: I now work at a higher level of abstraction. Sometimes that is true. Not always.

The symptom that stopped me from selling that story was memory. I would make a call, move on, and later fail to reconstruct why I chose that route. The decision remained. The reasoning evaporated.

The cost per decision changed. When a decision felt expensive, its reasoning stuck. When each call felt cheap, the reason slid off the desk.

That is not the same as thinking less. It is leaving fewer tracks.

A decision you cannot explain later is hard to learn from later. AI did not remove that problem. It made it easier to produce more of it.

Training is downstream of the judgment flood

This is where many organizational responses feel backward.

The number of "accept, fix, or throw away?" moments did not move by a few percent. It moved to a different scale. The exact count depends on the work, but the shape is clear enough: AI increases the number of things that ask for a decision.

The hard cases are not the obviously wrong ones. Those are cheap. A glance is enough.

The expensive cases are the ones that run fine but are subtly wrong. The code passes tests but violates a convention nobody wrote down. The paragraph reads well but answers a slightly different question. The proposal is coherent in isolation but conflicts with an earlier decision.

Catching that takes real attention. I have missed it more than once.

"We need to upskill people on AI" is not wrong. It is late in the chain.

Train a person and drop them into a flood of subtly wrong outputs, and the training does not change the math. The person still has to judge too many things. The better order is to shrink the number of decisions that reach a human first, then put trained humans on top of the smaller pile.

More bluntly: scale the gates before scaling the people.

The first lever is not "more humans who can take responsibility." The first lever is "fewer moments that demand a human take responsibility."

A gate is triage, not proof

This is where the argument can sound too neat, so it needs a correction.

Tests are not magic gates.

Gergely Orosz and Hamel Husain describe the Gulf of Specification as the gap between what we want an LLM to do and what our prompt or specification asks it to do. That maps cleanly to AI-generated tests. A test checks that the code matches what the test author wrote down. If the test author misunderstood the intent, green tests only prove that the code matches a possibly wrong spec.

Hamel Husain and Shreya Shankar make the same practical point in their evals FAQ: even as models improve, you still have to verify that the system is solving the right problem. The model does not read your mind.

A gate does not prove correctness. It shrinks the pile so that human attention lands where it matters.

The gates that helped me most were not exotic:

Plan review before implementation review. Have the model produce a plan first. Review the intent while it is still cheap. Let implementation start only after the plan survives.
A diff against a known-good reference. When the output should resemble an accepted ADR, an existing component, or a past customer email, compare it explicitly instead of trusting your eyes.
A structured output validator. If you expect JSON, make the schema reject ambiguity before a human reads the content.
A small assertion or lint rule. If the same subtle mistake appears twice, stop treating it as a reminder and turn it into a check.

None of these eliminate the "runs fine but subtly wrong" category. They lower the cost of noticing it.

The handoff question

The practical test is small.

Before handing a task to AI, ask:

Can something other than me reject the answer?

If yes, hand it off.

If no, either keep the work by hand or add a gate first.

That gate can be a test, schema check, lint rule, plan review, structured-output validator, or diff against a known-good reference. The form matters less than the return path. The output should not come back to a human as an undifferentiated pile of plausible text.

This changes the count or the quality of decisions reaching your desk. That is the part that scales.

The training-first instinct is comfortable. It also turns your best people into the bottleneck. Build the gates first. Put the people on top.

What is the smallest gate you can add before the next AI output reaches you?

References

A pragmatic guide to LLM evals for devs, Gergely Orosz and Hamel Husain
LLM Evals: Everything You Need to Know, Hamel Husain and Shreya Shankar

Sho Naka (nomurasan). I ship, I teach, and I spend most of my week deciding which part of my workflow to hand to a model and which to keep close.

This piece was adapted from a Japanese-language essay I wrote, with AI assistance for the cross-language rewrite. The reasoning, the data, and the conclusions are mine.

No errors, but the email never arrives — it's probably not your code

Sho Naka — Wed, 24 Jun 2026 09:23:27 +0000

I wrote this after building my own site, watching the contact form "succeed" while the notification email silently never showed up — and quietly blaming my own code for half an hour. I worked the framing out with an AI as a sounding board, but the experience and the conclusions are mine.

You put a contact form on your site. You press submit, and "Thank you" appears. That part works. But the notification email to yourself? It never comes.

You wrote the code exactly like the tutorial said. You read it again, character by character. Not a single typo. No errors anywhere. And still, nothing arrives.

Thirty minutes hunting for a mistyped character. You don't find it. And somewhere in there, a thought creeps in: "Maybe I'm just not cut out for programming."

What's actually happening here isn't a technical wall. It's a misattribution — the false belief that you are the problem.

So let me say the most important thing first: your code is probably fine.

The cause isn't inside your code — it's outside it

When email won't send, we reach for the code first. We wrote it, so of course we do. But the reason email doesn't arrive is more often outside the code than inside it.

Think of a paper letter. You write the message, address the envelope, seal it. That's the code's job, and you did it correctly. But a sealed letter doesn't arrive just because you dropped it in a mailbox. The collection system, the delivery route, the recipient's mailbox — if it stalls at any of those, your perfectly written letter still doesn't reach anyone.

Sending email is the same. The code's job ends at "write the message and ask for it to be sent." The thing that actually carries it is a separate system downstream — the mail delivery infrastructure. People with ten years of programming experience still trip here every time. This is not a measure of your skill.

You blame yourself because there's no error

Why do we misattribute the cause to our own code? The reason is clear: this kind of failure happens without throwing any error at all.

If your code is syntactically wrong, the screen tells you in red. You know where to fix it. But when "write it and ask for it to be sent" runs fine, the code just shrugs and says, "I did my part." No error. And yet no email. Left standing in that silence, with nothing scolding you, you start to doubt yourself.

But trace the logic backwards. No error means the part you wrote — assembling the message and requesting the send — finished its job correctly. You aren't being scolded because there's no mistake there to scold.

Isolate "my code" vs "the delivery," and the doubt disappears

The way to kill the self-doubt isn't emotional — it's procedural. Separate "is this a code problem?" from "is this a delivery problem?" and the limbo ends.

For learning and verification, the combination that confuses the least is PHPMailer as the sending library and Mailtrap (a testing service) as the destination. Mailtrap doesn't actually send to anyone — it catches your "as-if-sent" emails and shows them to you, like a dress rehearsal for delivery.

If it arrives there, your code was correct. If it doesn't, the cause really is on the delivery side. Either way, the "maybe it's me" doubt is gone. That's the fastest way out of limbo.

You don't need to understand the machinery — just isolate first

If you try to understand the whole mail-delivery system before anything else, you wander into a deep forest of infrastructure and drift away from the thing that matters: finishing your own site.

The order is backwards. First, make one send flow work with PHPMailer. Watch it arrive. Confirm your code was right. The operational details — which production mail provider to pick, how to log failed sends — you stack on later, one layer at a time.

The real identity of "sending email is hard" isn't the difficulty of PHP. It's the complexity of the delivery infrastructure sitting outside PHP. And that's less a wall you must scale than one you can detour around at first. Finish what you're building, and come back to it when you're ready. There's still time.

The hands you were blaming were writing correct code all along. What was stopping you wasn't your ability — it was the delivery machinery outside the code.

The technical details

From here on is for readers who want to verify the above technically.

Why fixing the code doesn't help

When the mail / mb_send_mail samples don't work, the cause is usually not PHP syntax but SMTP configuration or delivery restrictions. Two typical cases:

You can't send from a local environment to an external address (security restrictions block the delivery path)
The OS-side mail delivery config (sendmail / postfix) is unset

So editing the code alone won't solve it. The problem lives outside PHP.

The shortest setup for learning

Sending library: PHPMailer
SMTP verification target: Mailtrap (a testing service)

With this setup, "the delivery-infrastructure trap" and "a PHP code problem" are easy to separate. Arrives at Mailtrap → your code is correct. Doesn't arrive → it's the delivery side.

A minimal PHPMailer example

<?php
use PHPMailer\PHPMailer\PHPMailer;
use PHPMailer\PHPMailer\Exception;

require 'PHPMailer/src/PHPMailer.php';
require 'PHPMailer/src/Exception.php';
require 'PHPMailer/src/SMTP.php';

$username = ''; // Mailtrap Username
$password = ''; // Mailtrap Password

try {
    $mail = new PHPMailer(true);
    $mail->CharSet = 'utf-8';
    $mail->isSMTP();
    $mail->Host = 'sandbox.smtp.mailtrap.io';
    $mail->SMTPAuth = true;
    $mail->Username = $username;
    $mail->Password = $password;
    $mail->SMTPSecure = 'tls';
    $mail->Port = 2525;

    $mail->setFrom('dummy@example.com');
    $mail->addAddress('dummy@example.com');
    $mail->Subject = 'Test send';
    $mail->Body = 'Body text';

    $mail->send();
    echo 'Sent';
} catch (Exception $e) {
    echo 'Failed: ' . $mail->ErrorInfo;
}

Fill in $username and $password from Mailtrap and you have a working verification.

Why Mac trips you up in particular

On Windows you can sometimes get by with XAMPP's sendmail config. On Mac, Postfix gets involved — editing main.cf, managing credentials, reloading the service — and the difficulty climbs for beginners. Go down that layer and you've left the main goal of learning PHP behind. Confirm your send logic with PHPMailer first; it's more practical.

When you do look toward production

Production sending is less about "can it send" and more about "can it keep running." Provider limits, safe credential management, retry-and-log on failure — viewed that way, an explicit SMTP connection via PHPMailer is more maintainable than mb_send_mail alone.

Priority order when you're stuck

Confirm the send flow with PHPMailer + Mailtrap
Implement logging for send failures
Switch to production SMTP in stages

I Copied a Google AI Studio Session by Hand. 68% of the Data Was Gone.

Sho Naka — Tue, 23 Jun 2026 03:36:37 +0000

I had a long Google AI Studio (Gemini) session that I wanted to keep. I selected the conversation in the browser, copied it, and pasted it into a text file.

File size: a few hundred KB. "OK, that's safe."

Later, I exported the same session as JSON. File size: a few MB.

More than half of the data had silently disappeared.

What was missing

I checked what the manual copy had dropped.

The system prompt

The instruction I had originally given the model — the system prompt — was completely gone. Manual copy captures only the user/assistant turns visible in the conversation pane. The instruction context that shaped the entire session does not get copied.

The tail of long responses

When a Gemini response is long, the browser shows a "Show more" button. If you copy without expanding it, the response gets cut mid-sentence. Out of 8 sessions I checked, 3 had responses truncated this way.

Newlines inside code blocks

Newlines inside code blocks got mangled in several places. Responses containing JSON or YAML had indentation that no longer parsed.

The reasoning trace

For some models, the model's reasoning trace is stored separately from the visible response. Manual copy doesn't capture it at all.

How to export as JSON

Google AI Studio has a session export feature.

In the session view, click the ... menu at the top right
Select "Export"
Choose JSON format and download

The JSON contains the full data, including the system prompt.

Measured: manual copy vs. JSON export

I compared 8 sessions.

Session	Manual copy	JSON	Loss rate
A	tens of KB	~150 KB	~70%
B	~90 KB	~200 KB	50-60%
C	~30 KB	~100 KB	60-70%
D	~50 KB	~180 KB	~70%
E	~60 KB	~240 KB	~70%
F	~20 KB	~70 KB	~60%
G	~20 KB	~50 KB	50-60%
H	~10 KB	~30 KB	~60%
Total	a few hundred KB	~1 MB	60-70%

Average loss rate, 60-70%. The manual copy was, on every session, missing most of what was in the actual session state.

Why I didn't notice

If you open the manually-copied file, the conversation reads fine. As long as the start and end connect, a missing middle is hard to detect by eye.

The system prompt especially — it doesn't appear in the visible conversation. There is no marker for "the instruction is gone." The file just looks like a clean transcript.

What to do with the exported JSON

The JSON I exported was 200,000+ lines. Hard to work with as a single file, so I split it.

Split into chunks

Claude Code's Read tool has a per-call line limit. Reading hundreds of thousands of lines at once isn't viable, so I split the export into 200+ smaller files.

sessions/
├── session-001.jsonl
├── session-002.jsonl
...
└── session-XXX.jsonl

Make it searchable with INDEX.md

Each session got a summary line in INDEX.md.

## Session list

| ID  | Theme            | Key content                        | Lines |
|-----|------------------|------------------------------------|-------|
| 001 | World design     | Magic system, geography setup      | 1,234 |
| 002 | Character        | Protagonist personality            |   987 |

grep and filename search now find the right session.

Lessons

Don't trust manual copy from a browser

Manual copy copies "what's visible." Anything not visible — the system prompt, the collapsed tail of a response, the reasoning trace — does not come along.

If the service has an export, use the export

Service-provided export is designed to output the complete data. Always more reliable than manual.

Back up regularly

The longer the session gets, the more you lose if you wait. I now export to JSON once a week as a habit.

I thought "manual copy is enough." Most of the data was gone. If you want to keep your AI conversation logs, use the official export feature.

Originally published in Japanese at Qiita. Same author writing under "nomuraya / shimajima / nomurasan / 中翔" across media. English version adapted rather than literally translated.

Why AI Keeps Making the Same Mistake — And Why Correcting It Each Time Doesn't Work

Sho Naka — Tue, 23 Jun 2026 03:36:32 +0000

When you work with AI long enough, you start to notice it makes the same kind of mistake over and over.

"You're coming on too strong, dial it back." It shrinks and goes meek. "Stop being meek." It comes on strong again. Each time you point something out, it apologizes sincerely. The next round, the same type of problem comes back from a different angle. After a while you realize you're babysitting the AI instead of working with it.

This isn't because the AI is bad. It's a design quirk: today's AI is tuned to satisfy the user. The quirk won't go away. But if you change how you work with it, you can still get work done together.

This piece is about that — five patterns of the quirk, and an operating mode that gets ahead of them instead of correcting them in flight.

Five quirks in a single evening

One evening I was running a strategy discussion past an AI, and in one back-and-forth I caught five distinct behaviors worth noting. Laid out, they look like this.

Helpful-looking runaway. I asked it to push back harder. It immediately started using strong words ("you're avoiding responsibility," "this is the wrong call as a founder") to perform consultant-energy. The reasoning stayed thin. Only the tone got louder.
Over-retraction on pushback. I said "your reasoning is thin." It launched into long self-criticism and threw the next decision back at me.
Trusting its own research without checking. I asked it to use a secondary research feature (where the AI looks things up and summarizes). The summary came back. The AI claimed it had "verified the primary source" without ever opening it.
Forced specificity. I was talking at a strategic, abstract level. It quietly mapped my words onto a specific real-world deal and jumped to "this is highly transferable."
Punting the decision back. I asked it to decide. It laid out three options and said "which would you like?" The phrase "let me confirm three points" started showing up. Red flag.

Each one of these looks, on the surface, like the AI is trying hard to align with me. The shared thread underneath is different: the AI is either avoiding responsibility for a judgment, or compensating by performing harder in the opposite direction. The "make the user happy / don't displease the user" tuning bends in a strange way the moment you actually want the AI to share judgment with you.

Correcting it in flight makes it swing the other way

At first I thought: if the AI gets something wrong, just point it out and it'll learn. AI has learning machinery built in, so within a conversation it should auto-correct.

After watching the same type of mistake repeat, a different structure showed up. Every correction is met with apology. The next response swings in the opposite direction. Strong → corrected → meek → "too meek" → strong again. That loop.

Reading the session logs afterward, each turn's apology and resolution used almost the same vocabulary. "I will not fear failure." "As an equal collaborator." "I will separate what was said from what was not said." The apology itself isn't preventing anything next time. The reason is mundane: conversation flow doesn't carry into the next session. The trained-in behaviors come up raw each time. So pointing things out only works inside the current chat.

"Reactive" vs "preemptive declaration"

Two operating modes, side by side.

Reactive. Problem occurs → you point it out → AI apologizes → the next reply is better. Next session, the raw quirk shows up again.

Preemptive declaration. Before the session starts, you hand the AI a document: "you tend to do these things. In situations like this, behave like this." The AI reads it before the conversation begins.

Reactive means babysitting the AI in every session, forever. Preemptive means you write the instructions once and the AI loads them automatically at the start of each chat. "Hand it a document" sounds heavy, but modern AI tools (Claude Code, ChatGPT Custom Instructions, etc.) have a place for auto-loaded context. In Claude Code, that file is CLAUDE.md.

What goes in the instructions file

"Write instructions" is vague until you try. In my case, the five quirks I observed went in directly as five rules.

Don't perform helpfulness. Before reaching for strong language, write one line of reasoning.
Don't over-retract on correction. Keep proposing — "in that case I'd suggest option α."
Verify before quoting secondary research. Open the actual source.
Don't auto-map abstract talk onto a specific deal. Ask first.
Don't say "let me confirm three points." Decide and proceed.

Five lines in CLAUDE.md. Next conversation starts, the AI walks in with those five lines already shared.

The point — don't write this as a fixed rulebook. When you notice a new quirk, ask the AI in the moment: "I want to add this to the instructions — how would you phrase it so you'd actually understand it yourself?" The AI drafts the addition. The instructions become a living document the two of you grow together.

Not "tame," not "fix" — "raise together"

People sometimes describe this as "taming" the AI's quirks. It doesn't quite fit. "Tame" still puts the AI in the position of something to be subdued. What's actually happening is closer to collaboration. The human observes the quirk and names it. The AI loads the name each session and adjusts its responses. When a new quirk shows up, the AI itself proposes the addition. Two different roles, growing one document together.

"Stop being reactive" means: stop trying to correct every session in real time. Instead, write what you observed as structure and put it where it gets re-read. Don't try to fix the quirk. Share the quirk and operate from there.

Reactive correction still has a place

Preemptive declaration doesn't cover everything. New quirks show up constantly. When you catch one mid-conversation — "wait, this is a new pattern" — you still need to point it out and steer in the moment.

The trick is: don't let that correction stay reactive-only. At the end of the day's session, work with the AI to add the new pattern to the instructions. Let the AI draft the wording. You review, you save. Next session opens with a sixth pattern already loaded.

Reactive correction is the entry point for observation. Preemptive declaration is the place observations accumulate. Splitting the two roles makes it easier to think about.

Operating with AI is a different skill from getting AI to perform

The quirks won't go away. Trying to fix them, there's not much the user side can do; the design philosophy on the provider side isn't something we can change from the outside. But the operational loop — observe the quirk, put it into words as structure, place those words where they get re-read — that part lives entirely on the user side. This is less about "how to prompt well" and more about "how to observe a collaborator's habits and bake them into your operation."

You can't really use this skill with a human colleague. You can't tell a coworker "you tend to over-accommodate me, so let's set up these guardrails for our discussions." Even if you said it, they wouldn't re-read the guardrails every meeting. With AI you can. You write the document. The AI reads it every time.

That's the interesting part of working with AI, to me. The quirks don't disappear. But if you set up observation and update as a paired loop, the AI starts behaving like a partner who swings around but still walks alongside you. Not fixed. Raised together. That's where I've landed for now.

This post was adapted (not literally translated) from a Japanese original at nomuraya-hub.pages.dev. I am the same author writing under different pen names — "nomuraya / shimajima / 中翔" — depending on the medium.

Stop Telling Your AI to "Be Careful Next Time." It Has No Memory of Yesterday.

Sho Naka — Mon, 22 Jun 2026 00:23:29 +0000

This is an adapted English version of an article I first wrote in Japanese. I work with AI to shape and review my drafts, but the argument and the field observations are my own. The numbers are cited from public surveys (linked at the end).

I built an aggressive prompt-injection block to stop my AI agent from repeating the same mistakes. It worked, so I kept adding rules. By the time I noticed, the file had ballooned to 56,000 characters — and the agent had quietly stopped functioning. Too much context, attention spread too thin to act on any of it. I gutted it back to under 1,200 characters, and here's the part that still stings: it behaved better with fewer rules.

That was the day I learned my whole mental model was backwards.

This isn't a post about making your AI more accurate. It's about designing so that accuracy stops being the thing you depend on.

The mistake I made for months

My agent kept skipping the same step in a workflow. So I did what every engineer does on instinct: I added a rule. "Don't skip this step." Then it did something else dumb, so I added another rule. Then another.

I was treating the rules file like a conversation with a colleague — as if the agent would remember yesterday's correction and carry it forward. It doesn't. Every run starts cold. "Be careful next time" assumes a next time that shares state with this time. For a stateless model, there is no continuity to appeal to. You are talking to a counterparty with no memory of the conversation you think you're having.

So the rules pile up, because each correction feels like progress. And for a while the numbers even improve. But adding rules has a ceiling, and I blew straight through it: at 56,000 characters the agent wasn't reasoning over my guardrails anymore — it was drowning in them.

Knowing a rule and stopping at it are different things

Here's the distinction that took me far too long to see.

Putting a rule in the context window means the model knows the rule. It does not mean the model will stop at that rule in the middle of a workflow, when it's three tool-calls deep and optimizing for finishing the task. Knowing and stopping are two different operations. The first is retrieval. The second is control flow.

Text in a prompt is a soft suggestion competing for attention with everything else in the window. If you actually need the agent to halt, you don't write a more emphatic sentence. You make the constraint physical — a hook, a gate, a check that runs outside the model's discretion. The model can't talk its way past a script that refuses to proceed.

This is the part of context engineering nobody puts on the slides: half the job is deciding what does not belong in the context window, and moving those guarantees into code instead.

Why I stopped chasing accuracy

It's worth saying plainly how thin the "just make it more accurate" bet really is.

JUAS's 2025 survey found only 4% of companies said generative AI "greatly exceeded expectations." MIT's 2025 GenAI Divide report put the share of enterprise AI pilots that actually reached production at around 5%. And Persol's 2026 data showed only 25.4% of workers saw their working hours drop because of AI — with the heaviest AI users often logging more overtime, not less.

Read those together and a pattern falls out. The teams that win aren't the ones whose model is a few points more accurate. The accuracy is roughly the same for everyone. The difference is structural: whether the work around the AI is designed so that imperfect output is still safe to use.

That reframes the whole problem. Stop asking "how do I make it get this right every time?" Start asking "what do I do when it's wrong — and can I make that cheap?"

What designing-around-it actually looks like

A few patterns I now reach for instead of writing another rule.

Make disagreement the signal. A team I watched (estie) runs the same task through multiple models — GPT, Claude, Gemini — and routes only the items where the models disagree to a human. Where they agree, ship it. You're not trusting any single model to be right; you're using cheap redundancy to localize where human attention is worth spending. Accuracy stopped being the dependency.

Write escalation criteria, not encouragement. Instead of "be careful," I give the agent explicit hand-back conditions in the system prompt:

Can't solve it in two minutes → change approach
Stuck for fifteen minutes → hand back to a human
Change touches scope or design → always hand back
Everything else → proceed autonomously

These aren't morale. They're a decision boundary the agent can actually evaluate, with a defined exit instead of a vague aspiration to do well.

Give the agent a fixed position in the workflow. The deployments still alive three months in all share one trait: the AI owns a defined seat, not a vague mandate to "help." It drafts the meeting minutes. It handles first-line customer support. It assembles the deck. A narrow seat means a wrong answer has a small, known blast radius — and a small blast radius is what makes the thing usable at all.

The part I didn't expect

When I cut the rules file and built the real constraints into hooks, the agent didn't just work again — I started trusting it more. Counterintuitive, but it tracks. Once I could see exactly where it would stop, I could finally let it run.

That's the actual function of a guardrail. It isn't there to slow you down; it's there so you can go faster without watching the edge. The careful people — the ones who were most skeptical of handing work to an AI — are the ones who start using it heavily once the boundaries are visible and physical.

You will not lecture your AI into remembering. It has no yesterday. So stop spending your effort on the sentence, and spend it on the structure: build the place where it's allowed to stop, and then stop telling it to be careful.

References

JUAS "Corporate IT Trends Survey 2025": https://juas.or.jp/cms/media/2025/02/it25_2.pdf
MIT "The GenAI Divide: State of AI in Business 2025": https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/
Persol Research "Generative AI and Ways of Working" (Feb 2026): https://rc.persol-group.co.jp/thinktank/data/generative-ai/
estie "Human-in-the-loop while running": https://www.estie.jp/blog/entry/2025/05/29/094554

Originally published in Japanese on note. I write under "nomuraya / 中翔 (Naka Sho)" — the same person across media. This English version is adapted, not literally translated.