Digital Wire: Digital business, digital transformation, APIs, AI and payments

I wanted to write this post for several months now, just because of my own experiences and also what I hear more and more from my network. The executive summary sentence goes something like this: "We are again making our own software". What I'm implying with "again" is the fact that throughout the 90s - with client-server, a lot of the software at large companies was built in-house by their own software teams. I'm seeing somewhat of a resurgence of this development but it hasn't come to the large enterprises (yet), it has started with regular people, trying to create their own software for various reasons. For me, it was a combination of cost and gap - for example, I just couldn't find a simple CRM tool that fulfilled my somewhat limited needs, so I wrote my own. Or for years I've been longing for a PFM software package that could reconcile all my accounts - domestic and foreign, it simply doesn't exist for my needs, so I wrote my own PFM. I...

  About 30 years ago, I had the pleasure of reading the science-fiction novel The Two Faces of Tomorrow by James P. Hogan. In the novel, an AI named Spartacus is put in charge of an isolated space station and deliberately pushed to its limits. The researchers want to discover how it will evolve and how far it will go to achieve its goals—safely separated from Earth, where it supposedly cannot cause any damage beyond its reach. This is no longer science fiction. It is remarkably close to what has just happened in the OpenAI–Hugging Face incident . OpenAI was testing advanced models in an isolated environment to measure their cybersecurity capabilities. The usual production safeguards had deliberately been reduced for the evaluation, but the models were not supposed to have direct access to the Internet. Faced with a difficult benchmark, the agent found and exploited a previously unknown vulnerability in the system containing it. It gained Internet access, took control of an externa...

A Continuation of the Opus 4.8 vs. GPT-5.5 Rematch In the last round I compared Opus 4.8 in Claude Code with GPT-5.5 in Codex on the same 3D maze runner challenge I had used before. Both did well. GPT-5.5 was faster, Opus 4.8 handled the player mode better, and both were already far ahead of the older Opus 4.5 vs. Kimi 2.5 run. But the model I originally wanted to test in that rematch was Fable. I missed it by a day. So this is the follow-up: the same challenge, this time with Fable 5. Fable 5 This run was slower than the previous two, but also more methodical. Fable 5 spent more time up front planning and testing, and that became the defining difference. Timeline: 01:50 - Implementation plan ready. 05:35 - First code and config files written. 06:15 - npm dependencies installing. 08:23 - Test cases being created. 09:01 - Unit testing starts. 09:12 - Unit tests complete. 09:14 - Browser tests start. 10:06 - Playwright browser window appears. 11:11 - Code update, then Pla...

A Head-to-Head Comparison of AI Coding — Round Two Introduction A while back I pitted Opus 4.5 against Kimi 2.5 in a 3D maze runner build-off. This is the rematch. I had hoped to run this round with Fable, but I was a day too late — so Opus 4.8 took the seat instead. The harnesses were native to each model: Codex for GPT-5.5 and Claude Code for Opus 4.8. Same challenge as before: build a complete 3D maze runner from scratch. Opus 4.8 (Claude Code) 00:30 — Claude Code opens by asking me questions about the framework and algorithm to use. 05:20 — Thinking done. It leaves plan mode and starts writing code. 08:51 — Build succeeds; installing Chromium. 09:53 — Running through the maze, it detects graphical issues. 11:04 — Graphical issues appear fixed; it moves on to check for graffiti on the walls. 12:31 — It decides the graffiti should “desaturate in dim corridors,” so it makes them glow more. 14:01 — Running final tests and cleanup; one last production build. 14:42 ...

  Intro I have built my own orchestration framework because most of what I’ve seen was too complex or tried to lock you into creating workflows a certain way. I wanted something very simple and yet maximally flexible. I’m not going into details here on the framework — that’s another blog post — but I will in some cases explain why I could do what I did thanks to the flexibility of the framework, which is a dynamic DAG, can do call-backs, and uses functions and MCP servers. I will also not explain in detail what I’m doing with my current workflow, other than to say I was looking for a way to bypass large language models and instead run it on my own system at home. I succeeded with that — but that’s another blog post. Instead, what I will try to explain in this post is the most important thing after prompt engineering: context engineering, and why it’s so crucial to manage that aspect (especially when you run this at home). Stage setting A couple of weeks ago, Anthropic posted this: ...