Lutin

November 2022 → now · one stubborn idea

Why I Built Lutin Three Times?

Illustrated timeline from writing software by hand through AI-assisted coding to agentic engineering
The idea stayed. The developer bottleneck kept moving.

First build · before AI coding

Limited by: “How do I build this?”

I built the first Lutin as a native macOS app. I still remember spending an hour figuring out how to make messages look like messages—and how to give them that little form.

Every interface detail began with learning how to build it.
The first native macOS Lutin chat interface

Second build · vibe coding

Coding +vibe,
everything else -vibe

Producing features became dramatically easier. But every new surface brought more infrastructure, releases, secrets, and maintenance.

Now I was limited by DevOps and codebase maintenance.

Inside the third build · capabilities

Exploring tools

Pi gives the model a place to work. Tools let it touch the codebase, tests, infrastructure, analytics, and releases.

Tools create capability. They don’t decide how the work should be done.
Pi harness
Codex Playwright Storybook
Infisical Railway GitHub
Tauri PostHog Cloudflare

Inside the third build · workflows

Skills make good work repeatable

For example, the Lutin UI review skill turns a vague request into a repeatable, verifiable workflow.

The skill doesn’t replace judgment. It assembles the right judgment, context, and tools.
lutin-ui-design-reviewRequest → evidence
  1. 1
    Ground in policy

    Read the design system and document authority.

  2. 2
    Trace the real UI

    Inspect the changed component, callers, and production composition.

  3. 3
    Review in Storybook

    Compare focused and full compositions across themes and viewports.

  4. 4
    Exercise with Playwright

    Check responsive, keyboard, and interaction states.

  5. 5
    Verify and report

    Run type and interaction checks; return findings and residual validation.

Inside the third build · constraints

Policies encode intent and proof

A policy is more than a one-line rule. It connects an architectural intent to enforcement and the evidence a change must leave behind.

Agents can move fast because the repository catches boundary violations.
# Engineering policies

## Dependency direction
Intent: Commands are transport adapters.
Rule: `runtime/` and `platform/` cannot add
      dependencies on `commands/`.
Shared behavior: Move it behind the crate or
                 package that owns its semantics.
Proof: `check:dependencies` + `check:architecture`

## Cross-host contracts
Intent: Align desktop, mobile, and cloud without
        pretending every host is identical.
Rule: One fixture under `fixtures/runtime-conformance/`.
Capabilities: Publish exactly what each executable
              registry provides.
Proof: Every affected host consumes the fixture;
       mismatches fail verification.

Third build · agentic engineering

Agentic engineering coined!

Agents could carry bounded work across the project. What began as a gigantic refactor became Lutin’s third rewrite—across desktop, mobile, and a cloud runtime.

The conclusion

So why three builds?

It enabled me to build something I never thought I could.