---
rexxpub:
  docclass: slides
  style: print
  language: en
---

::::: title-page

ooRexx in an AI World
=====================

::: author
[Josep Maria Blasco](https://www.epbcn.com/equipo/josep-maria-blasco/)
:::

::: affiliation
Espacio Psicoanalítico de Barcelona
:::

::: event
37th International Rexx Language Symposium
:::

::: venue
Barcelona, May 3--6, 2026
:::

:::::

About this presentation {.slide}
=========================

All examples and demos in this presentation have been
tested with Anthropic Claude Opus 4.6.  The approaches described here
should be transferable to models of comparable capability,
with appropriate adaptations.

\


<small><b>Note:</b> This document[^ThisDoc] was written using
[RexxPub](https://rexx.epbcn.com/rexx-parser/doc/rexxpub/),
a Rexx Publishing Framework.[^RexxPub]</small>

\

[^ThisDoc]: URL of this document:
<https://www.epbcn.com/pdf/josep-maria-blasco/2026-05-04-ooRexx-in-an-AI-world.pdf>;
HTML version:
<https://rexx.epbcn.com/rexx-parser/doc/publications/37/2026-05-04-ooRexx-in-the-AI-world/>.
Presented to the
[37th International Rexx Language Symposium](https://www.rexxla.org/events/schedule.rsp?year=2026),
held at the
[Espacio Psicoanalítico de Barcelona](https://www.epbcn.com/) and online from the 3rd to the 6th of May, 2026

[^RexxPub]: See <https://rexx.epbcn.com/rexx-parser/doc/rexxpub/>.

Claude has a computer inside {.part}
============================

Did you know? {.slide}
==============

Every time you open a chat with Claude, a full Linux machine
boots behind the scenes.  Not a simulation.  Not a sandbox.
A real Ubuntu 24.04 with root access, network, and a complete
toolchain.

Many people don't know this.  They use the AI as a text
generator --- ask a question, get an answer.  But there's
an entire computer sitting there, waiting.

A complete environment {.slide}
=======================

The AI environment is a standard Linux box.  You can install
packages, download files, compile C code, run servers.  Anything
you'd do on a fresh Ubuntu machine, your assistant can do.

For example:

```
curl -o /tmp/oorexx.deb https://rexx.epbcn.com/oorexx-barcelona2026.deb
dpkg -i /tmp/oorexx.deb
rexx -e "say 'Hello from the 37th International Rexx Symposium!'"
```
```
Hello from the 37th International Rexx Symposium!
```

That's ooRexx, running inside Claude's session.  Downloaded,
installed, executed, and ready for real work --- in seconds.

But it's ephemeral {.slide}
===================

When you close the chat, the machine disappears.  Everything
--- installed software, files, state --- gone.

Next session, your assistant starts from zero.  No memory
of what you did, what you built, or what you agreed on.  A
fresh machine, a blank slate.

This is both a limitation and a design constraint.  It shapes
everything that follows.  We will come back to it.

AI assistants know how to program... also in ooRexx {.part}
====================================================

Not just code generation {.slide}
=========================

It's well known that AI assistants can write code.  But
there's a significant gap between generating a function
and working with a real project.

Advanced models can navigate a codebase
with hundreds of files, understand its architecture, and
perform refactorings that touch dozens of components without
breaking the whole.  They reason about dependencies, side
effects, and design trade-offs --- not just syntax.

The full cycle {.slide}
===============

And because these models have a computer, they don't just
hand you code and say "try this".  They run the code
themselves, read the error, fix it, and run it again.

This includes unit tests.  The assistant can write a test
suite, execute it, analyse failures, correct the code, and
re-run the tests --- iterating until everything passes.  You
get working, tested code, not suggestions.

Also in ooRexx {.slide}
===============

These models know Python and C inside out.  ooRexx, not so
much.  But they are customizable: you can give them a
_skill_ --- a concise document that describes a language, a
tool, or a workflow --- and they will absorb it and work
with it.

A well-crafted ooRexx skill, a few pages long, is enough
for the assistant to write idiomatic ooRexx, use the class
hierarchy correctly, and follow the conventions of a specific
project.  The same principle applies to any domain: your
deployment pipeline, your coding standards, your testing
framework.  The AI adapts to your way of working.

A YAML parser in ooRexx {.slide}
========================

How far can this go?  Prof. Rony Flatscher directed the AI
to write a complete YAML parser in ooRexx.  Josep Maria
Blasco acted as intermediary, relaying Rony's detailed
prompts to the assistant and its output back to Rony.  In
about 70 iterations, the parser was written, tested, and
delivered.

A professor and developer, a second developer acting as a
bridge, and an AI that programs in ooRexx.  The result:
working code, born from a collaboration that would have
been hard to imagine two years ago.

Three projects {.part}
===============

From a spreadsheet to a web application {.slide}
=========================================

The starting point was a real spreadsheet managing the finances
of a group of companies: an entity registry (suppliers, clients,
banks, tax authorities), issued and received invoices, bank
statements with pseudo-accounting categories and cost centres,
and summary sheets providing treasury, accounting, and
cost-centre views --- all dynamically customizable by date,
including forecasts.

We uploaded the spreadsheet to the AI and started asking
questions.  It handled the Excel data effortlessly.
Then came the key question: could it replicate this
functionality as a set of ooRexx CGIs?

In one week of intensive work, the assistant built a
complete web application.  It wrote the CGIs, the CSS, and
the JavaScript from scratch --- no frameworks, no libraries.
Design decisions were discussed and agreed upon
collaboratively.  The application is in production today.

Picking up ooSQLite {.slide}
====================

ooSQLite is an ooRexx binding for SQLite, originally written
by Mark Miesfeld.  After Mark's untimely death in 2012, the
project was largely abandoned.  From time to time someone
would touch it, but there was no sustained development.

We asked the AI to look at the project.  It compiled
ooSQLite from source, studied the manual, and wrote a test
harness from scratch.  When the tests ran, they uncovered
several bugs in the original code.  The assistant analysed
them and prepared fixes.

The author of this paper can read C++ but would not be able
to maintain a project like ooSQLite alone.  AI makes it
possible for a developer to pick up an abandoned project
in a language that is not their strongest, understand it,
test it, and start improving it --- work that would otherwise
remain undone.

The Rexx Parser {.slide}
================

The Rexx Parser is a comprehensive parser for ooRexx, currently
in active development.  Its AI instance manages a complex
pipeline: installing ooRexx, downloading the project, setting
up an Apache server with CGI support, deploying the parser's
web interface, and running integration tests against it.

In a typical session, we might ask the assistant to add a new
option to one of the parser's utilities, write the
corresponding unit test, update the documentation, and run
the full test suite to make sure nothing is broken.  Code,
tests, and documentation --- maintained as a single, coherent
flow.

[This section will be expanded with specific examples.]

These three projects have something in common: they are all
maintained by a single developer.  This is not about replacing
programmers.  It's about what happens when an experienced
developer --- someone who understands the full stack, from
CGIs to databases to deployment --- gets a collaborator that
can also program, also test, also debug, and never gets tired.

The more you know, the more you can leverage.

From session to session {.part}
========================

Working around ephemeral sessions {.slide}
===================================

As we saw, the machine disappears at the end of every
chat.  If you're working on a real project, this is a
serious problem: every session, your assistant starts with
no knowledge of what was done before, what conventions were
agreed upon, or what's left to do.

Developers who use AI assistants for ongoing projects
already work around this, often without giving it much
thought.  They paste a summary at the beginning of each
chat, upload a file with notes from the previous session,
or write a handoff document explaining where things stand.
Some use project instructions to preload context.  These
are all sensible responses to the same problem --- they
just tend to be informal, inconsistent, and hard to
maintain as the project grows.

We were no exception.  As our projects grew in number and
complexity, the informal approach stopped being enough.

What we did was not to invent something new, but to
formalise what we were already doing.  The key
idea is to separate _state_ from _project_.  The project is
the code --- it lives in a repository or a zip, as it always
has.  The state is everything the assistant needs to pick up
where the last session left off: what was done, what was
decided, how the code is organised, and what to do next.

The state travels as a zip file.  You upload it at the start
of the session; the AI reads it, works, and at the end
produces an updated zip.  Session after session, the state
accumulates.  The zip is small --- just a handful of markdown
files --- but it carries the full continuity of the project.

At the heart of the system are the _handoffs_: a document
that each session writes for the next one.  What was done,
what was decided, what's pending.  Old handoffs are never
deleted.  They form the project's memory --- a chain that
the assistant can walk back through when needed.

Skills {.slide}
=======

We introduced skills earlier: concise documents that teach
the AI a language, a tool, or a workflow.  In our system,
skills also travel in the state.

Each project carries the full skill collection, but a
_router_ determines which ones are active.  The ooRexx
skill is always active; the Apache CGI skill activates
only when deploying web applications.  Adding a skill to
a project is a one-line change in the router.

This is what makes it possible for a single developer to
maintain projects with very different tech stacks.  The
developer's expertise provides the direction; the skills
provide the assistant with the specific knowledge for each
domain.

A reusable framework {.slide}
=====================

What started as a pragmatic solution for one project
gradually became a framework.  After applying the same
pattern to several projects, we formalised it.

The framework includes protocols for creating state for a
new project, migrating existing projects, auditing
conformity, and synchronising skills across projects.  It
is not sophisticated --- the state files are plain markdown,
the transport mechanism is a zip, and the protocols are
short documents that the assistant follows step by step.

We make no claims about scalability or best practices ---
this is a tool that works for us.

Plain text as infrastructure {.slide}
=============================

Anyone can open the state folder, read every file, and
understand the entire system in minutes.  There is no
hidden logic, no configuration language, no abstraction
layer.  The "programming" is prose --- structured,
deliberate prose that an AI can follow and a human can
inspect.

It turns out that a well-organised collection of markdown
files is a surprisingly effective way to direct an AI
assistant.  It currently manages more than ten parallel
projects, all maintained by a single developer.  We are
making it available in case it can be useful to others.

[The framework can be downloaded from: URL pending.]

::::: closing-page

Thank You! {.slide}
===========

Questions?

jose.maria.blasco@gmail.com

:::::