Skip to content
About

MiQ Digital · 2026

3 min read

TESS: shipping UI without an engineer

An AI IDE framework that let product analysts deliver micro-frontend UI changes end to end, cutting combined frontend and backend delivery time by 85%.

85%less delivery time

Every product team has the same small, humiliating bottleneck. An analyst needs one more field on a form. It is a genuinely tiny change. It still takes three weeks, because it has to become a ticket, then survive a sprint boundary, then get a frontend engineer, then a backend contract, then a review.

The engineering is not the expensive part. The queue is the expensive part.

TESS came out of asking a question I could not get a good answer to: if an analyst can already describe the change precisely, and an AI IDE can already write that code, what exactly is the engineer in the middle protecting us from?

The honest answer was: correctness, contracts, and the release path. Not typing.

Delivering one input form

End to end, request to production.

  • Ticket + triage

    Analyst → PM

    6h

  • Frontend queue wait

    Sprint boundary

    40h

  • Frontend build

    FE engineer

    10h

  • Backend contract

    BE engineer

    12h

  • Review + QA

    Team

    8h

  • Release

    CI/CD

    4h

Total

80h

Against baseline

baseline

The queue wait is the real target. Most of the saving is work that never gets scheduled, not work done faster.

What we built instead of a ticket queue

The framework is less about the IDE than about what surrounds it. An analyst working alone with an AI assistant produces plausible code with no guarantee it is correct or deployable. The value is in making the guardrails do the job the engineer's attention used to do.

Analyst drafts

The analyst works in the IDE against a scaffolded micro-frontend, describing the change in the domain language they already use. They are not asked to learn React. They are asked to be precise about the requirement, which they already were.

The part that was not software

The framework was maybe half the work. The other half was upskilling product analysts on SDLC and CI/CD: branches, pull requests, what a failing pipeline means, why you do not merge on a Friday afternoon.

That was the genuinely hard part, and it is the part most "AI will let anyone build software" pitches skip. An AI IDE removes the syntax barrier. It does not remove the need to understand that software is a thing you operate, not a thing you finish.

What changed
Analysts originate and own micro-frontend UI changes end to end.
What did not
Engineers still review every pull request. Nothing merges unreviewed.
Blast radius
Micro-frontend boundaries keep a bad change scoped to one surface.
Hardest part
Teaching CI/CD literacy, not teaching code.

What I would watch next

The risk in this model is not bad code, which guardrails catch. It is ownership drift: a surface built by someone who has since moved to another team, with no engineer who considers it theirs. The queue we removed was also, accidentally, an assignment mechanism.

If I were extending this, that is the problem I would solve next, before adding a single new capability.