A Self-Healing Frontend Pipeline: From API Change to Pull Request

When I took over the frontend of a new radiology information system, the first weeks went into the foundation: a clean project setup and strict lint rules from day one. One decision from that time paid off more than any other: the frontend does not write its own API code. It generates it.

The API as a package

The backend describes every endpoint with decorators and generates an OpenAPI spec from them. That spec ships as an npm package, and every merge to master that changes the API publishes a new version.

On the frontend, that package is the single source of truth. From it we generate the types, the fetch functions and the mutation hooks. Nobody writes a response shape by hand, and every API change has a version number.

I presented the approach to the team and discussed it with our architects. Nobody had objections, and it was not hard to set up.

Breaking changes become build errors

The real payoff came later. When the backend renames a property or removes a type, the regenerated client changes with it. The TypeScript check in the pipeline then fails exactly where the frontend still uses the old shape.

A breaking API change no longer shows up as a bug in QA or production. It shows up as a failed build, with the file, the line and the missing type.

Phase 1: the pipeline fixes itself

A failed build that only lives in a pipeline log is easy to ignore. So at the end of January I added a step to the pipeline. When the build failed after an API update, it filed a Jira ticket with the compiler output and started an AI coding assistant (Aider) right there in the build. The assistant changed the code, the script ran lint and the type check, and only when both passed did it commit and open a pull request.

From February to April this produced seven merged fixes. It also showed the weak spots: the same error could open two pull requests, and once a helper file ended up in a commit. And it was a second AI setup to maintain, next to the coding agent the team already used for regular tickets.

Phase 2: the ticket goes to the agent

So in May I moved the fix out of the pipeline. The pipeline now does one job: it files the ticket with the compiler output and hands it to the AI coding agent I built. The agent picks it up like any other ticket, works with the same repository standards as the team, and opens a pull request.

A developer reviews the pull request and merges it, like every other change from the agent.

At the end of June a failing test run was reported like a broken build, and for one week the tickets said only "exit code 1" instead of showing the compiler output. The agent rejected all eleven of those tickets instead of guessing a fix. Limiting the handoff to real TypeScript build errors fixed that.

The numbers

• 35 tickets filed by the pipeline since February
• 12 merged fixes from the AI, seven in phase 1 and five in phase 2
• 4 of them closed within 20 minutes of the ticket

The full loop today:

1. A backend change alters the API and publishes a new spec version.
2. The frontend regenerates its types and API hooks.
3. The TypeScript check fails where the code no longer matches.
4. The pipeline files a Jira ticket with the error.
5. The agent fixes the code and opens a pull request.
6. A developer reviews and merges.

Why it works

None of these pieces are new. OpenAPI generators, type checks and ticket automation have been around for years. The value comes from chaining them so that each step produces exactly the input the next one needs. A typed client turns API drift into compiler errors. Compiler errors are precise enough to put into a ticket. And a precise ticket is something an agent can actually solve.

If you start a new frontend today, generate your API client from day one. It costs little at the start, and everything else builds on it.