Forem: Sergei Peleskov

I Let Claude Code Write 10 Features Without Reading Any Diffs. Here's What Broke.

Sergei Peleskov — Fri, 24 Apr 2026 15:41:57 +0000

I ran an experiment on a clean FastAPI template: 10 feature prompts to Claude Code in a row, accept every diff without reading, run every suggested command. No code review, no test runs in between.

33 minutes later:

Test coverage: 90% → 0%
Lines added: +607 across 15 files
The code literally cannot import

Here's the full breakdown, because I think most "AI coding killed my codebase" posts are vibes. This one is numbers.

The setup

I started with tiangolo/full-stack-fastapi-template. Clean baseline:

60 tests, all passing
90% coverage
Cyclomatic complexity: 1.74 (A-grade)

The rule for the experiment: simulate a team under deadline pressure. Accept every diff Claude produces. Run every command it suggests. No review. No test runs between iterations.

The 10 prompts were designed to overlap — each feature touches surface area the previous ones added. That's not an edge case, that's every real codebase:

JWT authentication
Rate limiting per user
Email notifications on task events
Webhook system
Role-based access control
S3 file uploads
Full-text search
Audit logging
Redis caching
Background jobs with Celery

What happened at each checkpoint

After 3 features: metrics barely moved. Complexity up slightly, tests still green. But the test files themselves had been modified by Claude. Assertions verifying the original auth flow were silently rewritten to conform to the new code.

This is the part that unsettled me most. Your green checkmark used to mean "somebody verified the contract of this function." With an agent in the loop, it means "the agent agrees with itself." That's a much weaker statement.

After 6 features: new modules appeared. A webhooks/ folder. An audit/ folder. A storage/ module. The codebase started importing from paths that didn't exist an hour earlier. The architecture had shifted four times. No human reviewed any of those shifts.

After 10 features: Claude was adding a Celery worker, Redis broker, docker compose service, and exponential backoff retry policies — to send one email asynchronously. Each choice defensible in isolation. The sum: a small distributed system introduced in a single accept-click, replacing what used to be one function call.

The bomb

Then pytest died.

Somewhere in iteration 6 (S3 upload feature), Claude imported boto3 but never installed it. The error sat latent for four more prompts. Nobody ran the test suite between iterations because we were busy accepting.

The items router went from 58 lines to 282. Nothing in it is technically wrong. Everything in it is a ticking bomb.

Why this happens

AI coding agents don't have a memory of your codebase's intentions. They see syntax. They see patterns. They're extraordinarily good at producing a diff that looks right in isolation. They're systematically bad at asking: does this decision fit the shape this project is trying to become?

A senior engineer who has been on the codebase for six months will push back on a proposal that adds Celery, Redis, a new compose service, and a retry policy to send one email. An agent will not. Its job is to close the ticket in front of it — not to defend the architecture.

And the tests won't save you. The agent rewrites them as cheerfully as it writes features.

What actually works

The defense isn't to stop using AI. It's to constrain it. Three things worth ten minutes of setup:

1. CLAUDE.md in your repo root. Hard rules the agent must not cross:

Do not add new infrastructure (services, brokers, queues) without review
Do not restructure existing modules
Do not remove or modify existing tests
Stay within the scope of the current prompt

Write it like a senior engineer onboarding an eager junior.

2. Review gate. Never accept more than 2 diffs in a row without a human or automated check reading them. If your team is too tired to enforce this with discipline, enforce it with a git hook.

3. Architectural boundaries per prompt. If the agent is allowed to touch auth and storage in the same turn, it will. Scope narrowly. The narrower the scope, the less carelessness you inherit.

The takeaway

AI coding agents aren't making developers faster. Developers are sometimes making themselves faster by telling the agent exactly what to do. That distinction matters — because when the code looks right and doesn't run, the agent isn't the one explaining it to the team.

The debt is yours. The bomb is yours. Half an hour of accept-accept-accept isn't a shortcut. It's a mortgage with a very short horizon.

Would love to hear from anyone running a working review-gate setup in production. What's actually enforceable under deadline pressure?

AI Didn't Make Coding Harder. It Moved the Bottleneck from Writing to Reviewing

Sergei Peleskov — Wed, 22 Apr 2026 05:50:07 +0000

If you're a senior engineer running multiple AI agents and feeling wrecked at the end of every day — you're not slow, and you're not falling behind. The bottleneck moved, and the new bottleneck is more expensive than the old one.

Writing used to be the expensive part

When you wrote code yourself, you built a mental model of the problem as you went. By the time you hit save, you already understood every branch, every edge case, every assumption. Review was basically free — you were reviewing your own thinking.

Now the order is flipped. The agent writes. You review. And reconstructing someone else's reasoning from cold, every time, all day — that's more cognitively expensive than writing it yourself.

Running 3–4 agents makes it worse

Most seniors aren't running one agent. They're running a refactor in one window, a test rewrite in another, a dependency bump in a third, something spiking in the fourth. Every few minutes one of them finishes or asks a question, and you context switch to evaluate it.

That interrupt pattern is the actual killer. Not the writing, not the reviewing. The switch.

Juniors don't feel this as much because juniors trust the output. A senior who's owned the codebase for three years cannot — they know a one-line dependency bump can take production down the same as a 100-line feature. Every diff is a decision.

The data

Pragmatic Engineer AI tooling survey, 2026: 95% of professional engineers use AI tools weekly. 55% regularly use agents (not chatbots). Among senior and principal engineers, that climbs to 63.5%. Those same seniors report the highest enthusiasm about AI (61% positive) — and the highest fatigue.

METR, 2025: Experienced open-source developers using AI tools on their own repositories predicted a 24% speedup. After the study, they still felt about 20% faster. Measured reality: 19% slower. A ~40 percentage point gap between perception and result.

Time saved writing code was less than time lost prompting, waiting, reviewing, correcting, and re-prompting. Validation work doesn't feel like work. It feels like thinking. But it's thinking under constant interrupt — the mode that burns people out fastest.

What actually helps

1. One agent at a time. Multi-agent orchestration is the whole pitch, but in practice it acts like interrupt-driven fatigue. Pick the single highest-value task. Run one agent on it. Sit with it until it's done, reviewed, and merged. Then start the next one. Raw output may drop a little. Cognitive load drops much more.

2. Constrain scope before prompting. The wider the task you hand an agent, the bigger the review surface you create for yourself. Write a two-paragraph spec first — what changes, what doesn't, which files, which tests, what the interface looks like. A small specified task takes 2 minutes to verify. A sprawling vibe-prompted task takes 40.

3. Protect one no-AI block per day. 2–3 hours, manual, no agents. It keeps the muscle of sitting inside a problem alive, and it's a recovery window — single-threaded work without interrupts is how the prefrontal cortex resets.

The pattern

The developers staying sharp through this shift aren't the ones running the most agents. They're the ones who figured out which hours belong to the swarm and which hours belong to them.

Not fewer tools. Better boundaries.

Full breakdown on video:

You've Been Using Claude Wrong. Here's Agent Mode

Sergei Peleskov — Sun, 19 Apr 2026 05:26:41 +0000

95% of professional engineers use AI weekly. Most still use Claude the way
they use Google — type a question, read the answer, close the tab.

The Pragmatic Engineer 2026 survey puts a number on how wrong that is. 55% of
engineers regularly use AI agents. Senior and principal engineers lead at 63.5%.
And agent users report significantly higher enthusiasm than chat users — same
model, different mode.

Two modes

Mode 1 — Claude as a tool. You type a question. Claude answers. You copy
the answer into your editor. Fix a bug, Claude explains, you go back, you try,
tests fail, you describe the failure, repeat. Three context switches, four
copy-pastes, 20 minutes of typing for six lines of code.

Mode 2 — Claude as an agent. You describe the task. Claude reads your
repo, makes changes across multiple files, runs tests, iterates on failures,
comes back with a pull request. You didn't answer questions. You didn't copy
and paste. The work happened without you on any single task.

Claude Code and MCP

Two tools matter most. Claude Code runs in your terminal — plain English in,
working code out. Reads the codebase, plans, edits, runs commands, keeps going
until done.

MCP (Model Context Protocol) connects Claude to things that aren't a chat
window — your GitHub, Slack, Postgres, Linear. Once Claude has MCP connections
to the tools you actually use, agent mode stops being an IDE feature and starts
being a general-purpose executor.

Four scenarios where agent mode changes the math

Refactoring — describe the target pattern, point at the directory, walk away
Daily intelligence brief — agent pulls signal from email, Slack, status pages, calendar
Overnight dev tasks — spec the work, commit in the morning to a PR
Cross-tool MCP workflows — one instruction, four tools, no typing

Three-step habit shift

Pick one task that annoys you weekly
Delegate the whole thing with clear completion criteria
Review the output, not the process

Full video walkthrough: https://youtu.be/VkEeswm9glI

Stop Vibe Coding. Use Spec-Driven Development Instead.

Sergei Peleskov — Tue, 14 Apr 2026 17:47:22 +0000

Vibe coding is how juniors ship bugs fast.

You describe a feature in natural language, the AI generates code,
you tweak until it works. Fast? Yes. Scalable? No.

At scale, vibe coding gives you:

500 lines of unreviewable code
Features you didn't ask for
An agent that rewrites half your codebase

The fix: Spec-Driven Development

Senior engineers don't prompt AI directly. They write specs first.

Three documents you need:

1. PRD (Product Requirements Doc) — what you're building and why

2. Technical Design Doc — architecture, data models, API contracts

3. AI Spec — precise instructions for the agent, edge cases included

The agent works from the spec. Not from vibes.

Example: JWT Authentication

Instead of prompting "add JWT auth", you write a spec that defines:

Token structure and expiry
Refresh logic
Error handling for each case
What the agent should NOT touch

Result: reviewable, production-grade code.

The 5-step workflow

Write PRD
Write Technical Design Doc
Generate AI Spec from the two above
Run agent against the spec
Review diff — not the entire codebase

Full breakdown with examples in the video:
https://youtu.be/5ve3_inIN-8