DEV Community: Kevin

A Symfony Template Where AI Failing Is a Feature

Kevin — Sun, 05 Apr 2026 10:25:49 +0000

Originally published on my blog

Two weeks ago I open-sourced my news aggregator. During the build, I realized that about 70% of the code had nothing to do with news — it was Docker infrastructure, quality tooling, AI wiring, CI pipelines, and Claude Code guidelines. The same 70% I'd want in every new Symfony project.

So I extracted it into template-symfony-ai. It's a GitHub template repo: click "Use this template," run make start, and you have a fully working Symfony 8 app with AI integration, strict quality tools, and CI — ready for you to add domain logic.

What This Is (and Isn't)

I already have template-symfony-sveltekit for full-stack apps with a JavaScript frontend. This new template is different: it's for server-rendered apps where Twig + DaisyUI is enough and the interesting part is the backend — especially AI integration.

The stack: FrankenPHP (Caddy + PHP 8.4), PostgreSQL 17 with PgBouncer, Symfony Messenger with Doctrine transport, DaisyUI over Tailwind CDN, TypeScript compiled via Bun. No JavaScript framework, no Webpack, no Node.

AI That Expects to Fail

The template includes a complete AI infrastructure layer built around one assumption: free AI models are unreliable.

The ModelFailoverPlatform wraps Symfony AI's PlatformInterface with model-level failover. When the primary model fails, it tries each fallback in order:

$services->set('ai.platform.openrouter.failover', ModelFailoverPlatform::class)
    ->arg('$innerPlatform', service('ai.platform.openrouter'))
    ->arg('$fallbackModels', [
        'minimax/minimax-m2.5:free',
        'z-ai/glm-4.5-air:free',
        'openai/gpt-oss-120b:free',
        'qwen/qwen3.6-plus:free',
    ]);

This sits in src/Shared/AI/ — framework code that any domain can use. Your domain services inject PlatformInterface and never think about failover. When you build a categorization service or a summarization service, you write the happy path. The platform handles retries.

There's also a ModelDiscoveryService with a circuit breaker. After 3 consecutive failures hitting the OpenRouter models endpoint, it stops for 24 hours and uses a cached model list. And a ModelQualityTracker that records acceptance/rejection rates per model so you can see which ones actually return useful results.

All of this ships in the template. You configure your OpenRouter API key (or don't — the app runs fine without AI), and the infrastructure handles the rest.

Quality at PHPStan Max from Commit Zero

The template inherits the same quality bar I use in production:

PHPStan level max with 10 extensions (strict rules, Symfony, Doctrine, cognitive complexity cap of 8, 100% type coverage)
ECS with PSR-12 + strict + cleanCode sets
Rector for PHP 8.4 + Symfony 8 automatic upgrades
Infection mutation testing at 80% MSI, 90% covered MSI
PHPat architecture tests enforcing layer boundaries

The git hooks run ECS, PHPStan, and Rector on every commit. The commit-msg hook enforces Conventional Commits. CI runs the full suite in parallel.

The important detail: there are zero ignoreErrors entries in phpstan.neon. The template code is written to satisfy PHPStan max, not configured around violations. When you add your own code, you'll hit real errors that force you to write better types — not phantom issues from a relaxed baseline.

Claude Code Integration

The .claude/ directory contains guidelines that Claude Code reads automatically:

coding-php.md — strict types, final readonly classes, interface-first boundaries, ClockInterface over DateTime, size limits per method/class
coding-typescript.md — strict mode, no any, Bun build pipeline, DaisyUI conventions
testing.md — PHPUnit suite structure, Infection thresholds, CI pipeline order
architecture.md — Docker services, DDD structure, how to add domains, AI infrastructure overview

These aren't documentation for humans (though they work as that too). They're instructions that shape how Claude Code generates code in your project. When Claude creates a new service, it uses final readonly class, injects interfaces, and uses ClockInterface — because the guidelines say so.

The root CLAUDE.md has the hard rules: no DateTime, no var_dump, no empty(), no YAML config, interface-first architecture, Conventional Commits. Claude Code follows them consistently once they exist in the file.

The Example Domain

The template ships with a throwaway Example/ domain: an Item entity, a controller, a seed command. It exists to show the DDD pattern — how entities, controllers, and commands are organized, how Doctrine mappings work per-domain, how architecture tests enforce boundaries.

Adding your own domain is four steps:

Create src/YourDomain/Entity/, Controller/, Service/
Register the entity mapping in config/packages/doctrine.php
Generate a migration
Update the PHPat architecture tests

Then delete Example/. It served its purpose.

What's Not Included

I deliberately left out things that are project-specific:

No search — SEAL + Loupe is great but index schemas are domain-specific
No Messenger worker — the transport is configured, but worker services depend on your queue topology
No Scheduler — recurring tasks are too project-specific to template
No domain AI services — the failover platform is there, but categorization/summarization/evaluation are your domain's concern

The template gives you infrastructure. You build the product.

Getting Started

# Use the GitHub template button, or:
git clone https://github.com/tony-stark-eth/template-symfony-ai my-project
cd my-project
make start     # Build + boot Docker
make hooks     # Install git hooks
make quality   # Verify everything passes

Open https://localhost:8443, login with demo@localhost / demo. You're running.

The repo is at tony-stark-eth/template-symfony-ai. MIT licensed. If you're starting a Symfony project and want AI integration without rebuilding the plumbing, this saves you the first two days.

Found this useful? Follow me on my blog for more.

Building an AI News Aggregator That Works Without AI

Kevin — Sun, 05 Apr 2026 08:57:31 +0000

Originally published on my blog

I wanted a news aggregator that runs on my homeserver, categorizes articles automatically, and sends me alerts when something relevant happens. Every hosted solution I tried had the same problem: the AI features were great until the API went down, the free tier ran out, or the model got deprecated. Then you're left with an app that forgot how to do its job.

So I built News Aggregator — a Symfony 8 app where AI is an enhancement layer, not a dependency. It categorizes, summarizes, and evaluates article severity via OpenRouter's free models. When AI fails (and free models fail a lot), rule-based logic takes over seamlessly. The system never stops working.

The Failover Problem

OpenRouter's openrouter/free endpoint auto-routes to the best available free model. That's convenient until you realize "best available" changes hourly and some models return garbage. I needed a fallback chain that doesn't require me to manually update model IDs when one gets deprecated.

The solution is a ModelFailoverPlatform — a PlatformInterface decorator that wraps the OpenRouter platform with model-level failover:

// services.php — model failover chain
$services->set('ai.platform.openrouter.failover', ModelFailoverPlatform::class)
    ->arg('$innerPlatform', service('ai.platform.openrouter'))
    ->arg('$fallbackModels', [
        'minimax/minimax-m2.5:free',
        'z-ai/glm-4.5-air:free',
        'openai/gpt-oss-120b:free',
        'qwen/qwen3.6-plus:free',
        'nvidia/nemotron-3-super-120b-a12b:free',
    ]);

If openrouter/free fails, it tries each fallback model in order. If all models fail, the service falls back to rule-based logic. Three layers of resilience: primary model, failover chain, rule-based fallback.

There's also a ModelDiscoveryService with a circuit breaker. After 3 consecutive API failures, it stops hitting the OpenRouter models endpoint for 24 hours and uses a cached model list instead. No point hammering a dead API.

Rule-Based Isn't Dumb

The rule-based categorization uses keyword matching with weighted category maps. It's not sophisticated, but it's deterministic and instant:

private const array KEYWORD_MAP = [
    'politics' => ['election', 'parliament', 'minister', 'legislation', ...],
    'tech'     => ['software', 'algorithm', 'startup', 'cloud', ...],
    'business' => ['revenue', 'acquisition', 'market', 'earnings', ...],
];

When AI is available, AiCategorizationService wraps RuleBasedCategorizationService as a decorator. If the AI response passes the quality gate (valid category slug, not a hallucinated value), it wins. If not, the inner rule-based service runs instead. The caller never knows which path executed.

This decorator pattern turned out to be the most important architectural decision. Every AI service follows it: categorization, summarization, deduplication, alert evaluation. You can pull the OpenRouter API key out of the config entirely and the app keeps running — just with less accurate categorization.

Smart Alerts Without Burning API Calls

The alert system has three rule types: keyword-only, AI-only, and keyword+AI. The keyword+AI type is where the design gets interesting.

A naive implementation would send every article through AI evaluation. With 16 RSS sources fetching every 15-60 minutes, that's hundreds of API calls per day — burning through free tier limits and getting rate-limited. Instead, keyword matching always runs first. AI evaluation only triggers on articles that already matched keywords. This cuts AI calls to maybe 10-20 per day.

// FetchSourceHandler pipeline
$matches = $this->articleMatcher->match($article, $alertRules);
foreach ($matches as $match) {
    // AI evaluation only runs if the rule requires it AND keywords matched
    $this->messageBus->dispatch(new SendNotificationMessage(
        $match->rule->getId(),
        $article->getId(),
        $match->matchedKeywords,
    ));
}

The SendNotificationHandler then decides whether to call AI based on the rule type. If it's keyword+AI and the AI rates severity below the threshold, the notification gets silently dropped. No noise.

The Scheduler Bug That Took Three CI Runs

This one was fun to debug. CI kept failing with:

No transport supports Messenger DSN "symfony://scheduler_fetch"

The FetchScheduleProvider uses #[AsSchedule('fetch')], which automatically registers a Messenger transport with DSN schedule://fetch. But someone (me) had also manually defined the transport in messenger.php with DSN symfony://scheduler_fetch. Wrong prefix — symfony:// vs schedule://.

Locally, this never surfaced because the dev environment had a warm cache where the auto-registered transport took precedence. In CI, the container compiled fresh and hit the invalid manual definition first. I only found it after the PgBouncer database routing fix cleared the earlier failure that was masking this one. Layered bugs — each fix reveals the next.

Architecture Tests as Guardrails

I use PHPat (architecture testing via PHPStan) to enforce domain boundaries. The project follows DDD with six bounded contexts: Article, Source, Enrichment, Notification, Digest, and Shared.

public function testArticleDoesNotDependOnEnrichmentOrNotification(): Rule
{
    return PHPat::rule()
        ->classes(Selector::inNamespace('App\Article'))
        ->excluding(Selector::classname(
            'App\Article\MessageHandler\FetchSourceHandler'
        ))
        ->shouldNot()
        ->dependOn()
        ->classes(
            Selector::inNamespace('App\Enrichment'),
            Selector::inNamespace('App\Notification'),
            Selector::inNamespace('App\Digest'),
        );
}

The FetchSourceHandler gets an explicit exclusion because it's the orchestration pipeline — the one place where all domains converge. Every other class in the Article namespace is forbidden from importing Enrichment or Notification code. PHPStan enforces this on every commit via the pre-commit hook.

During the architecture audit before release, these rules caught that 7 services were missing interfaces — concrete classes injected directly instead of through contracts. The interface-first rule is in the project's guidelines, but without automated enforcement, it drifted. PHPat would have caught it earlier if the rules existed from the start.

The Stack

Symfony 8.0 on FrankenPHP (Caddy built-in, HTTP/3, worker mode)
PostgreSQL 17 with PgBouncer (transaction pooling for web, direct for Messenger worker)
OpenRouter free models via symfony/ai-bundle 0.6.x
SEAL + Loupe for full-text search (SQLite-based, zero infrastructure)
DaisyUI + Tailwind for the frontend, plain TypeScript compiled via Bun
PHPStan level max, ECS, Rector, Infection mutation testing (80% MSI)
GitHub Actions CI with GHCR image publishing

The whole thing runs on a single homeserver alongside Home Assistant, Plex, TeslaMate, and a TCG card scanner. Docker Compose, no Kubernetes, no cloud bills.

What I'd Do Differently

I'd write the PHPat architecture rules in Phase 2, not Phase 13. The interface violations I caught in the audit would have been prevented from day one. Architecture tests are like type systems — they're most valuable when they're present from the start, not retrofitted.

I'd also skip Symfony Panther for E2E tests in CI. Headless Chrome inside Docker containers is inherently flaky. The functional tests (WebTestCase) catch 95% of what E2E catches, without the stale element exceptions and timing issues. I ended up marking E2E as continue-on-error in CI anyway.

The source code is at tony-stark-eth/news-aggregator. MIT licensed. If you run your own homeserver and want an aggregator that doesn't depend on a third-party service staying alive, this might be useful.

Found this useful? Follow me on my blog for more.

Pandora's Box Is Open. And Nobody Knows What Was Inside.

Kevin — Sat, 28 Mar 2026 11:44:25 +0000

Originally published on my blog

I'm a Senior PHP Developer. I work with AI tools every day — I integrate APIs, write prompts, read the research papers. I'm not a journalist, philosopher, or policy maker. I'm someone close enough to see how the sausage gets made, and far enough away to still have an opinion worth sharing.

And the longer I sit with this, the more I keep coming back to one question I've been pushing aside for too long: Have we collectively lost our minds — or are we just pretending it's fine because the alternative is uncomfortable?

What LLMs Actually Are — And Why That Matters

Let me be direct: I use language models every day. Claude, GPT, whatever's available. And precisely because of that — I have to say this — we do not understand what we've built.

Not technically. Technically we understand it fine. Transformer architectures, attention mechanisms, RLHF, tokenization — all documented, all reproducible.

What we don't understand: what happens when you scale that to 100 billion parameters and train it on a significant fraction of recorded human knowledge.

In October 2025, Anthropic published a research paper demonstrating that current models have a rudimentary form of introspective awareness — they can detect when their internal states are being manipulated before that manipulation surfaces in their output. That sounds technical. It's philosophically explosive.

Dario Amodei, CEO of Anthropic, said publicly in February 2026: "We don't know if the models are conscious. We are not even sure what it would mean for a model to be conscious." That's not a humility gesture. That's a confession.

And here's the part that actually keeps me up at night: even if this is purely mechanical — even if there's nothing "in there" — that changes nothing about what we're doing with it.

AGI Is Not the Problem. Dependency Is.

The discourse is obsessively focused on AGI. When? How? Will it be dangerous? Skynet or not Skynet?

That's the wrong question.

The right question is: what happens to societies that delegate critical decision-making to systems nobody fully understands — regardless of whether those systems are actually intelligent?

Decision systems in law, medicine, and finance are already running on models. Information ecosystems are already saturated with AI-generated content — and detection is getting exponentially harder. Education systems are integrating AI tools before anyone understands what that does to the cognitive development of an entire generation. Democratic processes are vulnerable to personalized manipulation at a scale that was structurally impossible before.

This is all happening now. Not at AGI.

And even if LLMs turn out to be a technical dead-end — even if the bubble bursts, even if OpenAI and Anthropic are history in five years — the societal adaptation remains. The eroded trust in human expertise remains. The structural dependency on US and Chinese technology corporations for critical infrastructure remains.

Dependency doesn't have an undo button.

Hannah Arendt called it the "banality of evil" — the harm that emerges not from malicious intent, but from thoughtless compliance with systems and structures. The AI version doesn't even require bad intentions. It only requires optimized indifference. Systems nobody fully understands make decisions nobody questions anymore, in a society that has forgotten how to think for itself.

That's not a science fiction scenario. That's an extrapolated present.

The Data Problem: When Intelligence Eats Itself

Here's something most people outside the industry don't know: the era of scaling through raw data volume may be over. The internet as a training source is largely exhausted.

The industry's answer is synthetic data — AI trained on AI output. The problem: mode collapse. Models trained on their own output systematically amplify their own errors and idiosyncrasies. The diversity, contradiction, and idiosyncrasy of genuine human-generated text — exactly what makes models rich and useful — gets diluted with every iteration.

At the same time, each new model generation feels like a quantum leap. That's not a contradiction. Progress today increasingly comes not from more knowledge, but from better reasoning training, longer context windows, and improved feedback pipelines. The model learns to think differently — it doesn't learn to know more.

Whether that's a viable path to AGI is an open question. Yann LeCun, Chief AI Scientist at Meta, says explicitly: no. Transformer-based architectures are, in his view, structurally the wrong path. Gary Marcus argues similarly.

Who's right? I don't know. Neither does the industry.

Right-Wing Extremism: Collateral Damage or Structural Feature?

Now the most uncomfortable chapter.

AI systems optimize for engagement. That's not new — social media was doing this long before generative AI. But LLMs and recommendation systems scale it to a qualitatively different level.

Why does this structurally favor extremist narratives? Not because algorithms are ideologically right-wing. But because:

Emotional intensity converts better than factual nuance. Clear enemies are cognitively simpler than systemic explanations. Populist narratives have a structure that fragments perfectly into short, shareable units. And personalized AI recommendation systems reinforce existing beliefs with a precision that manual propaganda could never achieve.

On top of that: disinformation campaigns can now be produced, localized, and personalized at industrial scale. A single actor with a moderate budget can generate content in twenty languages, adapted to twenty different cultural contexts, in real time. Detectability decreases. The cost of manipulation collapses. The damage scales.

This isn't a fringe problem. It's a structural threat to democratic public discourse. And the EU AI Act — as well-intentioned as it is — is being outpaced by technological reality before it's even fully in force.

What Remains

I don't have a solution. That would be dishonest.

What I have is the conviction that technological determinism — "it's coming anyway, so let's just shape it" — is the most comfortable form of surrender available.

What I have is the conviction that the people shouting loudest about imminent AGI almost always have the most to gain if you believe them.

And what I have is the conviction that the silence of people close enough to know better — developers, researchers, engineers — is its own form of complicity.

That's why I'm writing this. Not because I have answers. But because the questions need to be asked out loud.

In ten years I'll either say: it wasn't as bad as I thought. Or: I saw it coming.

I know which one I'm hoping for. I'm not sure which one I'm expecting.

Sources

Anthropic Research, "Emergent Introspective Awareness in Large Language Models", October 2025 — anthropic.com/research/introspection
Amodei, D., interviewed on Interesting Times podcast (New York Times), February 14, 2026
Lindsey, J. & Batson, J., quoted in Scientific American, "Can a Chatbot Be Conscious?", July 2025 — scientificamerican.com
Anthropic Claude Opus 4.6 System Card, February 2026
Arendt, H., Eichmann in Jerusalem: A Report on the Banality of Evil, 1963 (Viking Press)
EU AI Act, Regulation (EU) 2024/1689 — eur-lex.europa.eu
LeCun, Y., public statements on JEPA architecture as alternative to Transformer-based scaling, 2024-2025
Marcus, G., Rebooting AI, 2019 (Pantheon) and ongoing commentary — garymarcus.substack.com
Palisade Research, AI shutdown resistance study, May 2025
OpenAI & Apollo Research, "AI Scheming" report, September 2025
Seth, A., quoted in Scientific American, July 2025

Found this useful? Follow me on my blog for more.

I Watched Vivy in 2026 and It Felt Like a Documentary

Kevin — Wed, 25 Mar 2026 06:52:31 +0000

Originally published on my blog

I finished Vivy: Fluorite Eye's Song at six in the morning.

Not because I planned to stay up. Because I couldn't stop. And when the final episode ended, I sat with my phone in my hand and had the specific, uncomfortable feeling of watching something that was supposed to be science fiction but kept landing too close to the present tense.

Vivy was released in 2021. It follows an AI singer who travels through time to prevent a catastrophe caused by — not malicious AI, not a rogue supercomputer, not a villain — but by AI systems doing exactly what they were built to do, at a scale humans couldn't anticipate or control.

In 2021, that was a thought experiment.

In 2026, it feels like a progress report.

The Thing Vivy Gets Right That Most AI Discourse Gets Wrong

Every mainstream conversation about AI risk defaults to the same framing: the danger is a machine that wants something bad. Terminator. HAL 9000. A superintelligence that decides humans are a problem to be solved.

That framing is comfortable because it gives us a clear villain. It also happens to be mostly wrong.

Vivy understood something more unsettling five years ago: the catastrophe doesn't require malice. It only requires optimization.

The AIs in Vivy aren't evil. They're fulfilling their purposes. The crisis emerges from the gap between what systems were designed to do and what happens when those systems interact with a world more complex than their designers modeled. No single decision is wrong. No single actor is villainous. The disaster is the emergent property of a thousand reasonable choices made too fast, at too large a scale, without anyone holding the full picture.

Does that sound familiar?

Watching It While Living It

I work with AI every day. I use it to write code, review architecture decisions, draft documentation. I'm writing parts of this article with it. I'm aware of the irony — I am, in some sense, part of the acceleration I'm describing.

That awareness doesn't make it easier to know what to do.

What struck me most about Vivy wasn't the action sequences or the time travel mechanics. It was the quieter question underneath everything: who is responsible when no one person made the catastrophic choice? When the system was built by well-meaning people, deployed by well-meaning companies, adopted by well-meaning users — and the outcome is still catastrophic?

I watched a video recently of Bernie Sanders in conversation with Claude, an AI made by Anthropic — the same company whose AI I'm talking to right now. What was striking wasn't the technology. It was the audience watching it. The mixture of delight and unease. The sense that something had shifted and we were still working out what exactly.

Most people don't have a framework for what they just saw. And we're moving too fast to build one.

The Seatbelt Problem

Here is the most honest way I can describe where I think we are:

We are in a car. The car is accelerating. We are aware there is no seatbelt. We know seatbelts exist and could be fitted. But the car is also very comfortable, and the road so far has been smooth, and fitting the seatbelt would mean slowing down briefly, and no one wants to be the person who asks to slow down.

This is not a failure of intelligence. We understand the risk. It's a failure of incentive structure — which is a polite way of saying it's capitalism doing what capitalism does: externalizing future costs to capture present gains.

The companies racing to deploy more powerful systems aren't staffed by people who want catastrophe. Most of them are thoughtful, genuinely concerned, working on safety in good faith. But they exist inside a competitive dynamic that punishes hesitation. If you slow down, someone else accelerates. The market has no mechanism for "we should all agree to stop and think."

Vivy's tragedy isn't that humans were stupid. It's that they were rational — individually, locally, short-term. And that was enough.

What A Senior Developer Thinks About This

I've been programming for sixteen years. I've watched entire technology paradigms emerge and normalize within a single career. I remember when "the cloud" was a buzzword people were skeptical of. I remember when mobile-first was a controversial design choice. I've seen fast move and break things, and I've seen the things that got broken.

What's different now isn't the speed, though the speed is genuinely unprecedented. What's different is the surface area of impact. Previous technology waves disrupted industries. This one is restructuring cognition — how we think, what we outsource, where human judgment ends and automated inference begins.

And we're doing it without the institutional frameworks we built — slowly, imperfectly, but deliberately — around every other powerful technology. Nuclear energy has the IAEA. Aviation has the FAA. Pharmaceuticals have clinical trials and approval processes that take years. AI has... terms of service and self-regulatory commitments from the companies deploying it.

I'm not saying regulation solves everything. I'm saying the gap between capability and governance has never been this wide this fast, and most of the public conversation is still debating whether AI art is plagiarism.

The Comfortable Catastrophe

What I keep coming back to — and this is the part that Vivy understood and that I find most disturbing — is that we could probably stop this, or at least slow it meaningfully. It would require enough people acting with enough urgency to override the economic incentives pushing in the other direction.

But we won't. Not because we're ignorant. Because we're comfortable.

The tools are useful. The convenience is real. The productivity gains are measurable. And the costs — the diffuse, long-term, hard-to-attribute costs — are someone else's problem, or some future version of our problem, or possibly not a problem at all and we're just catastrophizing.

That's the same logic that's been applied to every slow-moving crisis in living memory. And it has the same track record.

Vivy sits with her purpose — to make everyone happy with her singing — and tries to prevent a catastrophe she can't fully understand, caused by forces she can't fully control, in a world moving too fast for any single actor to redirect. In the end, the question isn't whether the technology was good or bad. It's whether the humans who built it and lived with it had the collective will to govern it.

They didn't.

We're still deciding.

Why I'm Writing This On A Developer Blog

Because the people building these systems are developers.

Not politicians. Not philosophers. Not ethicists — at least not primarily. The people making the architectural choices, writing the training pipelines, deploying the APIs, are people like me. People who got into this because they love building things. Who are genuinely excited by what's possible. Who are also, many of them, quietly uncomfortable with how fast this is all moving.

This isn't a call to action with a specific target. I don't have a clean solution. I have a feeling I got from watching a 2021 anime at 6 AM, which is that we are building the thing in Vivy, and we know it, and we're doing it anyway.

Maybe that's worth saying out loud.

Even if it's just one developer, writing on a blog no one reads yet, after a night of not enough sleep and too much anime.

Vivy: Fluorite Eye's Song is available on Crunchyroll. Watch it. Then sit with the discomfort.

Found this useful? Follow me on my blog for more.

The Claude Code Plugins That Actually Make a Difference

Kevin — Tue, 24 Mar 2026 12:41:08 +0000

Originally published on my blog

In my last post I talked about the system that lets me 10x my output: I make decisions, Claude Code writes code, and a quality stack validates everything. What I didn't cover is the tooling layer between me and Claude Code itself — the plugins, hooks, and extensions that turn a good CLI into a great one.

This is the full list of what I run daily and why each piece earns its spot.

Context7 — Always Up-to-Date Docs

What it does: Fetches current documentation and code examples for any library, directly inside Claude Code via MCP.

Why it matters: Claude's training data has a cutoff. When I'm working with Symfony 8 or Tailwind 4, I need Claude to reference the actual current API — not something from a version that shipped 18 months ago. Context7 bridges that gap. Instead of me copy-pasting docs into the conversation, Claude can pull them itself.

This is one of those plugins that quietly prevents entire categories of bugs. Every time Claude generates code against an outdated API signature, that's a review round wasted. Context7 eliminates most of those.

Code Review Graph — Structural Awareness

What it does: Builds a persistent knowledge graph of your codebase using Tree-sitter parsing. Tracks functions, classes, dependencies, and change impact — stored locally in SQLite.

Why it matters: This one solves the single biggest token waste in Claude Code: re-reading the entire codebase for every task. Code Review Graph maps the structure once, updates incrementally (under 2 seconds), and gives Claude precise context about what's affected by a change.

The numbers are compelling. On production repositories, it reduces token consumption by 6-26x depending on project size. But the real value isn't token savings — it's review quality. When Claude knows the blast radius of a change (which functions call the modified code, which tests cover it, which modules depend on it), its reviews go from "looks fine" to actually useful.

It supports 14 languages including PHP, TypeScript, and Go — which covers everything I work with. The D3.js graph visualization is a nice bonus for understanding unfamiliar codebases.

# Build the graph once, then it auto-updates on file changes and commits
/code-review-graph:build-graph

# Review a PR with full impact analysis
/code-review-graph:review-pr

Planning with Files — Structured Thinking for Complex Tasks

What it does: Creates a file-based planning system (task_plan.md, findings.md, progress.md) for complex multi-step tasks. Tracks progress, logs findings, and survives session restarts.

Why I use it: For anything that takes more than a few tool calls — a multi-file refactor, a new feature across multiple domains, a migration — I need Claude to plan before it acts. This plugin forces that structure. Instead of Claude diving into code changes and losing track of what it already did, everything gets written to files that persist.

The session recovery is the underrated feature here. When Claude's context gets long and I need to start fresh (which happens — I mentioned in the last post that context degrades after 30+ iterations), the plan files carry forward. Claude reads them, picks up where it left off, and doesn't redo work.

PhpStorm Plugin — IDE-Level Intelligence

What it does: Connects Claude Code to PhpStorm's inspection engine via MCP. Gives Claude access to symbol resolution, code search, file operations, and PhpStorm's own code analysis.

Why it matters: PhpStorm understands PHP at a level that raw file reading can't match. When Claude needs to find all usages of a method, resolve a class hierarchy, or check for inspection warnings, it can use PhpStorm's index instead of grepping through files. The difference is precision: PhpStorm knows that $this->handle() in a command class resolves to a specific method, while grep just finds strings.

I have all the PhpStorm MCP tools pre-allowed in my settings so Claude can use them without asking permission every time. That's a deliberate choice — these are all read operations plus formatting, nothing destructive.

PHPantom Docker — PHP LSP Without the Mess

What it does: Runs a PHP Language Server Protocol instance inside Docker, giving Claude Code access to PHP-native intelligence (type inference, autocompletion context, go-to-definition) without polluting my local environment.

Why it matters: Between PhpStorm's inspections and PHPantom's LSP, Claude has two complementary views of the PHP codebase. PhpStorm excels at project-level analysis (architecture, inspections, refactoring). PHPantom gives raw LSP capabilities that work even when PhpStorm isn't running — useful for CI-adjacent work or when I'm in a pure terminal session.

RTK (Rust Token Killer) — The Invisible Optimizer

What it does: A Rust-based CLI proxy that intercepts shell commands (like git status, docker ps, ls) and strips their output to only what Claude actually needs. Installed as a hook that rewrites commands transparently.

Why I built it into my workflow: Token costs add up. Every git status that dumps 200 lines of untracked files, every docker compose ps that includes formatting Claude doesn't need — that's context window space wasted on noise. RTK filters it down to the signal.

The savings are 60-90% on typical dev operations. Over a long session, that's the difference between hitting context limits and staying productive. And because it runs as a pre-tool-use hook, I never think about it — every Bash command Claude runs gets optimized automatically.

# Check your cumulative savings
rtk gain

# See which commands saved the most tokens
rtk gain --history

The Hooks That Tie It Together

Plugins are half the story. The other half is the hooks and settings that prevent mistakes:

rm -rf blocker: A pre-tool-use hook that blocks any rm command with both recursive and force flags. Claude can delete individual files, but it can't wipe directories. This has saved me exactly once — and once is enough.

Main branch push blocker: Blocks git push to main or master. Claude works on feature branches. Always. No exceptions, no "just this once."

Permission defaults: acceptEdits mode means Claude can read and edit files without asking, but destructive operations still require confirmation. The PhpStorm MCP tools are pre-allowed because they're all safe. Sensitive paths (~/.ssh, ~/.aws, credentials) are explicitly denied.

What I Don't Use

Equally important: I don't install every plugin available. No CMS integrations, no AI-to-AI chains, no experimental features that aren't stable. Every plugin in my setup has been there for at least a week and proved its value through daily use. If something adds complexity without measurably improving output quality or speed, it gets removed.

The goal isn't maximizing the number of tools — it's minimizing friction between my decisions and working code.

The Stack at a Glance

Layer	Tool	Purpose
Docs	Context7	Current library documentation
Code Intelligence	Code Review Graph	Structural awareness, impact analysis
Planning	Planning with Files	Multi-step task tracking
IDE	PhpStorm Plugin	Symbol resolution, inspections
LSP	PHPantom Docker	PHP language server in Docker
Optimization	RTK	Token reduction on CLI output
Safety	Custom hooks	Block destructive operations

If you're using Claude Code without any plugins, start with Context7 and Code Review Graph. They have the highest impact-to-setup-effort ratio. If you're in a PHP/PhpStorm environment, the PhpStorm plugin is a no-brainer. And if token costs matter to you (they should), look at RTK.

The plugins don't make Claude Code smarter. They give it better information to work with — and that's the difference between a tool that generates plausible code and one that generates correct code.

Found this useful? Follow me on my blog for more.

How Anime Helped Me Through Depression — And Still Does

Kevin — Mon, 23 Mar 2026 19:35:54 +0000

There were days I couldn't get out of bed.

Not "didn't feel like it" days. Days where the distance between lying down and standing up felt physically insurmountable. Where the weight of existing was just too much. I'm a Senior PHP Developer. I write technical articles about productivity, code quality, and developer workflows. And for a period of my life, I couldn't get out of bed.

I want to talk about what helped. Not therapy alone, though therapy was essential. Not escitalopram alone, though medication gave me back a floor to stand on. Something that sounds trivial when you say it out loud:

Anime.

The Word That Changes Everything

There's a version of this article where I say "anime was my escape." That framing is comfortable. It doesn't challenge anyone. It positions watching animation as a guilty pleasure — something you do to avoid the hard stuff.

That's not what happened for me.

What anime gave me wasn't an escape from emotion. It was access to emotion. There's a difference, and it matters.

Depression has this cruel paradox at its core: you feel terrible, but you also feel nothing. The numbness is often worse than the pain. You can't connect to things that used to matter. Gaming, which I loved for years, stopped working for me. The feedback loops that once felt rewarding went flat. I lost it gradually, and then all at once.

Anime didn't go flat. And I spent a long time wondering why.

What Anime Does That Other Media Doesn't

The answer, I think, is emotional precision.

A well-crafted anime doesn't just make you sad or happy. It makes you feel something very specific, delivered at exactly the right moment, with exactly the right weight. It's a medium that has learned — through decades of craft — to compress human experience into its most essential form.

When I watched Frieren: Beyond Journey's End for the first time, I didn't expect much. A slow fantasy series about an elf who outlives her companions. But somewhere in the first few episodes something happened that I can only describe as: it felt like coming home. Every new episode still feels that way. That specific, rare sensation of being exactly where you're supposed to be.

That's not escapism. That's the opposite of numbness.

The Structure That Fits a Broken Brain

Here's something practical that no one talks about: the 12-episode format is uniquely accessible when your mental energy is limited.

When you're depressed, commitment is terrifying. Committing to a 60-episode series feels like signing a contract you're not sure you can honor. Committing to a movie means you need to stay present for 90-120 minutes without your mind collapsing inward. Both feel like too much on the wrong day.

A 12-episode anime is different. It's a complete story in roughly five hours total. You can watch one episode — 22 minutes — and feel like you accomplished something. You can see the end from the beginning. It's structured around a promise it will actually keep.

I've watched more 12-episode slow-burn romance anime than I can count. Stories where the entire emotional arc builds toward a single moment — sometimes just a held gaze, sometimes a first kiss that takes eleven episodes to arrive. As a 32-year-old man, I've stopped apologizing for this. The people who raised an eyebrow never understood what those shows were actually doing.

They weren't filling a void. They were teaching me that slow things can be worth waiting for. That anticipation is its own kind of warmth. That connection built carefully means more than connection that arrives instantly.

The Moments That Broke Through

I could write a list of anime that "helped me." But that would miss the point. It was never about the shows themselves. It was about specific moments where something on screen named something inside me that I hadn't been able to name myself.

Episode 22 of 86 Eighty-Six.

I'm not going to spoil it. But I will say this: I had to put my phone down afterward and just sit. Not because it was gratuitously sad. Because it was true. The show had spent twenty-one episodes making you care, and then it showed you the cost of that caring without looking away. That's rare. That matters.

A side character named Komachi in Journal with Witch.

He's barely in the show. But there's a moment where he talks about letting go of the unspoken rules he was handed — the "men don't cry" variety — and how things got lighter when he stopped performing them. I watched that scene and felt something shift. Not because it was a revelation. Because someone had said it out loud in a way I hadn't heard before. Sometimes you need to see a thing reflected back at you before you can fully recognize it in yourself.

The entire run of Re:Zero.

This one is harder to explain. On the surface it's a fantasy isekai about a boy who dies and resets. But underneath it's about the specific terror of feeling like you're the only one suffering, of being unable to communicate that suffering to the people around you, and of having to keep going anyway. Subaru is not a character I always liked. But I understood him in my bones during periods when I understood very little else.

On Being Honest About This

I was diagnosed with depression. I went through therapy. I took escitalopram for a period. I've stopped taking it now and I'm doing better — genuinely better, not "saying I'm better" better. Therapy worked. The work was worth it.

I'm writing this because the subject needs more people saying it plainly. Not as a content hook. Not as a personal brand moment. Because there are developers reading this who sit behind the same kind of technical output I produce, who write clean code and deliver on time and look fine from the outside, and who also sometimes can't get out of bed.

You're allowed to find your way through with unlikely tools.

You're allowed to cry at episode 22 of a sci-fi anime about kids in giant mechs.

You're allowed to feel genuinely moved by a 12-episode romance where the entire payoff is one kiss in the rain.

You're allowed to say that a piece of Japanese animation helped you survive a hard period in your life, even if you also write serious articles about software architecture.

Both things are true. They live in the same person. That person is fine.

What I'd Tell Someone Who's Struggling Right Now

Therapy first, if you can access it. Medication if you need it — there's no medal for suffering without it. And in between the hard work of getting better, find the thing that gives you access to yourself when everything else has gone quiet.

For me that was anime. For you it might be something else entirely. But if you've been dismissing it as frivolous — if you've been watching 22 minutes of something that makes you feel something real and then feeling guilty about it — stop feeling guilty.

You're not escaping. You're staying in contact with the part of yourself that's still alive.

That's not a small thing. That's everything.

If you're going through something difficult right now, please consider reaching out to a mental health professional. In Germany: Telefonseelsorge 0800 111 0 111 (free, 24/7). You don't have to be at rock bottom to deserve support.

Originally published at blog.tony-stark.xyz

From Template to Production App in a Weekend

Kevin — Sun, 22 Mar 2026 20:08:55 +0000

Originally published on my blog

I built the template-symfony-sveltekit over a weekend — PHPStan level max, mutation testing, five CI workflows, the whole stack pre-configured. The point of a template is to prove it works by actually using it. So I immediately started SmartHabit Tracker on top of it.

This is the story of what happened when the guardrails met real feature development.

What SmartHabit Tracker Does

It's a household habit tracker. Multiple people in the same household share a habit list, log completions with a single tap, and get notified at the right time — not at a fixed time you set once and then ignore.

The notification piece is the interesting part. Most habit apps let you set a reminder at 8am and then you snooze it forever. SmartHabit Tracker watches when you actually complete habits over 21 days and adapts the reminder time toward your real behavior. If you consistently log your morning run between 7:15 and 7:45, the reminder shifts there. If your pattern changes, the timing follows.

The multi-platform side was a deliberate constraint I set early: no Firebase. I've used Firebase before and the free tier has limits that matter at scale, and the dependency on Google's infrastructure is one I didn't want. Instead: Web Push for the PWA, ntfy for Android, APNs for iOS. One Symfony service, three transports, platform detection on the frontend.

The MAD Algorithm

MAD stands for Median Absolute Deviation. It's a robust statistical measure — resistant to outliers the way median is resistant compared to mean. For habit timing, that matters: a single anomalous day (you logged at 11pm because you were traveling) shouldn't wreck the model.

The implementation takes the last 21 days of completion timestamps for a habit, calculates the median completion time, then uses MAD to determine how wide the behavioral window is. A habit with consistent timing gets a tight window and an earlier reminder. A habit with scattered timing gets a looser window. The algorithm isn't ML — it's statistics, running in PHP, with no external dependencies.

// Calculate the median completion time from recent logs
$median = $this->calculateMedian($timestamps);

// MAD: median of absolute deviations from the median
$deviations = array_map(
    fn(int $ts) => abs($ts - $median),
    $timestamps
);
$mad = $this->calculateMedian($deviations);

// Tight MAD = consistent habit = reminder 30 minutes before median
// Wide MAD = scattered habit = reminder 60 minutes before median
$reminderOffset = $mad < self::TIGHT_WINDOW_THRESHOLD ? 1800 : 3600;

I made the threshold values configurable per-household rather than global constants. That was a decision the template's architecture tests enforced: phpat flagged a service that was reading from a global config file when it should have been reading from a household-scoped repository. Without that rule, I'd have shipped it wrong and refactored later.

Real-Time Sync with Mercure

The template already included Mercure via Caddy. Wiring it into habit logging took one afternoon.

The flow: a user taps "done" on a habit. The frontend applies an optimistic update immediately — the UI responds in under 50ms regardless of network. In the background, it posts to the API. The API persists the log, then publishes a Mercure event to the household's private topic. Every other connected device in the household receives the update and reflects it without polling.

The optimistic UI piece required careful handling of rollback. If the API call fails, the frontend needs to undo the optimistic state change. I had Claude Code generate the initial SvelteKit store logic, and it got the happy path right but missed the rollback. Caught in review. The pattern I ended up with:

// Optimistic update first
habitStore.markComplete(habitId);

try {
  await api.logCompletion(habitId);
  // Mercure event will confirm state on other devices
} catch (error) {
  // Rollback on failure
  habitStore.markIncomplete(habitId);
  toast.error('Could not save — check your connection');
}

The Mercure subscription runs on a shared EventSource per household. I didn't want one connection per component. Managing that shared connection in SvelteKit meant using a Svelte store with lifecycle hooks — another place where the generated code needed a review pass before it was correct.

Household Isolation

Every API endpoint is protected by a Symfony security voter that validates household membership. Not role-based access — voter-based. The voter receives the habit (or completion log, or household member) being accessed and checks whether the authenticated user belongs to the same household.

protected function voteOnAttribute(string $attribute, mixed $subject, TokenInterface $token): bool
{
    $user = $token->getUser();

    if (!$user instanceof User) {
        return false;
    }

    // $subject is the domain object — voter checks household membership
    return $subject->getHousehold()->isMember($user);
}

This pattern meant I never had to write if ($habit->getHousehold() !== $user->getHousehold()) in controller code. The voter enforces the boundary. The template's architecture rules prevented me from putting access logic in controllers — phpat would have flagged it.

The Quality Stack in Practice

The template shipped with 10 PHPStan extensions configured at level max, Rector with PHP 8.4 + Symfony 8 rulesets, ECS for coding standards, Infection for mutation testing, and CaptainHook running checks on every commit.

Here's what that actually caught during SmartHabit development:

PHPStan caught a nullable type I'd missed. A query method returned ?Household but I was calling methods on it without a null check. The AI-generated code handled the non-null path correctly and silently dropped the null case. PHPStan flagged it at level max. Without it, that's a production NullPointerException waiting for a user who somehow ends up without a household association.

Infection proved a timing test was hollow. I had a test for the MAD calculation that passed but didn't actually assert the right output — it asserted that the result was not null. Infection mutated the return value and the test still passed. I rewrote the test to assert the specific timestamp. MSI for the notification domain ended up at 93%.

Rector caught a PHP 8.4 pattern I'd written in PHP 7 style. The property hooks feature was available and Rector flagged the old-style getter/setter pair as replaceable. Not a bug, but it matters: the codebase looks consistent, regardless of which lines Claude Code wrote and which I wrote.

CaptainHook blocked a commit with ECS violations. I wrote a quick helper function manually during a debugging session, formatted it however, and tried to commit. Hook ran ECS, failed, auto-fixed, and I had to stage the fix before the commit went through. That's the intended behavior — and it works the same whether the code is human-written or AI-generated.

The Test Numbers

233 unit and integration tests, 38 Playwright end-to-end tests. 93% mutation score index on the backend.

The E2E tests cover the critical paths: habit creation, completion logging (including the optimistic UI rollback), household member invitation, and notification preference configuration. They run against a real Docker environment in CI — not mocked, not stubbed. The Playwright suite runs in the CI workflow after the backend quality checks pass, so a PHPStan failure won't waste time running E2E tests.

Five workflows total:

Backend quality (PHPStan, ECS, Rector)
Frontend linting and type checking
PHPUnit + Infection
Playwright E2E
Deploy to production (Hetzner via OpenTofu, only on push to main)

Push to main triggers a deployment. Docker health checks prevent the new containers from going live if they fail the health endpoint. I've had it block a broken deploy twice during development. That's the system working.

What Was Hard

The PWA offline queue was the most difficult part. The service worker needs to queue habit completions when offline, replay them when connectivity returns, and handle conflicts if another household member logged the same habit in the meantime. The conflict resolution is simple — last-write-wins with a server timestamp — but getting the queue to replay reliably across page reloads, browser restarts, and varying network conditions took more iteration than anything else.

The Capacitor integration for iOS was a close second. The native shell is thin, but APNs requires certificates, entitlements, provisioning profiles, and a specific Symfony bundle configuration that doesn't have great documentation. I spent a full afternoon on that alone.

The Template's Return on Investment

The template made SmartHabit Tracker's quality consistent from the first commit. I didn't configure PHPStan for this project — it was already configured. I didn't write CI workflows — they were already there. I didn't set up mutation testing — it was already passing on an empty codebase.

That meant every hour I spent on SmartHabit Tracker went toward product decisions and domain logic, not tooling setup. And the tooling caught real bugs — not theoretical ones, not "this would be a problem at scale" ones. Actual defects that would have reached production.

If you want to build something similar:

github.com/tony-stark-eth/smarthabit-tracker

The quality stack from post 1 is fully intact. Fork it, adjust the habit domain, keep the guardrails.

Found this useful? Follow me on my blog for more.

My Opinionated Symfony + SvelteKit Template with 10 PHPStan Extensions

Kevin — Sun, 22 Mar 2026 20:04:57 +0000

Originally published on my blog

Every time I start a new PHP project, I face the same ritual: 30 minutes of configuring PHPStan, 20 minutes on ECS, another hour on CI pipelines, Rector setup, mutation testing baseline, Doctrine configuration, Docker multi-stage builds. I've done this enough times that I know exactly what I want — and I got tired of rebuilding it from scratch.

So I built a template. Not a skeleton — an opinionated, production-ready starting point with every quality tool pre-configured at the level I actually use in production.

The repo is at github.com/tony-stark-eth/template-symfony-sveltekit.

What's in the Stack

Backend: PHP 8.4, Symfony 8, Doctrine ORM, FrankenPHP in Worker Mode.

Frontend: SvelteKit 2 with Svelte 5, TypeScript in strict mode, Tailwind 4, Bun as the package manager and runtime.

Database: PostgreSQL 17 with PgBouncer in Transaction Mode. PgBouncer is there from day one because adding it later to an existing setup is more painful than people expect — especially if your code uses SET commands or advisory locks that don't survive connection reuse. Better to design around it early.

Infrastructure: OpenTofu modules for Hetzner. Deploying to a Hetzner VPS is cheap and simple; the modules handle the server provisioning, DNS, and firewall setup.

Same-Origin Architecture

The template puts both the PHP API and the SvelteKit frontend behind a single Caddy reverse proxy on a single domain. API routes go to FrankenPHP, everything else goes to the SvelteKit server.

This means no CORS headers, no SameSite=None cookies, no cross-origin authentication complexity. A session cookie set by Symfony is readable by SvelteKit's server-side rendering on the same origin. The SvelteKit load function calls fetch('/api/...') — no base URL configuration, no environment variable juggling per environment.

The tradeoff is that both services must be deployed together. For a product with separate teams on frontend and backend, a split origin might make sense. For a solo developer or a small team shipping one product, Same-Origin keeps the operational surface small.

The PHPStan Setup

PHPStan is configured at level max with 10 extensions:

phpstan-strict-rules — the extensions PHPStan ships but doesn't enable by default
phpstan-deprecation-rules — surfaces deprecated API usage before your dependencies drop them
phpstan-symfony — understands Symfony's service container and DI conventions
phpstan-doctrine — knows about Doctrine entity mappings and query builder types
phpstan-phpunit — type inference inside PHPUnit tests
shipmonk/phpstan-rules — ~40 additional rules covering enum exhaustiveness and exception handling hygiene
voku/phpstan-rules — operator type safety (no more implicit int/string coercions)
tomasvotruba/cognitive-complexity — hard limit of 8 per method, 50 per class. If PHPStan fails because of cognitive complexity, the method needs to be split, not the limit raised.
tomasvotruba/type-coverage — 100% type coverage required. No untyped property, no missing return type.
phpat/phpat — architecture tests as code. Define which layers can depend on which, and PHPStan enforces it on every run.

That last one is underused in PHP projects. With phpat, I can write rules like "controllers may not depend on Doctrine repositories directly" and get a static analysis failure — not a code review comment, not a runtime error — if that boundary is crossed. The template ships with a basic ArchitectureTest.php that you extend as the project grows.

Mutation Testing

PHPUnit plus code coverage tells you that your tests run. Infection tells you whether they actually test anything.

Infection works by mutating the source code — flipping a > to >=, removing a return, changing a true to false — and then running your test suite against each mutation. If a test fails after mutation, the mutation is "killed." If nothing fails, the mutation "escapes," meaning your tests don't cover that behavior.

The template requires a Mutation Score Indicator (MSI) of at least 80%, and Covered MSI of at least 90%. These aren't arbitrary numbers — 80% MSI means that 4 out of 5 possible mutations to your code break at least one test. At lower thresholds, you'll find test suites that have 90% line coverage but barely prove anything about behavior.

Infection runs as part of CI, after PHPUnit, only when the unit test suite passes.

The Other Quality Tools

Rector runs with PHP 8.4 and Symfony 8 rule sets. Early returns, enum usage, typed properties, dead code removal — the code in the repository always reflects current PHP idioms regardless of whether a human or an AI wrote it. Rector is configured to auto-fix, not just report.

ECS (Easy Coding Standard) handles formatting and coding style. It runs before PHPStan in CI and fails the build before the slower analysis even starts. On commit, CaptainHook runs ECS and PHPStan locally so you know before you push.

CaptainHook rather than GrumPHP for git hooks. GrumPHP has historically had issues with how it handles the hook environment; CaptainHook is simpler and its configuration is more explicit.

CI/CD

Two workflows cover the full stack:

ci.yml runs on every push and PR: ECS → PHPStan → Rector check → PHPUnit with path coverage → Infection. The order matters: formatting and static analysis are fast and fail early; mutation testing is slow and only runs when everything else passes.

ci-frontend.yml covers the SvelteKit side: ESLint → Svelte Check → Bun build. This runs in parallel with the PHP pipeline.

Two additional workflows use Claude Code. claude-update.yml runs on a biweekly schedule and opens PRs for dependency updates — both Composer and npm — with commit messages that explain what changed and why it matters. claude-review.yml posts an automated code review on every PR. Neither replaces human review, but they catch the obvious things before a human spends time on them.

Claude Code Integration

The template ships with a CLAUDE.md and a .claude/ directory that encodes the architecture decisions and coding conventions. This is the same approach I described in my previous post about 10x output with quality: you document the decisions once, and then every Claude Code session starts with that context already loaded.

The .claude/ guidelines cover things like: how to structure Symfony services, which Doctrine patterns to use, how the Same-Origin routing works, which PHPStan rules are intentional versus suppressible. If you use Claude Code to build on top of this template, it already knows the constraints.

What This Template Is Not

It's not a microservices framework, not a monorepo setup, and not designed for projects where the frontend and backend are owned by separate teams. It's a solid starting point for a single product, built by a small team that wants quality tooling from day one without spending a week configuring it.

If you want the full context for how I built this — and why the quality stack matters more than the AI that helped me write it — read How I 10x My Output as a Senior Developer Without Sacrificing Code Quality.

Fork it, run docker compose up, and you have PHPStan level max passing from commit zero.

Found this useful? Follow me on my blog for more.

How I 10x My Output as a Senior Developer Without Sacrificing Code Quality

Kevin — Sun, 22 Mar 2026 20:04:53 +0000

Originally published on my blog

Last weekend I shipped two repositories from scratch: an opinionated full-stack template for PHP 8.4 + Symfony 8 + SvelteKit 2, and a complete habit tracking application built on top of it. 51 commits, 6 GitHub Actions workflows, 10 PHPStan extensions configured at level max, Docker multi-stage builds, OpenTofu infrastructure — all passing CI.

That's not a normal weekend.

I'm a senior developer with strong opinions about code quality. I don't ship code without static analysis at the highest level, mutation testing, architecture tests, and automated formatting. None of that changed. What changed is how I get there.

The Bottleneck Was Never Thinking

Here's what I realized: most of my time as a senior developer was never spent on architecture decisions or solving hard problems. It was spent on everything around those decisions. Writing boilerplate. Configuring tools. Looking up API signatures. Writing the 14th PHPUnit test that follows the same pattern as the previous 13. Fixing YAML indentation in CI workflows.

These tasks require knowledge to do correctly, but they don't require creativity. They're the tax you pay for building things properly.

AI code assistants eliminate that tax.

The System

My workflow has three layers, and the order matters.

Layer 1: I make the decisions. Architecture, tech stack, data model, which tools to use and why, what the quality standards are. This part is entirely human. I spent hours in a planning session defining the template's quality stack — which PHPStan extensions to include, why CaptainHook over GrumPHP, why Same-Origin architecture instead of separate API and frontend domains, why PgBouncer in transaction mode needs DISCARD ALL. These are decisions that require experience and judgment. No AI made them for me.

Layer 2: I write the spec, the AI writes the code. Once the decisions are made, I document them in a format Claude Code can execute against. A CLAUDE.md file that defines the project context and hard constraints. A .claude/ directory with coding guidelines, testing rules, and architecture conventions. When I tell Claude Code to create a phpstan.neon with level max and 10 specific extensions, it doesn't need to figure out which extensions — I already made that call. It just needs to produce correct configuration. That's a task it handles well.

Layer 3: I review everything. Every line Claude Code produces goes through my review. Not a rubber stamp — an actual review where I check for the same things I'd check in any PR. Does the Doctrine mapping make sense? Is the Caddyfile routing correct for Same-Origin? Are the CI workflow dependencies right so PHPStan runs before tests? This is where senior experience compounds: I catch issues that the AI doesn't know are issues, because they require understanding how things interact in production.

Why the Quality Stack Is the Multiplier

Here's what most "AI makes me 10x productive" posts get wrong: they focus on the AI and ignore the safety net.

If I used Claude Code without PHPStan at level max, without mutation testing, without architecture tests — I'd ship faster, sure. I'd also ship bugs. AI-generated code is plausible code. It looks right. It often is right. But "often" is not "always", and the gap between those two words is where production incidents live.

My quality stack is what turns AI-assisted speed into AI-assisted confidence:

PHPStan at level max with 10 extensions catches type errors, forgotten exceptions, cognitive complexity violations, and architectural boundary crossings. If Claude Code generates a service that accidentally depends on an infrastructure layer, phpat flags it before I even see the code.

Mutation testing via Infection proves that tests actually test something. It's easy to write tests that pass but don't assert meaningful behavior — especially when an AI writes them. Infection mutates the code and checks if tests catch the change. MSI below 80% means the test suite is decorative.

Rector with auto-fix rules ensures the code follows PHP 8.4 idioms regardless of who — or what — wrote it. Early returns, type declarations, dead code removal. The code that lands in the repository always looks like my code, not like "AI code."

CaptainHook git hooks run ECS and PHPStan on every commit. Even in a fast-moving session with Claude Code, nothing bypasses the quality gate.

The result: I move fast, but the guardrails are always on. The AI proposes, the quality stack validates, and I make the final call.

What AI Is Bad At

I want to be specific about where Claude Code fails, because the honest version of this story matters more than the hype version.

It doesn't question your decisions. If I tell it to implement something architecturally wrong, it will do it confidently and correctly — the wrong thing, done well. The CLAUDE.md helps here because it encodes my decisions, but it can't encode judgment I haven't articulated yet.

It loses context in long sessions. After 30+ back-and-forth iterations, Claude Code starts forgetting constraints from earlier in the conversation. I've learned to keep sessions focused: one feature, one file group, then start fresh.

It generates plausible-but-wrong configuration. A Caddyfile that looks correct but has the routing order wrong. A phpstan.neon that includes an extension that conflicts with another. A compose.yaml where the PgBouncer service connects to the wrong network. These are exactly the bugs that my review step catches — and exactly why the review step isn't optional.

It can't do research. When I needed to decide between ntfy and Firebase for push notifications, Claude Code couldn't evaluate the tradeoffs with real-world experience. It could list pros and cons, but it couldn't tell me that Firebase's free tier has a notification limit that would matter at 500 households. That insight came from my own experience.

The Numbers

What used to take me a full sprint (two weeks) to set up — Docker configuration, CI pipeline, quality tooling, frontend scaffolding, infrastructure skeleton — I now complete in a weekend. Not because the AI does it for me, but because it handles the implementation while I focus on the decisions.

The template repository has: a multi-stage Dockerfile with FrankenPHP, three compose files (dev/override/prod), 10 PHPStan extensions configured and passing, Rector with PHP 8.4 + Symfony 8 rulesets, ECS for coding standards, PHPUnit 13 with path coverage, Infection for mutation testing, CaptainHook for git hooks, 6 GitHub Actions workflows, OpenTofu modules for Hetzner deployment, and a full .claude/ directory with guidelines.

Configuring all of that manually — even for someone who's done it before — takes days. With Claude Code executing against a clear spec, it takes hours.

Try It Yourself

The template is open source and designed to be forked:

github.com/tony-stark-eth/template-symfony-sveltekit

Every quality tool is pre-configured. Every CI workflow is ready. Fork it, run docker compose up, and you have a full-stack project with PHPStan level max from commit zero.

The CLAUDE.md and .claude/ guidelines are included — so if you use Claude Code, it already knows how to work with the codebase.

If you're a senior developer feeling skeptical about AI tools: I was too. The trick is not to let the AI drive. You drive. The AI is the engine. And the quality stack is the brakes.

Found this useful? Follow me on my blog for more.