# Kilby: a firmware engineer who never skips the hardware test

AI engineer for embedded teams. Assign a ticket like you would to a colleague: a bug, a feature, a driver. Kilby writes the code and tests it on your hardware. A human engineer reviews it before you get the pull request.

## Four jobs you can hand to Kilby

- Developer: Takes tickets, small to large: bugs, features, drivers and CRA reports. Every change is tested on your board. You get: A pull request with test results, reviewed by a human engineer.
- Support engineer: Reproduces the report on the bench and measures what happens on the board. You get: A yes or no, with log, trace and measurements. Real bug? Kilby can fix it next.
- Test engineer: Every night Kilby flashes the day's work and runs the regression tests on hardware. You get: A morning report: what broke, and a proposed fix.
- Spec keeper: Reads your firmware, tickets and documents, and keeps one spec next to the code. Every change updates it. You get: One spec in your repo that matches what runs on the product.

## Assign a ticket. Get back a tested pull request.

Works with Jira, Azure DevOps and OpenProject.

- Assign: You assign a ticket, like you would to a colleague.
- Ask: Unclear? Kilby asks on the ticket and waits.
- Fix: Kilby finds the cause and writes the right fix, with a test that fails without it.
- Deploy: Built and flashed on your board.
- Test: Run on your board: fails without the fix, passes with it.
- Sign off: A human engineer reviews it. Then you get the pull request.

## What's on the bench

Kilby connects to your lab through a harness and tests hardware in the loop, like an engineer at the bench. An engineer sets the limit on every output, and a request past it is refused.

A test can run for hours without Kilby. He only wakes up when a check fails or the run is done.

## Why not just a coding agent with skills?

A coding agent with skills is great with a developer next to it. Skills tell the agent how to work. Kilby also gives it a bench and limits it can't pass, so you can hand over a ticket and walk away.

On complex jobs, a coding agent runs out of context around 1M tokens. Kilby keeps going past 12M tokens.

- Where it works: a coding agent: in a terminal, with a developer watching. Kilby: on the ticket, with nobody at the keyboard.
- Hardware: a coding agent: only what you script yourself. Kilby: a real bench, with limits it cannot pass.
- Long tests: a coding agent: the agent waits, and uses context. Kilby: the bench runs alone, and wakes the agent when needed.
- Your code and keys: a coding agent: what it can read, the model can see. Kilby: sealed agent, with your keys and ignored files out of reach.
- Sign-off: a coding agent: up to you, afterwards. Kilby: a human engineer, before it reaches you.

## Not just an agent: where your code goes

The agent writes the code. The Kilby platform around it decides what the agent can see and reach.

- You choose what stays behind. We work from a copy of your repository, one workspace per job. Files in your Kilby ignore file stay out of the agent's workspace. Builds still use them. (licensed libraries, your own core IP)
- Sealed container, one per run. The agent writes the code, but it can't reach anything on its own. The platform holds the keys and does the pushing. (no network, no credentials, no git push)
- The agent's only ways out. One door to the AI model, one to the bench, one to hand in the work. Nothing else leaves the container.
- The agent never holds a real key. What the agent reads goes to an external AI model, over an encrypted connection. The real key is added server-side. Every request is scanned for your kept files, and a match is replaced by a note.
- Limits from the manifest, not the model. Every bench proves who it is, and an engineer sets its limits. A request past one is refused, not quietly capped. The agent measures on your real board, not in a simulator. (mutual TLS, reject, never clamp, unknown state = all outputs off)
- Nothing leaves without a human. The platform runs the checks and a human engineer reviews the work. You get signed commits and a pull request on your own repository. Merging is up to you. Copies are removed after a set period. Want the details for your security team? We'll walk through the full setup with them before a pilot starts.
- It keeps growing. Yours stays yours. We keep extending what Kilby can do, for every client. What he learns about your product grows in a knowledge graph of its own, after an engineer accepts it, and is only used for your jobs. Nothing crosses over to other clients. (one graph per client, no links between clients)

## Questions engineers ask

**What kind of boards and chips does Kilby work with?** Firmware for embedded boards, whatever processor is on them. Tell us what you build on when you join the waitlist, and we'll make sure the bench fits your board.

**Does Kilby really test on our hardware?** Yes. Kilby works on a bench with your board, a bench power supply and a debug probe. Real power, real measurements, no simulator. How the bench is configured for your board is something we agree on in the pilot.

**Is it safe to let an AI drive a power supply?** An engineer sets a limit on every output before Kilby starts. A request past a limit is refused, and the bench switches off.

**Does our code leave the company?** The agent works on a copy of your repository in a sealed container. Files in your Kilby ignore file are never shown to it. What it does read goes to an external AI model, and we monitor that, automatically and with people. What Kilby learns about your product stays with you and never crosses over to other clients.

**Can Kilby push to our repository or merge?** No. The agent has no keys and cannot push. The platform runs the checks, a human engineer reviews the work, and you get a pull request on your own repository. Merging is up to you.

**What happens when a ticket is unclear?** Kilby asks on the ticket, like a colleague would, and waits for the answer before it starts. If it gets stuck, it says so on the ticket instead of guessing.

**What do we need for a pilot?** A board, a user for Kilby in your ticket system (Jira, Azure DevOps or OpenProject), access to your repository and a contact person. Join the waitlist and we'll reach out.

## More

- [Join the waitlist](/#waitlist)
- [About Kilby](/about/)
- [Contact](/contact/)
- [Privacy policy](/privacy/)
- [Guide for AI agents](/llms.txt)