DEV Community: flipslidersand

The AI Is Fast. The Decisions Are Mine.

flipslidersand — Mon, 06 Jul 2026 14:14:05 +0000

A lot of writing about AI-assisted development focuses on speed.

How fast you can generate code. How many lines per hour. How quickly you can go from idea to pull request.

Speed is real. But it is not the interesting question.

The interesting question is: who is responsible for what?

Get that wrong, and speed becomes a liability. You move faster toward the wrong place, with less awareness of how you got there.

The boundary I use

After four months as a solo engineer building a production system with Claude Code as my primary tool, this is the line I drew:

Human side:

Requirements — what the system should do, and what it should not do
Acceptance criteria — what "done" actually means for each unit of work
Production judgment — whether something is safe to ship

AI side:

Implementation — writing code that satisfies the criteria
Code review — flagging issues and suggesting alternatives
Repetitive testing — generating test cases and running assertions

This is not a rule I found written down somewhere. It is a conclusion I reached by watching what breaks when the line moves in either direction.

Why requirements must stay with humans

AI does not know your domain.

It knows patterns from training data. It can generate plausible-sounding requirements based on what similar systems have needed. But it does not know what your business actually needs, what your users are actually doing, or what your organization can actually support.

When I joined the company, I spent time on the shop floor before writing any code. Not to understand what to build — to understand what not to build. Which parts of the workflow had value precisely because they involved human judgment. Which parts were mechanical. Where systematizing would help versus where it would remove something important.

There is also a more subtle case. Sometimes the right answer from the observation phase is not to build something at all. I once watched a workflow that looked inefficient on paper — manual handoffs, no clear status tracking. The instinct was to systematize it. But two things stopped me. First, the manual handoffs were doing something a system could not: they forced a conversation that kept two people aligned. Second, that part of the workflow existed because of a specific regulatory requirement — one that could change or disappear entirely. Building a system around it would have meant maintaining something with an uncertain lifespan. I left it alone.

The observation phase is where you find out what not to build. AI was not in the room for that.

Why acceptance criteria must stay with humans

"Done" is a business decision, not a technical one.

A feature can pass all its tests and still not be done. Maybe it handles the happy path but leaves error states unclear. Maybe it works in isolation but creates friction in the actual workflow. Maybe it solves the problem that was described but not the problem that exists.

The acceptance criteria is the translation layer between what the business needs and what the system does. Getting that translation right requires the same domain knowledge that requirements do.

When I write a GitHub Issue, I write the acceptance criteria before I ask Claude Code to implement anything. That sequence matters. The implementation is shaped by the criteria. If the criteria is wrong, the implementation is fast in the wrong direction.

Why production judgment must stay with humans

Responsibility cannot be delegated to a tool.

If something breaks in production — data loss, incorrect calculations, a process that runs incorrectly overnight — the question is not "what did the AI do." The question is "who decided to ship this."

That accountability has to live somewhere. It lives with the person who made the call.

A concrete example: a customer-side image leak incident required a rapid audit response. There was almost no historical data to work from. The model's inferences were weak. But with a minimal scope, limited claims, clear caveats, and humans in the loop at every step, the output was still usable. Weak inference plus human judgment is often more than good enough. Strong inference with no human checkpoint is where things go wrong.

When I review a pull request before merging, I am not checking syntax. I am asking: does this match the acceptance criteria, and is this safe to run in production? Those are my questions to answer.

What happens when the boundary slips

The failure modes are predictable.

When AI takes on requirements: The system is built to match a plausible interpretation of the problem rather than the actual problem. This is often invisible until the system is in production and users start working around it.

When AI writes acceptance criteria: "Done" becomes technically correct rather than useful. Tests pass. The feature ships. Something important is still missing, but it is hard to say what.

When AI makes production calls: Nothing fails visibly. But the person who hit "deploy" does not fully understand what they shipped. Over time, this erodes the ability to reason about the system — you have output, but not understanding.

A specific example: I hit a SQL connection error, asked Claude Code to fix it, got a revised version, hit the same error again. Asked again. Got back something close to the original code. The problem turned out to be a version dependency — something that changed after the model's knowledge cutoff. No amount of prompting would have resolved it, because the model simply did not have the relevant information. The fix came from going directly to the latest documentation.

Knowing when to stop prompting and go elsewhere is a judgment call the tool cannot make for you.

What AI handles well, and why

The right side of the boundary is where AI is genuinely powerful.

Implementation, review, and repetitive testing all share a property: the standard is clear before the work starts.

When the acceptance criteria is written, there is an external measure of correctness. AI can write code against that standard, generate tests that check that standard, and flag when code does not meet it. The verifiability is what makes this work.

Boilerplate is the clearest case. Cloud Run configurations, Argo CD manifests, GitHub Actions workflows — these have well-defined correct forms. AI can produce them quickly and accurately. There is nothing to decide; there is something to write.

Error diagnosis is another strong case. A stack trace with a clear error message is a specification of what went wrong. AI can read that specification and suggest what caused it. The interpretation is bounded and checkable.

Fast output in bounded, verifiable tasks. That is where the leverage is.

The practical consequence

Once this boundary is clear, the day-to-day feels different.

I do not ask Claude Code what to build. I decide what to build, write it as a scoped Issue with acceptance criteria, and then ask Claude Code to implement it.

I do not ask Claude Code whether to merge. I ask Claude Code to review the pull request, I read the review, and then I decide.

I do not ask Claude Code if the system is ready for production. I look at the tests, the logs, the behavior in staging, and I make the call.

The AI is fast. The decisions are mine.

Why this matters more as tools improve

As AI tools become more capable, the temptation to move the boundary grows.

The output gets better. The suggestions feel more reliable. The friction of making your own decisions seems unnecessary when the AI gets it right most of the time.

But "most of the time" is not good enough for requirements, acceptance criteria, or production decisions. Those are the moments where being wrong has compounding consequences.

The tools improving does not change what needs human judgment. It changes how much of everything else can be handled without it.

Which means the human role is not disappearing — it is concentrating.

Less time on implementation. More time on what actually needs to be decided.

That is a better arrangement, not a worse one. But it only works if the boundary is held.

I Built an Article Draft Pipeline with Claude Code in Half a Day

flipslidersand — Mon, 06 Jul 2026 14:04:05 +0000

Writing technical articles is harder than it sounds.

The topic. The research. The structure. The references.

Before writing a single sentence of the actual piece, there is already a lot of work. By the time you have done it, you are half-tired before you start.

I wanted to fix this. So I built a pipeline that automatically generates draft material for articles — using Claude Code to move fast, and GitHub Actions to run it daily.

The total build time was roughly half a day.

What I built

The goal was not to auto-publish articles.

It was to build a stockpile of article starters — background context, related keywords, structural outlines — so that when I sit down to write, the hardest part is already done.

The architecture:

HackerNews / Dev.to → keyword collection (daily 08:00)
     ↓
  SQLite (keyword inventory)
     ↓
Gemini Flash-Lite → surrounding context generation (daily 09:00)
     ↓
  drafts/ → auto-committed to GitHub
     ↓
Human reviews → writes → publishes

The key constraint: AI generates the material, not the article itself. The writing stays with me.

Keyword collection

HackerNews uses the Algolia API. Dev.to has an official API. Both are auth-free, which keeps the setup lightweight.

The goal at this stage was not to build a comprehensive collection system. It was to get a steady, small flow of relevant topics arriving every day.

SQLite for inventory management

The database is SQLite. For a personal pipeline, there is no reason to run a separate database server. The SQLite file lives in the repo — which also means the keyword inventory has full version history.

CREATE TABLE keywords (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  source TEXT NOT NULL,
  keyword TEXT NOT NULL,
  category TEXT NOT NULL,
  used INTEGER DEFAULT 0,
  fetched_at TEXT DEFAULT (datetime('now'))
);

CREATE TABLE themes (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  keyword_id INTEGER REFERENCES keywords(id),
  title TEXT NOT NULL,
  slug TEXT NOT NULL,
  status TEXT DEFAULT 'pending',
  created_at TEXT DEFAULT (datetime('now'))
);

The used flag prevents the same keyword from generating multiple drafts. A monthly purge job clears out old entries.

Day-of-week rotation

Generating the same category of content every day gets monotonous. I split categories by day:

Monday: Tech
Tuesday: AI
Wednesday: Career
Thursday: Dev process
Friday: Product
Weekends: lighter topics

Each run pulls up to 5 unused keywords from that day's category. The cap matters — more than that and the folder becomes a pile nobody reads.

GitHub Actions for full automation

08:00 — collect keywords
09:00 — generate draft material

Generated files are committed and pushed automatically. When I sit down to write, drafts are already waiting. I pick a topic that looks promising and go from there.

How I used Claude Code

The entire build happened through conversation with Claude Code.

Framing — Talked through a vague requirement until the spec was concrete
Issue creation — Claude Code broke the work into GitHub Issues: fetch / generate / pipeline / DB / schedule
Implementation — Generated scripts and GitHub Actions workflows
Debugging — Ran it live, showed the errors, iterated until it worked

Step 4 was the most valuable. Getting from error message to fix in seconds — rather than searching for an hour — changes the pace of the entire build.

What actually broke

1. Vertex AI returning 403
First live run failed. Pasted the error into Claude Code. It identified BILLING_DISABLED and diagnosed the cause immediately: billing was not enabled on the GCP project.

2. Workload Identity Federation is scoped per repository
Copied a working config from another repo. It did not work. The workloadIdentityUser binding was scoped to the original repo. New repos need explicit registration:

gcloud iam service-accounts add-iam-policy-binding <SA> \
  --role=roles/iam.workloadIdentityUser \
  --member="principalSet://iam.googleapis.com/<POOL>/attribute.repository/<owner>/<repo>"

3. Japanese titles vanish when slugified
A standard replace(/[^\w\s-]/g, "") strips almost everything from a Japanese title. Fix: mix the database primary key into the slug from the start.

4. LLMs treat management labels as semantic content
I prefixed titles with Zenn: as an internal tag. The model read it as topic direction and generated off-target drafts. Strip management labels before passing anything to a model.

5. Swallowing errors produces silent empty output
Early on, API errors returned empty strings. Result: blank drafts committed as successful output. Better: throw on error, do not save empty output, do not mark keywords as used on failure.

Cost ceiling

Gemini 2.5 Flash-Lite at 5 drafts per day costs a few dollars per month at most.

But automated pipelines calling generative APIs need a hard ceiling. GCP budget alerts notify — they do not stop charges. I added a Cloud Function that disables the billing path when the monthly budget is exceeded. Build the stop yourself.

Why AI did not write the articles

I tried it. The output had hallucinated citations, placeholder text, and plausible-but-unverified claims. Not safe to publish directly.

As background research, keyword mapping, and structural outlines — more than good enough.

AI builds the inventory. The human does the writing and verification.

Since drawing that line, starting an article became significantly easier. I am not staring at a blank page. I am choosing from what already exists.

What this taught me

AI coding assistants make the cycle from vague idea to working system faster — not just the code writing part.

But the decisions were still mine.

What to build. What to automate. Where the human stays in the loop. What happens when it fails.

As tools become more capable, those design decisions become more important, not less.

This is an English adaptation of an article originally published in Japanese on Zenn.

People Who Resist Change Are Often Protecting Something

flipslidersand — Mon, 06 Jul 2026 14:01:22 +0000

We are often told that we live in an age of rapid change.

New technology. New ways of working. New values. New norms.

What felt obvious a few years ago quietly becomes outdated. What worked yesterday gets called inefficient today.

And somewhere in that process, we start asking:

Why won’t that person change?
Why won’t they accept a new way of doing things?
Why doesn’t anything I say get through?

These moments happen at work, at home, and inside organizations more often than most of us expect.

But before we label someone as “behind the times,” it is worth asking a different question:

What are they trying to protect?

Resistance is not always a capability problem

When someone resists change, our first instinct is often to frame it as a capability issue.

They are slow to understand. They lack flexibility. They are uncomfortable with new things. They cannot keep up.

That is sometimes true.

But not always.

It is possible that the person understands the change perfectly — and has decided not to accept it.

They see something valuable being lost.
They feel the new approach conflicts with what they care about.
The stability they have now looks more important than the benefit waiting on the other side.
They tried to adapt before, and it hurt.

From the outside, this looks like simple resistance.
From the inside, it can be a deliberate act of protection.

People don’t resist without reason

When someone won’t change, there is always a reason.

It might be logical. It might be emotional. It might be rooted in past experience.

Imagine someone at work who refuses to use a new tool, no matter how many times it is explained.

The people around them see someone being difficult.

But that person might feel like their way of working — built over years — is being dismissed. They might be afraid that not mastering the new tool will hurt how they are evaluated. Or they might have lived through a similar “change” that failed, and watched the people on the ground absorb all the damage.

Behind visible resistance, there is often anxiety, caution, or something being guarded.

That is why the first move is not persuasion.

The first move is to see what the person is trying to protect.

Understand before you try to change anything

When facing someone who resists change, we tend to add more explanation.

Lay out the benefits. Show the efficiency gains. Present success stories. Say that everyone else is already on board.

And when that does not move them, we push harder.

But persuasion rarely works if you do not yet understand what they are protecting.

Because you are talking about the benefits of change. They are focused on what the change will take away.

You are looking at different things.

You see convenience. They see risk.
You see efficiency. They see who takes the blame if this goes wrong.
You see the future. They see what happened last time.

When you are looking at different things, the conversation does not connect.

What is needed is not better arguments. It is a conversation to understand what they are actually looking at.

Respect is not the same as doing nothing

That said, respecting someone’s choice and simply leaving them alone are not the same thing.

People deserve to have their choices respected. Everyone has their own values and pace.

But when that choice affects others, the situation changes.

Not using a new system at work — which then increases the workload for teammates. Refusing to adapt at home — which shifts the burden unevenly onto one person. Holding onto old methods in an organization — which makes it harder for newer people to function.

In these cases, simply saying “that is their choice” and stepping back means someone else quietly absorbs the cost.

Respecting a choice is important.

But it does not mean the people around them are obligated to absorb all the consequences indefinitely.

Respect is not permission for everything. It is not the same as silence.

Precisely because you respect them, you still need to have the conversation about impact.

The right question is not who is right — it is what impact is happening

When the conversation turns to whether change should happen, it easily becomes an argument about who is correct.

Focus on behavior and impact — not character or correctness.

Not “you are wrong” — but “this approach is creating this burden here.”
Not “please change” — but “can we align on just this part?”

Not rejecting the person. Clarifying the boundary.

That distinction matters.

The freedom not to change — and its consequences

There is a freedom not to change.

No one needs to adopt every new thing. Keeping some distance from changes that conflict with your values is a legitimate choice.

But choices have consequences.

What matters is who bears those consequences.

If the person themselves carries them, that is their choice.
If the consequences fall on the people around them, that is where a conversation is needed.

There is a freedom not to change.
There is no freedom to make others absorb all the costs of that choice.

This line is important.

Adjusting distance, not forcing change

You do not have to change someone who resists change.

In fact, the harder you push, the more defensive they become.

What matters is not changing them — it is adjusting the distance.

How far do we move forward together? Where do we allow different approaches? Which parts need to be aligned at minimum?

Clarifying these boundaries makes the relationship significantly easier.

You do not need full agreement. You just need to know where your choices intersect and where they do not.

People who resist change have a story too

We tend to judge people by what we can see.

They don’t use new tools. They don’t change their approach. Nothing gets through.

That picture, taken alone, is frustrating.

But that person has a story.

Things they have protected over the years. Experiences of failure. A place they are afraid of losing if they change.

Telling someone to “just change” without acknowledging any of this will not move them.

What someone who resists change needs, before anything else, is to be understood.

And then — once you understand — you still draw the necessary boundaries.

Both are required.

In summary

There is no need to immediately label someone who resists change as “behind the times.”

They may be making a deliberate choice — to protect something they value.

So the first step is not persuasion. It is understanding.

But respect and silence are not the same. If their choice is creating impact on others, that impact needs to be addressed.

Do not dismiss the person who won’t change.
But do not leave the burden unaddressed either.

That balance — I think — is how we work with people in an age that keeps moving.

This is an English adaptation of an article originally published in Japanese on Zenn.

AI-Native Development Flow: 4 Months, 153 PRs, Production

flipslidersand — Mon, 06 Jul 2026 13:45:36 +0000

I joined a used-car export company as the only engineer.

There was no existing codebase. No engineering team. Just a mandate: build an internal operations platform for sales, inventory, and back-office work — and get it into production.

Four months later, the system was live.

Over 75 working days, I opened 153 pull requests.

This is how I structured the process.

The problem with "AI-assisted" development

Most discussions about AI-assisted development focus on code generation speed.

That misses the harder question:

Who decides what to build, and who signs off that it works?

If you hand those decisions to AI, you get fast output with no clear ownership. If you keep every decision entirely with yourself, you become the bottleneck — one person trying to do every kind of thinking at once.

I drew a different line.

The boundary

On the human side:

Requirements: what the system should do, and what it should not do
Acceptance criteria: what "done" actually means
Production judgment: whether something is safe to ship

On the AI side:

Implementation: writing code that satisfies the criteria
Code review: flagging issues and suggesting alternatives
Repetitive testing: generating test cases and running assertions

This sounds clean on paper.

The hard part is holding the line.

When Claude Code suggests an approach, it is tempting to accept it and move on. But that is exactly where judgment can slip.

The question is not only "does this code work?"

The better question is:

Does this solve the right problem?

That question stays on the human side.

What the workflow actually looked like

Every feature started as a GitHub Issue.

Not a vague task. A scoped description with acceptance criteria written in plain language — clear enough that I could read it the next morning and still know exactly what "done" meant.

From there:

Claude Code drafted the implementation.
I reviewed the pull request, not mainly for syntax, but for whether it matched the Issue.
Claude Code generated test cases against the acceptance criteria.
I made the final call on whether to merge.

The PR count climbed quickly because the Issues were small and specific.

A 153-PR codebase does not mean 153 features. It means 153 well-scoped units of work, each with a clear start and end.

What AI handles well

AI worked well for tasks where the expected output could be checked against a clear standard:

Boilerplate and scaffolding
Cloud Run configurations
Argo CD manifests
Pub/Sub wiring
GitHub Actions workflows
Error diagnosis from stack traces
First-draft implementations where the shape of the solution was already clear
Test generation against explicit acceptance criteria

The common thread is verifiability.

When the standard is clear, AI can move very fast.

What AI handles poorly

AI was much weaker at the parts that required business judgment.

It should not decide scope.

"Should this be in the system at all?" is not an AI question.

It should not judge operational readiness.

"Is this safe to cut over to production?" requires business context, operational risk awareness, and responsibility.

It also does not reliably notice what is missing.

The system does not know what it does not know about your domain.

These are the moments where solo engineers lose time if they treat AI judgment as equivalent to their own.

The numbers in context

153 pull requests over 75 working days is roughly two PRs per day.

That includes days with meetings, training, firefighting, and production support.

It is not a speed record.

It is a measurement.

I started tracking because I wanted to know whether this process was actually faster — not just whether it felt faster.

The production cutover happened in month four.

The system is running.

The measurement held.

What this means for teams

Most AI adoption conversations ask:

How much faster can one person go?

I think the more interesting question is:

What happens when an entire team holds this boundary consistently?

Implementation gets faster.

Review gets faster.

Repetitive testing gets faster.

But judgment stays where it belongs.

The bottleneck shifts from writing code to deciding what to write.

That is where the bottleneck should be.

The tooling matters. But the real change is not the tool.

The real change is the operating model.

AI-native development is not about letting AI take ownership.

It is about designing a workflow where AI accelerates execution, while humans keep responsibility for direction, judgment, and production risk.

That boundary is what made 153 PRs in 75 working days possible.

And more importantly, it is what made the system shippable.