Why I Killed My One-Shot AI Coding Pipeline"

Grounded / Real Inflated / Uruttu

60% real

40% uruttu

article Original Content

I built a software factory for Claude Code and rebuilt it from scratch.

Here's what I learned:

My first version tried to automate everything inside one giant workflow.

Halfway through implementing a feature, I realized the plan needed changing.

Or I'd want to review an architectural decision before continuing.
Or fix one small task without waiting hours for the entire pipeline to finish.

So I rebuilt Squid around three simple stages instead:

𝟭/ 𝗣𝗹𝗮𝗻𝗻𝗶𝗻𝗴

Better plans matter far more than better prompts.

And this is where humans still matter most.

I start with a rough feature idea.

Then I "grill" it with an LLM to uncover:

• Missing requirements
• Weak assumptions
• Architectural gaps
• Edge cases

The output is:

• A polished specification
• ADRs
• A project glossary
• A list of implementation tasks

𝟮/ 𝗜𝗺𝗽𝗹𝗲𝗺𝗲𝗻𝘁𝗮𝘁𝗶𝗼𝗻

I stopped thinking about this as one coding agent.

Instead, it's a conversation between two roles:

• Software Engineer
• Tester

One writes the code.

The other tries to break it. They iterate until the task is complete.

For larger changes, I let the whole feature run autonomously. For quick fixes, I only execute a single task.

The workflow adapts to what I need.

𝟯/ 𝗥𝗲𝘃𝗶𝗲𝘄

This was probably the biggest surprise...

Reviews should happen against the pull request diff rather than the entire repository.

Once I changed that, review quality improved dramatically.

I also merged two roles into one.

Instead of having a product manager and an architect, I now have a product architect.

Coding agents don't suffer from the communication gaps humans do.

Keeping product intent and architectural reasoning together produces much better feedback.

After review comes:

• CI.
• Formatting.
• Linting.
• Integration tests.
• Regression checks.

If anything fails, a new implementation task is created automatically.

Here's the gist:

Everyone talks about agent loops.
But loops are only one part of a software factory.

The actual value comes from everything around them.

This is the architecture I've been gravitating towards while building Squid.

Check it out here: https://lnkd.in/dejXAQBc

So far, it's producing some of the cleanest AI-generated code I've worked with.

P.S. What's been your biggest bottleneck when building with coding agents?

verified Validated Content

I checked out the actual repo behind the link (it resolves to github.com/iusztinpaul/squid) and compared it against what the post describes.

What checks out:

The plugin is real and is exactly what's described: a Claude Code plugin that turns a feature spec into a reviewed PR through a multi-agent pipeline, with two human gates: plan approval and final merge.
The implementation loop matches: for quick fixes there's a single-task command, and for full features there's an end-to-end autonomous pipeline — "For a quick single change, run /squid-implement-task... the same SWE ↔ Tester loop, no planning or review pipeline."
The "review against the diff, not the whole repo" claim is accurate — the PR Reviewer agent is explicitly scoped to catch issues in the diff.

Where the post oversimplifies or diverges from the repo's own README:

"Three stages" undersells it. The actual pipeline is a 5-agent chain — PM → SWE → Tester → PR Reviewer → On-Call — not three. The post's Planning/Implementation/Review framing is a reasonable narrative grouping, but it collapses two extra named agents (PR Reviewer and On-Call are separate) into "Review."
The "merged PM + architect into product architect" claim isn't reflected in the current repo. The README lists the planning role simply as "PM" (product-manager), with no separate "architect" role and no mention of a merger. That could be true of an earlier internal iteration that isn't documented publicly, but as written, it's not verifiable from the repo itself.
ADRs and a "project glossary" as planning outputs aren't mentioned anywhere in the public README's description of what /scaffold or the planning stage produces. Possible they exist in the actual spec files, just not surfaced in the top-level docs.
Worth knowing for context: this is a very new, single-maintainer project — 1 star, 0 forks at the time I checked. "Producing some of the cleanest AI-generated code I've worked with" is a subjective, unverifiable claim, not something with external validation yet.

So the core architecture claims (spec-driven, two human gates, diff-based review, adaptive single-task vs. full-feature execution) hold up against the source. The "3 stages" and "PM+architect merger" framing reads more like the author's internal mental model than what's documented in the public repo — not necessarily false, just not independently confirmable from what's published.