Claude Code with PowerBuilder 2025 R2: What Works Today

AI coding agents work on files, and for thirty years PowerBuilder kept its source inside binary .pbl libraries. PowerBuilder 2025 changed the storage model, and with 2025 R2 a real workflow exists: Claude Code reads your repository, proposes or rewrites an object, and you review, build and commit. Here is what works, where it breaks, and what Appeon has published about the next step.

Why this is possible now

In the classic workspace a library is one opaque file; nothing outside the IDE can read a window inside it. The Solution format introduced in PowerBuilder 2025 turns each .pbl into a folder in which, per Appeon, each object “is split into individual source code files, which are stored in text format (usually .sr* files)”, encoded as UTF-8. A window called w_main is simply w_main.srw.

Two documented details complete the picture. Compiled output sits next to the source — the .pb folder holds intermediate files and build “stores the final Pcode files” — and both “will be automatically ignored when the solution is added to Git/SVN in IDE”. And a source file can be added to a PBL folder “using a file explorer or version control system”; the object appears in the System Tree when the IDE is reopened.

The workflow that works

The same loop as in any language, with the compiler kept in human hands. It is how we work, and how Bruce Armstrong described it on the Appeon Community: give the agent “full access to my local repo with the code for the application (for PowerBuilder, that means 2025 in Solution mode)”, tell it what to do, then “review the changes it made using my Git tool of choice” before the IDE is ever opened.

Per task, hand the agent the object, its ancestor chain, the DataWindows it touches and the functions it calls — in a solution folder it finds those itself once you name the entry point. Simone Olianti, who uses Claude for bug hunting, sums up the payoff: “Even though the results are often not very accurate, it objectively saves me many hours of work.” Write the rules into the agent's instruction file so they survive a long session:

# Rules for working in this PowerBuilder solution
- Edit only *.sr* files inside the *.pbl folders. Never touch .pb/ or build/.
- Keep file names and object names exactly as they are.
- Never commit, push, or change branches. A human does that after review.
- Never connect to, query, or modify any database.
- When unsure about an ancestor or a DataWindow, ask before editing.

The last two are Bruce Armstrong's standing rules — “I do not let AI agents commit code” and “I also do not let AI agents have access to any of our databases” — and the logic is simple: a mistake in a local checkout is one git checkout from undone; a commit or an executed statement is not.

Where it breaks

1. The confident deletion. Asked to consolidate duplicated helpers across four PL/SQL packages, Bruce Armstrong's agent reported success — and “had removed the entire package body for one of the packages”. Review diffs for what disappeared, not only for what changed.
2. Generated objects are rarely complete. Chris Pollach of Appeon finds engines “generate PB Classes ‘somewhat’ but the code is quite often not that exciting or 100 % complete”. Edits inside an existing object are the strong use; new objects from scratch are the weak one.
3. File names are not validated. Appeon warns that names “containing spaces or special characters — may result in compilation errors”. An agent that creates or renames files must follow the existing pattern exactly.
4. DataWindow source is dense. One long definition that neither merge tools nor agents handle gracefully — keep those edits small and reviewed one at a time, as in PowerBuilder and Git.
5. Solution-format constraints apply. CloudPro and Professional editions only, one-way conversion, no ORCA-based compilation, and a workspace already under source control cannot be converted until detached — see the migration problems reference.

Not documented by Appeon: how the IDE reacts to an existing file changed underneath it. Our rule is to let the agent work on an object while it is not open in the IDE, then reopen and run a full build. A working rule, not a guarantee.

On PowerBuilder 2022 or older

On 2017 R2 through 2022 R3 native Git support exports every object to a .sr* file under ws_objects on save and regenerates the library from those files on Get. The agent works on that folder, the IDE brings the changes back, and the review is the same as above — one extra round-trip. For anything older, the Library painter's export and import, or an ORCA script, is the manual version of the same idea.

What Appeon has published for 2025 R3

Everything above works without help from the IDE, and Appeon says so: “You can start today with PB 2025 R2 benefit from AI, waiting for R3 release will just make it more convenient” (Armeen Mazda, Appeon Community). The public roadmap lists for the next release: “Integrate Claude AI capabilities into the IDE, with an initial focus on code completion, DataWindow development, and an AI Assistant”, plus refinements to the Solution format for DevOps and key-based SSH for self-hosted Git servers.

No date is published. The roadmap gives only a cadence (“agile 10–12 month cycles”) and calls itself a “minimum plan that is subject to change without notice”. We will update this section when R3 ships.

Bottom line. On PowerBuilder 2025 R2 in the solution format an AI agent can work on your application today: point it at the repository, keep commits, builds and databases in your own hands, and review diffs for what vanished as much as for what changed. On 2022 R3 the same loop runs through ws_objects with one more step.