Autopilot for Delphi - Delphi, in all its glory

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.

Claude Code receiving the prompt to run the Delphi app and test the Next-page button — 1 — The prompt. “Run the app, press the button, see if the page changes, report back.”

The running Delphi FMX application with an arrow pointing at the Next-page button Claude is about to press — 2 — Claude drives the running Delphi app and presses the real button (it figures out on its own that the control is named `btnNext`).

Claude before-and-after report showing PageIndex changed from 1 to 2 and the rendered page changed, proving the button works — 3 — The verdict, with a before/after table: `PageIndex` 1→2, the spinbox 2→3, the rendered page visibly turned. The button works.

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.

	Kai	Autopilot
Write code in the IDE	yes	no
Build, fix compiler errors	yes	yes*
Drive and operate the running app	no	yes
Debug / test the GUI (click, type, read state)	no	yes
Screenshot the running app	no	yes

* 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 (the full list is below). 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. Setup is a one-time registration of the server with your AI host; from then on it auto-discovers your running app — no port to configure, no manual attach.

The tools the AI calls

No macro recorder, no script to maintain — under the hood it’s a small, typed toolset that the assistant calls straight from a chat session. Eleven tools cover the whole operate-and-observe loop:

Tool	What it does
`list_tree`	Enumerate every form and control — names, classes, paths, text, enabled/visible state. The AI’s map of your app.
`click`	Click a button, or anything with an `OnClick`. Repeat N times in a single call.
`execute_action`	Fire a `TAction` directly — for shortcut-only actions and actions shared by several controls.
`get_text` / `set_text`	Read and write `Caption` / `Text` / `Lines` on edits, memos and labels. Writing fires `OnChange`.
`set_checked`	Toggle a checkbox or radio button; fires `OnChange`.
`set_property`	The Swiss-army knife: write any published property — `Tag`, `Color`, `Position`, `ItemIndex`, sets, even AI-friendly colors like `clRed` or `#FF8000`. Mistype a name and it hands back the full list of writable properties with their live values, so the AI corrects itself without another round-trip.
`read_property`	Read any published property via RTTI — and what it returns is exactly what `set_property` accepts back.
`wait_for`	Poll a property until it matches or times out — for async work (`TTask`, database queries, timers).
`screenshot`	Capture the form as a PNG, for visual and layout checks.
`attach`	Pick a target when several apps are running. Usually unnecessary — every tool auto-attaches.

The assistant bundles several of these into a single turn — find the control, type, click, then check the result — so a whole reproduce-and-verify sequence is one round-trip, not ten.

What it deliberately doesn’t do

Honesty first. Autopilot acts directly on your Delphi objects; it doesn’t fake Windows mouse and keyboard input. That’s a deliberate trade, and it has a flip side — bugs that only show up through the real input pipeline won’t reproduce through it. Things like:

Focus-change validation (OnExit, kill-focus handlers)
IME composition and Asian-language input
Keyboard accelerators that travel through the Windows message loop
Hover-driven UI (mouse-enter / mouse-leave)
Drag-and-drop started by a real mouse-down-and-move

A message-based click mode covers some of this for buttons; for full input-pipeline coverage you would pair Autopilot with a SendInput-style tool (TestComplete, Ranorex, AutoIt).

In return for that trade you get direct property access with no OCR and no fragile screen coordinates, sub-millisecond round-trips, and compatibility with any third-party control pack — because RTTI is universal.

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.

Availability, pricing & supported Delphi versions

Not released yet. Autopilot is feature-complete and in testing — VCL and FMX bridges, eleven tools, a passing test suite, plus working VCL and FMX demo apps you can drive from an AI session in about five minutes — but there is no public build or purchase link yet, and pricing is not final.

Planned licensing (all prices to be announced): a Personal license, a Team license, and a site license. It ships as pre-built DCUs for each supported Delphi version — the source code is not distributed.

Supported Delphi versions at launch: 11 Alexandria, 12 Athens and 13 Florence — Win32 and Win64, six pre-built DCU sets in total. 10.4 Sydney is planned for a 1.1 release, and earlier versions are available on request. Tested against Delphi 13.1 Florence. No third-party dependencies — standard library and Windows API only.

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.