Back to blog

Libraries Don't Have a Design Phase

For a long time, H·AI·K·U had one studio for "software." You'd kick off an intent to build a logging library and the lifecycle would helpfully route you through a product discovery phase and a UX design phase on your way to writing code. You'd stare at the prompt. "What's the user journey for log.info()?" Nobody wants to answer that question because it's not a real question.

We were telling ourselves it was fine. Every stage is "optional-ish." You can skip phases. You can customize. The template is just a starting point.

The shape of the mismatch

The software studio's stages were: inception, product, design, development, security, operations. Beautiful for a web app. Works fine for a SaaS backend. Reasonable for a mobile app. Actively wrong for anything else.

Libraries

The API is the product

There's no separate discovery step where you figure out what users want. Consumers want functions with well-chosen signatures and an error model they can reason about. Slot that into the design stage and you get mockups for a thing that has no UI.

Games

The fun gate has no equivalent

Game development has a binary "is this fun" question that has to be answered before you commit production resources. Skip it and you build six months of assets for a core loop that doesn't work. The industry already named this — the prototype trap.

Hardware

Manufacturing happens once

Hardware has no operations phase at the end. It has manufacturing — one-shot, enormously expensive, and whose main risk is FCC compliance you didn't do upstream. The software studio's vague "security" stage was a category error.

The shared error

One shape, three wrong fits

Each of these had its own lifecycle. We kept telling ourselves the software studio was "flexible enough." It wasn't — it was a web-app template wearing a universal label.

So we had a shape that only fit apps. And we'd been trying to convince ourselves that the shape was "flexible enough" for everything else.

Lifecycles, not roles

Here's what I missed for a long time. Specialization in AI-assisted workflows isn't about roles. It's about lifecycles.

The software industry spent decades arguing about roles. "Full-stack or specialist?" "Product manager or product engineer?" "Where does QA fit?" Most of that debate assumed a fixed lifecycle: requirements → design → build → test → ship → operate. What changed between arguments was who sits in which chair.

When the implementation bottleneck collapses — when an AI can write the code, draft the spec, sketch the wireframe, and run the tests — the role question matters less. What matters is whether the lifecycle you're running matches the artifact you're making.

A library is not a product that happens to be a library. It's a contract with consumers who will depend on it for years. Its lifecycle is API-shape-driven, not user-journey-driven.

A game is not an app that happens to be fun. It's an experience whose validation has to happen against real players before you scale content. Its lifecycle needs a fun-gate, and polish isn't "we'll clean it up later" — it's where games become great.

A hardware product is not a software product with a casing. It's a one-shot manufacturing commitment with regulatory constraints that touch every layer. Its lifecycle has to front-load compliance because retrofits cost 10x.

Different lifecycles. Same orchestration machinery underneath — same workflow engine, same review gates, same quality enforcement, same persistence. But the stage sequence, the artifacts produced at each stage, the review agents, the review-gate shapes: those come from the artifact, not the tooling.

Four studios, not one

So software became application-development (slug appdev, alias software for back-compat), and three siblings moved in next to it.

appdev

Apps with users in them

Inception → product → design → development → security → operations. The default when you're building a thing people click on.

libdev

Libraries are a contract

Inception → development → security → release. Inception folds in the API surface because that's where the contract lives. Release publishes to a registry; there's no on-call rotation.

gamedev

Fun is a hard gate

Concept → prototype → production → polish → release. Prototype is binary: fun or bust. Polish gets its own stage because "tune later" has never once produced a game that felt great.

hwdev

Compliance constrains everything

Inception → requirements → design → firmware → validation → manufacturing. Requirements captures compliance upfront because the FCC doesn't care when you noticed. Manufacturing is one-shot.

The existing software directory stays put on disk. Intents with studio: software still resolve cleanly — aliases are indexed alongside canonical names and slugs, so you never have to migrate anything. You can type appdev, application-development, or software. All three land in the same place.

The principle

Here's the takeaway, if you're designing AI-assisted workflows of your own.

The same orchestration machinery can drive every studio — same workflow engine, same gates, same quality enforcement. What changes is the sequence and the artifacts each stage produces, because those come from the thing you're building, not the tools you're using.

When your template starts needing "skip this phase" instructions, the template is telling you something. Libraries don't have a design phase. Games don't have a development-that-ends-at-deploy phase. Hardware doesn't have an operations phase at the end. Build each lifecycle for what it actually is.

Everything else is retrofit.