Autopilot for Delphi

There is a gap between Claude and your Delphi app. Autopilot closes it.

You already work hand in hand with an AI assistant: you give a prompt, Claude writes the code, Claude even compiles it. And then it stops dead. Claude can write a whole form, a handler, a dialog — and have no way to run it, click the button it just wrote, or read what landed in the edit box. Everything past “compile” is on the far side of a wall. The AI needs you at the keyboard to push the buttons and report back.

That gap was in my way on real Delphi work, so I built a bridge across it. Autopilot for Delphi — the Delphi AI Bridge — hands the controls of your running VCL or FMX app to the AI. It clicks real controls, types into real edit boxes, reads the labels back, sets and reads any property, takes screenshots — the same loop a human operator runs, except the assistant does it on its own.

Two lines in your project, and the wall is gone.

See it close the gap

A real session: I told Claude that the “Next page” button in my FMX app (Orinoco eReader) was broken — it wasn’t, but it’s a good test. Claude runs the app, finds and presses the real button, reads the page state before and after, and reports back.

Early screenshots — at the time the tool was still called “AI Debugger”.

Drive it, or debug it — your call

Closing the gap unlocks two things, and the first one matters as much as the second.

• Drive the app to get real work done. Pushing the real buttons means the AI can operate your program, not just inspect it. If your app were an email client like Thunderbird, the AI could answer customers, search contacts, build templates, harvest addresses — driving your own application, the way the end user would. This is automation, not testing.
• Debug and test the GUI, unattended. “The Next button doesn’t work.” The assistant runs your app, presses the button, watches the page indicator advance, compares screenshots, and tells you what really happens — while you drink your coffee. No record-and-replay scripts to maintain.
• Full automation end to end. Hand it one big prompt and leave the computer running. Claude writes the code, builds it, drives the running app to check it, and — if something is wrong — changes the code and tries again. Come back to a GUI app that is built, clicked-through, and working.

How does it compare with Embarcadero Kai?

They are not the same thing — and they work well together. Kai is Embarcadero’s agentic-AI add-on for RAD Studio. It writes code, compiles, and fixes compiler errors — all inside the IDE, on your source. The moment the app is built and running, Kai stops: it can’t press a button or read a label. That is the gap. Autopilot lives on the other side of it — in the running app — and that’s exactly where Kai can’t go.

* Autopilot itself doesn’t compile — but it runs inside Claude Code, which writes and builds the code. So end to end, the Autopilot workflow does build and fix.

Run both and the loop closes with no human in the middle: Kai (or Claude Code) writes and fixes the code; Autopilot drives the running result and reports whether it truly works.

How it works

Three small pieces and one pipe. Your app links in a tiny bridge unit; a separate server process speaks the Model Context Protocol to the AI; the two talk over a private Windows named pipe.

You add one unit and one call to your project:

uses
  Vcl.Forms,
  Autopilot.Bridge.Vcl,        // 1. add the unit (Autopilot.Bridge.Fmx for FireMonkey)
  FormMain in 'FormMain.pas' {frmMain};

begin
  Application.Initialize;
  Application.CreateForm(TfrmMain, frmMain);
  Autopilot.Bridge.Vcl.StartBridge;    // 2. start the bridge
  Application.Run;
end.

The bridge is wrapped in {$IFDEF AUTOPILOT}. You add that define to your debug build only — so release builds compile StartBridge to nothing. No thread, no pipe, no automation surface in production. Your shipped binaries are exactly as they were.

The AI sees your form’s real component tree and acts on it through a small set of typed tools: enumerate every control, click, set/read text, toggle checkboxes, read or write any published property via RTTI, wait for an async result, take a screenshot. Because it reads and writes properties through RTTI directly, it works with any third-party control pack — DevExpress, TMS, anything — with no OCR and no fragile screen coordinates.

Honest about the limits

Autopilot acts directly on Delphi objects, not by faking Windows mouse and keyboard input. That’s a feature — it’s fast, precise, and pack-agnostic — but it means bugs that only reproduce through the real input pipeline (focus-change validation on OnExit, IME composition, hover effects, real drag-drop) aren’t reproducible through it. For that you still want a SendInput-based tool such as TestComplete or AutoIt. Everything else — the daily click-through-and-verify loop — Autopilot does cheaply and without leaving the chat.

I built it because I needed it

I use Claude every day on real Delphi work, and “I can’t see what the app is actually doing” kept stopping me cold. So I built the bridge, used it on my own projects, and it worked well enough that I cleaned it up for other Delphi developers.

Not released yet. Feature-complete and in testing — VCL and FMX bridges, eleven tools, a passing test suite — but there’s no public build or purchase link yet. Targeting Delphi 11 Alexandria, 12 Athens, and 13 Florence (Win32 + Win64), shipped as pre-built DCUs. Runs on Windows (VCL and FMX); the transport is a Windows named pipe.

Want a heads-up when it ships? Get in touch — or read the whole AI-Delphi workflow it lives in, in Book 5 of Delphi in All Its Glory.