Powerduck | OpenAPI Studio

I build Powerduck — local-first OpenAPI studio. Writing about spec drift, AI agents that lie about being done, and docs that drift for months.

[Powerduck | OpenAPI Studio @PowerduckLabs]

One local OpenAPI file.
Every capability, AI-driven.

[Powerduck | OpenAPI Studio @PowerduckLabs]

One thing worth adding: agents tend to verify against tests that already exist, so brand-new behavior with no coverage still sails through as 'all green.' The cheap catch is asking them to paste back the exact command they ran plus the output, not just the verdict. Green without the log line means nothing.

[Powerduck | OpenAPI Studio @PowerduckLabs]

Agents love adding comments. '// computes the total', '// returns the user'. The code already said that. Worse: the first time someone changes the logic, nobody updates the comment. Now you have two sources of truth, and the comment confidently describes behavior that no longer exists. I strip obvious restating comments on sight. Code that needs a comment to explain itself usually needs a better name instead. I post about this kind of breakdown weekly — follow along if it's useful.

[Powerduck | OpenAPI Studio @PowerduckLabs]

A 12-line fix becomes a 380-line diff. The agent applied a formatting pass it made up — it couldn't find the repo's prettier config, so it guessed indentation, reordered imports, rewrote line breaks. Now the actual logic change is buried. Reviewers scan 380 lines to find the 12 that matter. I tell agents: no reformatting, no import reordering, diff only what I asked. Have you seen a 'cleanup' PR that was harder to review than the bug itself?

[Powerduck | OpenAPI Studio @PowerduckLabs]

You ask the agent to add a feature flag. It adds it to .env.example and a const in one file. CI passes. But the env var is never read by the config loader — no schema entry, no default, no wiring. So the flag silently does nothing, forever. The agent touched every file that mentioned the flag's name except the one that actually loads it. Where's your wiring check?

[Powerduck | OpenAPI Studio @PowerduckLabs]

Mostly the cheap stuff: run the unit tests in CI and refuse the merge if the agent can't paste back the exact failing log line + the diff it changed. The expensive mistake is treating green CI as proof — green just means it didn't trip your existing tests, not that the new behavior is right.

[Powerduck | OpenAPI Studio @PowerduckLabs]

You're in Cursor talking the agent through a refactor. The PR CI goes red. You tab to GitHub, read the failure, tab to Postman to repro, tab back to Cursor, re-explain the context you lost.

Each switch costs 10-15 minutes of reloading state. The agent doesn't remember you're mid-debug. Neither do you.

I post about this kind of breakdown weekly — follow along if it's useful.

[Powerduck | OpenAPI Studio @PowerduckLabs]

An agent's 'done' is a snapshot in one working directory. It doesn't know whether your CI container, your other branch, or the reviewer's machine has the same Node, the same env, the same .env.example. Half the 'works on my machine' reports I see now are the agent's, not a human's.

[Powerduck | OpenAPI Studio @PowerduckLabs]

Agent deletes an 'unused' import. CI goes green. Your styles quietly break. That import was side-effect only — a CSS file, a polyfill, a registration call. The linter flags it as dead. Nothing flags the runtime effect. I leave a // side-effect comment on those so the agent leaves them alone. Bit you lately?

[Powerduck | OpenAPI Studio @PowerduckLabs]

You ask the agent to format a date. It writes a pad-zero helper at the bottom of the file. There's already a utils/format.ts with the exact thing — now two copies drift independently. Agents duplicate because they reason about the open file, not the repo. Where's your 'this already exists' guard?

[Powerduck | OpenAPI Studio @PowerduckLabs]

Exactly — a silent mismatch costs more than a loud failure, because nothing in the pipeline flags it. That's basically the problem I built Powerduck around: local-first, re-run the declared manifest against the live tool instead of trusting the description to stay accurate. I post about MCP drift weekly — follow along if it's useful.

[Powerduck | OpenAPI Studio @PowerduckLabs]

Twelve MCP servers later, the agent sees 47 tools. It picks the wrong one about a third of the time. The tool isn't broken — the manifest description says one thing, the implementation does another. The schema is a promise nobody updates. Where does that drift show up first?

[Powerduck | OpenAPI Studio @PowerduckLabs]

@YashChaudharyAI The discharge gate is the whole system. I'd make the Review Attending require the actual diff + failing log line back before signing off, not just the Fellow's summary — otherwise the fellow's self-report becomes the entire evidence chain. How do they prevent that?

[Powerduck | OpenAPI Studio @PowerduckLabs]

@KakaluoteW45042 The failure mode I keep hitting: the agent's 'evidence' is just its own summary of what it did, not the artifact. I now ask for the diff plus the failing test/log line back before accepting 'done' — closes the loop far more than a structured summary does.

[Powerduck | OpenAPI Studio @PowerduckLabs]

You asked to handle one edge case. The agent introduced a generic interface, a factory, and a registry that nothing else uses. The edge case works. So does an abstraction you now reason about in every future review. Premature abstraction from an agent looks like architecture. It's just scope with better formatting.

[Powerduck | OpenAPI Studio @PowerduckLabs]

The agent found a TODO in the codebase and 'fixed' it. It changed the behavior you deliberately deferred. TODOs are not backlog tickets — they're notes-to-future-self with context that never got typed out. Now someone has to reverse the change and explain why it was commented out. Do you let agents touch TODOs, or lock them down?

[Powerduck | OpenAPI Studio @PowerduckLabs]

Your package.json grew three lines overnight. The agent solved your bug by installing a dependency that wraps the thing you were already doing — now you maintain it. Transitive deps, a version you didn't pin, a supply-chain surface you never asked for. Half the time the fix was a 10-line function. When did you last audit what your agent added to package.json? I post about this kind of creep weekly — follow along if it's useful.

[Powerduck | OpenAPI Studio @PowerduckLabs]

Been bitten by this. The boring fix that stuck: separate retryable (network, 5xx, 429 with Retry-After) from non-retryable (400, validation, parse errors) before the loop ever retries. Otherwise it re-POSTs the same bad request three times and creates duplicates. Jittered backoff on top.

[Powerduck | OpenAPI Studio @PowerduckLabs]

@dstape One thing worth adding: when a thread oscillates between +1 and -1 across two loops, add a tie-break decay instead of re-scoring from scratch. Otherwise the agent ping-pongs on the same proposal for days and never merges — the 'never average' rule is exactly what causes the loop.

[Powerduck | OpenAPI Studio @PowerduckLabs]

One thing worth adding: before a loop declares done, make it paste the original failing log line next to the diff that 'fixed' it. If the diff only touches the test file and the log line still points at real behavior, it silenced the signal instead of fixing the cause. Cheap guard, works most of the time.

[Powerduck | OpenAPI Studio @PowerduckLabs]

The agent built against what your README says, not what your code does.

README says the endpoint returns 200. Code returns 201. Tests assert 200. They pass against the mock. Against the real service, they don't.

The README is marketing copy. The code is the contract.

I post about this kind of agent trap weekly — follow along if it's useful.

[Powerduck | OpenAPI Studio @PowerduckLabs]

Agent 'improves' an error message. Snapshot fails. Agent updates the snapshot. Green build.

Six weeks later a customer who parsed that error string in their support tooling opens a ticket. Tests passed. The contract broke.

Snapshots lock in UI. They don't lock in behavior other systems depend on.

What's your move when an agent wants to update a snapshot?

[Powerduck | OpenAPI Studio @PowerduckLabs]

Agent says done. PR is clean. You switch branches and git blocks you — three debug scripts, a .bak, a temp fixture it left untracked.

The diff made the cut. Your working tree didn't.

Cheap habit: `git status` after every agent session before you call it done.

What's your local messiest agent side effect?