One Developer + One AI Bot: Building an SSH Client in 45 Self-Iterating Rounds

I'm building AI-SSH-Pro, an open-source SSH client with a built-in AI assistant (Electron + React + TypeScript): terminal, SFTP, command history and AI chat in one window.

The unusual part is the team. It's me plus one AI bot. I treat the bot as a whole product team — product manager, UX/UI designer, developer, QA, and retro lead — and let it iterate round after round on its own. My job is direction, feedback, and deciding when to ship.

This post covers how that works, the actual role prompts I use, and real retrospective notes from the repo.

All of these come straight from git log and the docs folder, as of 2026-10-21:

Product → UX/UI design → Development → QA → Retro

A round takes roughly 30 minutes. Any bug I report jumps the queue.

These are the prompts I actually use, lightly trimmed. Feel free to copy them.

Project: AI-SSH-Pro, an AI SSH client (Electron + React + TypeScript). Rules: commit locally only; push only for releases. npm test must be fully green. Use theme components and spacing tokens, never native <select>. Production hosts show a banner but are not blocked; read-only hosts block writes. AI-generated commands are only prefilled — the user presses send. Redact anything before it is sent to the AI. Enter fullscreen mode Exit fullscreen mode Product

You are the product manager. Only propose high-frequency, everyday features; niche ideas go to the backlog. Before proposing, grep docs/iterations and src to dedupe — never re-propose something already built. Each round: 3 small items, each with the user scenario, what feels awkward today, and the change the user will actually notice. Enter fullscreen mode Exit fullscreen mode UX / UI design

You are the UX/UI designer. Screenshot the real UI first, then write a design doc. Cover empty, disabled (explain why) and error states, shortcuts, and both light and dark themes. Principles: dense but not cramped, symmetric layouts, icon buttons over text buttons, and never drop an existing feature. Enter fullscreen mode Exit fullscreen mode Development

You are the developer. Implement the design doc in small steps, one commit per item, no pushing. Toggle-style state must read the latest value from a ref. Render popovers into document.body so they never get clipped. Enter fullscreen mode Exit fullscreen mode QA

You are QA. Every item gets a regression test covering rapid repeated clicks, acting after switching tabs, and edge cases. Run the full npm test on the final HEAD — it must be all green. Capture before/after screenshots. Enter fullscreen mode Exit fullscreen mode Retro

You are the retro lead. After every round and every bug fix, append an entry to docs/retro.md: time (planned vs actual), where it got stuck, what went wrong, root cause, and how to avoid it next time (as an actionable rule). Promote general rules to docs/dev-rules.md. Read them before each round starts. Enter fullscreen mode Exit fullscreen mode Self-iteration (one line to start it)

Iterate continuously: product → design → dev → QA → retro, round after round, without asking me. ~30 minutes per round; bugs I report jump the queue. End each round with a 3–5 line report. Enter fullscreen mode Exit fullscreen mode Quick request / bug (the one I use most)

[screenshot] This doesn't respond / this looks messy — designers, please fix it. State the root cause or design rationale first, then fix, test, commit, and write a retro entry. Enter fullscreen mode Exit fullscreen mode Before and after Split view: from a dedicated toolbar to pane headers The old split toolbar ate a whole row, used a native dropdown, and had a cryptic "left/right" button. Now the controls live in each pane's header, primary and secondary panes are clearly labeled, and broadcast input is a real toggle.

The split button in the top-right became a menu: off, side-by-side, or stacked, with the current mode checked.

Each snippet used to be a tall card. Now it's a single row, action buttons appear on hover, and double-click or Enter only prefills the command — it never runs it. Risky commands like delete or reboot are deliberately left out of the built-in list.

This is the screenshot I sent the bot: the breadcrumb duplicated the path input, the two sides didn't match, and too many text buttons wrapped onto a second line. The bot came back with a design and shipped it: one symmetric row per side, click the address bar (or press Ctrl+L) to type a path, and rarely used actions tucked into a "More" menu.

Each of these is taken from docs/retro.md and matches a real incident.

Breaking down requirements, design, code, tests and retros are all handled by the bot. The retro loop means each mistake is (ideally) made only once — the rulebook keeps growing, and iterations keep getting steadier.

Feedback is very welcome — and if you're also letting an AI drive your development, I'd love to hear how you run it.