Everyone Is a Design Engineer Now

There is a check in my frontend that keeps an AI-proposed action from rendering unless a human approve handler is wired in. In the artifact registry, a quick-action artifact declares two required handlers, onApproveQuickAction and onDeclineQuickAction, and the required-handler check runs at compile time, so a surface that mounts proposals without both does not ship. I think about that line a lot, because nobody with the title designer wrote it, and nobody with the title engineer decided it. It is a policy, a UX decision, and a type constraint at the same time.

That collapse of roles is the real story of AI at work. Organizations used to ration expertise: functions owned the methods, the tools, the vocabulary, the approval paths. AI makes routine knowledge cheap to reach and recombine, so the scarce skill moves. Less knowing the answer inside one domain, more framing the problem, designing the system that finds it, and validating what comes back.

I call people who work this way design engineers, and the title on their badge is irrelevant. Part domain thinker, part system designer, part operator, part evaluator.

Concrete version. In our product, agents do not draw UI. They emit typed artifacts, and a registry decides what happens next. Nine artifact types exist today: chart, table, insight, task, report, quick action, insight edit, review, and a validated-procedure envelope. Every type declares four things: a Zod schema that validates the payload at runtime, a placement rule (inline in the chat bubble, or routed to the canvas panel beside it), a renderer, and the handlers a host surface must provide.

quick_action: {
  artifactType: 'quick_action',
  schema: StreamingQuickActionPayloadSchema,
  placement: 'canvas',
  renderer: QuickActionAdapter,
  requiredHandlers: ['onApproveQuickAction', 'onDeclineQuickAction'],
  defaultTitle: 'Quick Action',
},

The agent proposes. The registry decides whether it renders. Each artifact is wrapped in its own error boundary, so one malformed payload degrades one card instead of taking down the whole message. Against that single contract we have shipped 37 domain-specific cards for one support agent: statements, hardware returns, capital offers, escalations, integrations. The marginal cost of the 37th card was a schema, a component, and one registry line. The design work was never the pixels. It was the contract.

The dashboard side runs on the same idea. Every widget carries machine-readable metadata, what data it requires, what it can do, example queries, so an agent can choose widgets the way a developer chooses components. And each widget declares a dataStatus: real, calculated, or stub. Across the surface, 23 declare real, 11 calculated, and 10 admit to being stubs, each stub with a field spelling out exactly what data would make it real. Honesty as a schema field, because a widget that admits it is a placeholder beats a confident fake.

My sharpest lesson about what this discipline actually is came from a bug that never threw an error. Table artifacts reach our renderer through two paths: a live websocket stream, which delivers the raw snake_case payload, and a history reload, which rehydrates persisted metadata, also snake_case. The widget dispatch keyed off a camelCase field. Live sessions worked. Reloads missed the dispatch silently, and the fallback renderer took over.

So a validated-procedure card that looked right in every live demo came back as a generic data grid whenever anyone reopened the conversation. No crash, no console error, no failed test. The designed experience quietly downgraded for exactly the users who returned to rely on it. The fix was boring: a normalizer that detects the streaming envelope by its snake_case keys, runs a schema parse, converts, and logs a debug line when the parse fails instead of dying. The lesson was not: in AI systems, the failure mode of bad design is rarely a crash. It is a plausible fallback.

Whoever designs the system owns those seams: two payload shapes, a silent fallback, a schema that arbitrates. The job lives in the seams.

Scale the registry idea up and you get what I think an AI operating system should be. Our backend makes the same move: every agent on the platform is a declarative manifest, 16 of them, compiled through one pipeline with permission gates that fail closed. Nobody hand-wires an agent. The repo's contributor doc opens with the rule in bold: never build bespoke agents.

A foundation like this is what makes the design-engineer pattern safe at scale. A builder assembles from approved components. A business user runs a governed agent without touching implementation. A leader can see which systems exist and how they behave. Without it, capable people build anyway, in scattered notebooks, private automations, and disconnected vendor surfaces, and you get local productivity with systemic fragility.

AI generates plausible implementation detail faster than people can review it, which makes first-principles reasoning more valuable, not less. If you cannot reason from the objective, the constraints, and the actual mechanism, the system will hand you polished nonsense that is genuinely hard to catch. The stub labels exist for exactly this reason, and the only person who can demand that kind of admission is one who knows what real would look like.

The questions stay basic and have to be asked with discipline. What problem is this solving? What must not change? Who is accountable? What evidence would show it works? Which part should be automated, and which part stays deliberately human? Operational answers, not philosophy, and they decide whether an AI system becomes a durable capability or an impressive demo.

Expect more of your people to become builders: designing workflows, composing tools, evaluating model behavior inside their own domain. Make that safe with shared components, review gates, and clear data policy, and reward the people who improve the system of work, not only the ones who finish tasks inside it.

Team structure follows. The handoff model, where one group writes requirements and another disappears to build against them, is too slow for tooling that changes monthly. The teams shipping fastest for me mix domain experts and platform engineers around one shared contract surface, and the contract is the conversation.

Which leads to the hiring position I will defend: given the choice, I now take the domain expert who can write a schema over the fluent generalist who cannot. The schema is the new spec. In a world where AI writes most of the implementation, the people who define contracts shape the organization, and the people who cannot will be designed around. If that sounds harsh, notice that it was always true. AI just shortened the feedback loop.