Why build a domain-specific agent for front end tasks? (kombai.com)

Why not simply call it "specialist"? Are you trying to make some close connection to "Domain Specific Languages" somehow?

I'm okay with the fact that they've open-sourced their prompts. Not sure if someone would actually test it.

Real world design files are messy designers iterate, leave artifacts, create workarounds.

The fact that you're accounting for invisible elements and accidental shadows shows deep domain expertise.

This is exactly the kind of thing general-purpose tools miss because they assume clean inputs.

This broadly matches the theme of this post that Replit CEO posted yesterday: https://x.com/amasad/status/1950260314823397767.

Current AI coding tools don't seem to have any real impact on true development productivity/ efficiency yet.

Apparently you cannot just one-shot everything to production. who'd have thunk? :-)

Domain‑specific dev tools beat general ones because the latter never saw "domain" data.

LLMs did - they soaked up the entire public Python, JS, React universe during pre‑training.

So the marginal value of a “React‑only” model is thin.

I agree that bigger wins come from better retrieval, tool feedback loops, and planning on top of a powerful general model whose weights already contain some of today’s front‑end ecosystem's spine.

The idea sounds interesting enough. But, with SOOO much AI slop going all around in-the name of AI coding, I'm really weary of anyone who claims to generate "production-ready" code.

Can y'all find another word for high-quality code, please?

Re:domain-specific solutions inevitably outcompete general-purpose ones. Certainly not the case for coding agents.

Vertical software won because GUIs were scarce. General LLMs are winning because context is abundant.