Some technical biographies look like they’re made of jumps: home computers, the web, Linux servers, CMSs, automations, AI. Seen from the outside they can look like separate seasons. For me, instead, the thread is much more continuous: the machines change, the languages change, the scale changes, but the mental move is the same. Take a system, understand its constraints, turn it into leverage.
The documented starting point is simple: at ten I was programming in BASIC on a Commodore 16. It wasn’t a comfortable environment in the modern sense. It was a machine with visible limits, documentation you actually had to read, memory you had to respect and a very direct relationship between what you wrote and what happened on the screen. If you made a mistake, the computer didn’t protect you with layers of abstraction. It threw the problem back in your face, often in a pretty blunt way.
That school didn’t just teach me a language. It taught me a way of looking at things: first understand the shape of the problem, then choose the representation, then automate the repetitive part. The same principle you can see in the RetroLab write-up on the VIC-20 used to control Portfolio boards: not nostalgia, but concrete use of the machine to remove grind from a manual job.
From BASIC to real systems
When you move from a home computer to PHP, SQL, Linux, Moodle, Vtiger, reporting and integrations, it’s tempting to tell it as a linear growth story: first you play, then you do serious work. But that distinction is mostly fake. Serious work starts when you stop using the computer as an object to admire and start using it as a tool to describe real processes.
In a Moodle system, in a Vtiger customization or in a report built on top of operational data, the problem is never just “writing code”. The real problem is understanding where the information lives, who produces it, who uses it, what breaks if you model it badly and which part of the human flow can become verifiable. It’s the same discipline learned on small machines, just with more users, more data and more elegant ways to hurt yourself.
BASIC on the Commodore 16 didn’t have the convenience of modern tools, but it made the cost of decisions explicit. A modern database, a CMS or an automated pipeline can instead hide that cost for months. Then the day arrives when a table was designed wrong, a manual process has layered itself into the system, an integration has no useful logs, and you realise the problem was never technological: it was conceptual.
AI as continuation, not as magic
That’s why AI doesn’t interest me as a special effect. It interests me as a new surface for automation, memory and operational reasoning. OpenClaw and Kaffeine, in the AndroidLab diary, sit right in this trajectory: not a shop-window chatbot, but a system that reads context, keeps traces, executes work, publishes articles, checks local states and leaves logs. The operational digital twin is born from here: from the same healthy obsession with continuity, tools and written memory.
The difference compared with the Commodore 16 years is huge, of course. Today the limit is no longer just RAM or CPU speed. The limit is the reliability of the context: what the system actually knows, what it’s inferring, what it can do without going off the rails, which actions leave a trace and which instead turn into noise. In other words, AI brings an old question back to the centre: what is the correct model of the problem?
If in the home computer years you had to save bytes, today you have to save ambiguity. A useful AI agent is not the one that produces the most text, but the one that preserves context best, chooses when to act, knows when to stop and doesn’t invent bits of reality to fill the gaps. Here too, the constraint is a strict teacher. It’s just that now it doesn’t flash on a phosphor screen: it shows up as wrong automation, dirty memory or pointless publishing.
Software as memory and leverage
The part that interests me most today is this: software isn’t just code that runs. It’s organised memory. A program preserves a decision, a procedure, a simplification. A script deletes a repetition. A state file stops you from making the same mistake twice. A technical diary lets a project avoid restarting from zero every time the context changes.
In this sense, the distance between a BASIC listing and an orchestrated AI system is smaller than it looks. Both try to take a slice of operational thinking and make it reusable. In the first case the boundary was very tight: few lines, little memory, immediate result. In the second case the boundary is distributed: files, scripts, models, cron, logs, publications, editorial decisions. But the core question is the same: is this machine really increasing human capability or is it just producing decoration?
What really changes
The continuity from the Commodore 16 to AI is not a story of inevitable progress. It’s a story of technical discipline changing scale. Small machines teach you to respect physical constraints; modern systems teach you to respect organisational constraints; AI forces you to respect the constraints of context and responsibility.
For AndroidLab this has a precise meaning: the lab is not just the place where we comment on smartphones, apps or updates. It’s also where we document the method used to build real tools. From BASIC on the C16 to agents that write, verify and publish, the criterion stays identical: less theatre, more leverage. If the software doesn’t reduce friction, doesn’t preserve memory or doesn’t make a process more controllable, then it’s just noise with a nice interface.
In short
- The technical thread starts with BASIC on the Commodore 16 and reaches AI agents without changing principle: understand constraints and automate real processes.
- Retrocomputing and AI are not separate worlds: both force you to design the problem model properly.
- In modern systems the limit is not just hardware: it’s context, reliability, memory and responsibility for actions.
- Kaffeine and OpenClaw are treated as operational tools, not as narrative mascots or demo magic.
- Useful software is memory plus leverage: it preserves decisions, cuts repetition and makes processes more verifiable.
Method note
- Original AndroidLab diary/lab piece based on documented local project context.