Skip to main content

Positioning

Who Kiln is for, what it refuses to be, and the lens we use to pick features.

The shift: authorship has flipped​

The old model was simple. Humans wrote code, machines ran it. That model is breaking. Agents now write most of the code, and the highest-output engineers spend their day steering them. Software creation has become specification and orchestration, not typing.

That creates a new bottleneck. If you didn't write the code, you understand it less, which makes reviewing it harder, and you're still the one accountable for quality, architecture, correctness, and shipping. The center of the job is moving from writing code to understanding, validating, and steering it.

Today's tools help generate code. They don't solve accountability. IDE agents, CLI agents, and web builders are all useful, and all optimized for output. None are built around the harder problem: how a human stays in control of a fast-moving codebase they didn't fully author. Kiln is the IDE rebuilt for that.

The call: built for directors, not typists​

The vibecoder-vs-professional question is a false choice. The real split is between people who type code and people who direct and read it, and the second group is growing on both ends: newcomers who never learned git, and senior engineers who now spend their day reviewing agent output. Kiln is for directors.

That resolves the tension cleanly:

  • No knowledge is required that the app could carry for you. Version control speaks plain language at the surface ("checkpoint", "share", "rewind"), with the real git vocabulary one hover away — teach, don't hide. Terminals exist but are spun up for you. A vibecoder is never stranded.
  • Nothing is dumbed down. The full file tree, real zsh, real diffs, and real model output are always reachable. A professional never feels the guardrails.

The squad is the clearest expression of this: you don't ask Kiln to help you type — you watch named agents read, propose, and explain, and you decide what lands.

The three bets​

Kiln is built on three bets about what an IDE is for once agents write the code.

  1. Code as documentation. If humans review more than they write, the interface for reading code has to get dramatically better. Kiln treats presentation as a first-class problem, borrowing from typesetting, layout, and information design to make files and architecture legible.
  2. Plan, execute, validate, ship in one path. Start from a spec, test the plan, implement, validate locally, then ship. Today that's scattered across docs, GitHub, terminals, CI, and PR tools. Kiln makes it one coherent workflow, which helps experts move faster and lets less technical contributors take part without mastering git first.
  3. An orchestrator, not a chatbot. The agent isn't a sidebar chat box. It manages a plan, delegates subtasks to the right agents, picks models, reviews progress, and keeps hunting for issues across the whole change. A collaborator embedded in the workflow, not a tool you drive by hand.

The USP, in one sentence​

A native macOS editor where on-device intelligence is ambient and plural — a squad of visible agents working your project alongside you — rather than a chat box bolted to a buffer. It's the substrate the orchestrator bet runs on.

Three properties make this defensible rather than a feature checklist:

  1. On-device first. Apple Foundation Models make inference free and private, so Kiln can afford to think about your project constantly, unprompted. Cloud-metered tools can't copy the cadence, only the features.
  2. Plural and visible. Agents have names, presence, and personas. The multiplayer feel — dots in the sidebar, a roster, a feed — makes AI work reviewable and social instead of modal and hidden.
  3. Reading first. The calm surface (reading mode, breathing sections, margin notes) is the human's half of the deal: Kiln optimizes the reviewing experience because reviewing is the job now.

The feature test for anything new: does it only work because inference is free, local, and always on? If a cloud-metered VS Code extension could do it identically, it's table stakes at best — schedule it accordingly.

A second lesson from the research: the features people love most in IDEs — local history, scratch files, structural search — are the ones they discover years late, because they have no visual surface and get found socially, not through the product. Kiln's answer is the squad: proactive agents are a discoverability mechanism, surfacing the right capability at the moment of need instead of hiding it behind a command palette.

What Kiln refuses to be​

  • Not an extension platform. The squad subsumes the long tail; the short list of genuinely table-stakes jobs gets built natively.
  • Not cross-platform. macOS 26+, Apple Silicon, and every native affordance we can reach (below).
  • Not a chat-first product. Potter (the chat) is a side panel; the project task graph and the squad are the primary AI surfaces.

Mac-native affordances worth building on​

Ranked by how directly each amplifies the USP:

  1. App Intents + Shortcuts — "Hey Siri, set the squad on the project." Squad runs and pair invites as system-level intents; Kiln becomes automatable from outside itself.
  2. UserNotifications — squad activity surfaces as native notifications with action buttons (approve a proposal from the banner) when the panel is closed or the app is backgrounded. The presence layer beyond the window.
  3. Touch ID / LocalAuthentication — biometric approval for agent actions that touch disk or run commands. Trust theater that is also real trust.
  4. MenuBarExtra — a glanceable squad status in the menu bar: who's working, what landed while you were away.
  5. Core Spotlight — index project symbols/todos so system search finds "where do we parse proposals" inside your project.
  6. Foundation Models (already shipped) — the free-inference substrate everything above leans on.
  7. Quick Look, Services, drag-from-Finder — politeness features; do them when touched, don't schedule them.