Pages

About

Creating 18 Engine descriptions

Mike's Notes

18 working engines are currently being imported into Pipi Core, configured, and tested.

Alex has sent me a DeepSeek chat that generated descriptions of those engines and how they worked together by analysing the existing web page "20 Engines". DeepSeek also produced a Mermaid Diagram from Markdown code based on those descriptions. DeepSeek was partially correct in some descriptions.

The Mermaid diagram was wrong, but what a great tool for Pipi to self-document with CL and accurate Markdown descriptions. It will be widely used in future as a plugin.

Feedback and suggestions are very welcome as always.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

06/05/2026

Creating 18 Engine descriptions

By: Mike Peters
On a Sandy Beach: 06/05/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

Most Pipi engines have historically been poorly described. This is an attempt to write better descriptions for the 18 engines currently being imported.  I had a go, then used Gemini to come up with better wording, then Mrs Grammarly did her bit. 😎

Much later, once the workspace UI are working, a one-page summary about each engine can be written for the pipiWiki. The Wiki Engine (wik) in the resources above has an example of such a summary.

Descriptions

Each engine has;

  • Unique Name (Unique 3-letter code)
  • S: Short description suitable for tooltips under 100 characters.
  • D: Description under 255 characters.

System Engine (sys)

  • S: System identity and lifecycle controller.
  • D: Manages the vital signs and lifecycle of Pipi’s dynamic engine ecosystem, fostering complex emergent behaviours through seamless interaction.

Nest Engine (nst)

  • S: Host and environment interface bridge.
  • D: Serves as the foundational gateway between the host OS, Java, the application server, and the internal Pipi environment.

Namespace Engine (nsp)

  • S: Global identification and addressing.
  • D: Enforces a conflict-free global naming convention, ensuring every system element is uniquely addressable across the entire platform.

Render Engine (rnd)

  • S: Static file and asset rendering.
  • D: Processes and renders static resources, including HTML, CSS, source code, and databases.

Template Engine (tem)

  • S: Reusable pattern templates.
  • D: Manages reusable structural pattern templates used by the CMS to generate database-driven pages and components.

Variables Engine (var)

  • S: Centralised variables library.
  • D: Provides a centralised repository for managing variables used across templates, system configurations, and executable logic.

Log Engine (log)

  • S: Universal logging and telemetry controller.
  • D: Aggregates and configures logging parameters across all active engines to provide system-wide transparency and diagnostics.

Data Engine (dta)

  • S: Database lifecycle and CRUD operations.
  • D: Commands the creation, evolution, and deletion of databases and their underlying data objects with full administrative control.

Configuration Engine (cnf)

  • S: Engine blueprint and manufacturing settings.
  • D: Supplies the precise DNA and configuration parameters required for the automated fabrication of individual Pipi engines.

Versioning Engine (ver)

  • S: Semantic versioning and update tracker.
  • D: Maintains system integrity by aggregating incremental updates from all engines into a unified semantic versioning timeline.

Code Engine (cde)

  • S: Internal code generation.
  • D: Facilitates automated code generation, including class libraries and logic synthesis directly within the Pipi platform.

Conductor Engine (cnd)

  • S: Internal process regulator.
  • D: Operates as the high-level orchestrator for major internal system processes and synchronisation.

Directory Engine (dir)

  • S: CMS file system and path manager.
  • D: Manages the logical and physical file system directories generated and utilised by the CMS.

Node Engine (nde)

  • S: Hierarchical template tree architect.
  • D: Maintains the addressable tree structure of templates to define content hierarchy within the CMS.

CMS Engine (cms)

  • S: Digital content management.
  • D: Powers the end-to-end lifecycle of digital content, from initial creation and editing to final publishing.

Core Engine (cor)

  • S: Primary system driver and logic hub.
  • D: The central engine that powers fundamental system behaviours and executes the primary logic that keeps Pipi running.

Factory Engine (fac)

  • S: Automated engine fabrication.
  • D: Assembles and deploys engines based on stored configuration files and real-time updates.

Page Engine (pge)

  • S: Semantic relationship and metadata mapper.
  • D: Maps external relationships for pages, managing keywords, references, and "See Also" semantic connections.

Tim Cook is Leaving. Good.

Mike's Notes

The key takeaway of this copied article.

"make products you’d be proud to use yourself."

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Amazing CTO
  • Home > Handbook > 

Last Updated

05/05/2026

Tim Cook is Leaving. Good.

By: Tony Mattke 
Router Jockey: 27/04/2026

I’m Anthony Mattke, aka Tony. I’m a network engineer, infrastructure architect, and general-purpose technology geek located amidst the endless cornfields of north central Indiana. I’m a husband and father, and I hope to have superpowers one day. Seriously.

Your AirPods just connected to the wrong device. Again.

iMessage is taking twenty minutes to sync a message between your laptop and your phone sitting six inches apart. HomeKit forgot the kitchen lightbulb exists, and will remember it again in three hours like nothing happened. System Settings, which used to be one of the cleanest preferences UIs ever shipped, now feels like a bad Electron app pretending to be macOS.

These aren’t dramatic failures. They’re worse than dramatic failures. They’re daily proof that somewhere along the way, Apple stopped caring about the texture of using its own products.

This is Apple in 2026. And this is the Apple that Tim Cook built.

Cook announced his departure last week, and most of the coverage you’ll see is going to be a victory lap. A lot of it is earned. Apple is a three-trillion-dollar company. Services revenue is at record highs. Apple Silicon is one of the great hardware bets of the last decade. He took a company already at the top of its industry and made it bigger than the GDP of most countries.

So why am I glad he’s leaving? Because somewhere in all that growth, Apple stopped making products it was proud of.

What Steve Actually Said

There’s a passage in Walter Isaacson’s biography of Steve Jobs that gets quoted less than the famous ones. Jobs talked about how great companies die, and his theory was that the rot has nothing to do with competition or markets or innovation cycles. The rot starts when the salespeople end up running the company.

He named names. He pointed at IBM under John Akers. He pointed at Microsoft under Ballmer. He even pointed at the Sculley era of his own Apple as the cautionary tale. The phrase Jobs kept circling back to was that the people running these companies eventually “have no conception of a good product versus a bad product.” They can’t tell the difference. They can run a supply chain better than anyone alive, but they couldn’t tell you whether the radius on a button looks right.

That’s not a small criticism. That’s the founder of Apple, on the record, naming the disease and warning the company against catching it.

Then, in 2011, Apple promoted its head of operations to CEO.

I’m not saying Cook was a bad pick at the time. He was the right person to keep the trains running while everyone caught their breath after losing Steve. But fifteen years later it’s worth asking the question Steve himself would have asked. What kind of products are we shipping now?

The Tenet Cook Forgot

Of all the things Steve Jobs believed about Apple, one of them stands out as the most quietly violated under Cook: make products you’d be proud to use yourself.

Not just sell. Not just ship. Use. Sit down at the Mac on a Tuesday night, put your AirPods in, fire off a Message, set up a HomeKit automation, and feel proud of every single one of those things working the way you wanted them to.

Today’s Apple doesn’t pass that test. And the failures aren’t dramatic ones. They’re the small, persistent, daily-friction kind that the founder used to personally drive teams to fix.

You know the list. The 2022 System Settings redesign managed to take a perfectly usable preferences app and ship it as something worse, then leave it that way for three OS releases and counting. Notifications have been re-architected three times in five years and still work inconsistently across iOS, iPadOS, and macOS. Mail rules have been broken since the Obama administration. The Photos library will quietly drop items, sync ghosts, and offer no diagnostics when something goes wrong. HomeKit loses devices the way a child loses socks. Spotlight returns stale results and pauses for seconds at a time on hardware that should make it instant.

Each one of these, on its own, is just a bug. Together, they’re a culture.

They survive because they don’t move metrics. They don’t reduce revenue. They don’t show up in the quarterly. But they’re exactly the kind of paper-cuts that would have annoyed Steve at 9pm on a Tuesday, and they would have been fixed by Wednesday morning.

That’s the difference. Steve used the products. Cook signs the budget.

Before Someone Says This Is Just Nostalgia

Yes, I know. Apple under Steve wasn’t perfect. MobileMe happened. Antennagate happened. The hockey-puck mouse happened. Plenty of bad calls happened. Nobody is arguing for some flawless golden age that didn’t actually exist.

The argument is about standards, not perfection. Old Apple shipped mistakes too, and it visibly hated them. The bad release, the launch-day disaster, the public mea culpa, the engineering re-org. The whole company would visibly recoil and try to do better.

Today’s Apple ships friction and treats it like background radiation. That’s not the same thing.

The Counter Argument (-ish)

Yes, Apple Silicon is incredible. Yes, the Watch saved lives. Yes, the iPhone got better cameras and better screens and better batteries. The hardware story under Cook is strong, and pretending otherwise would be silly.

But here’s the thing about hardware. You can grow it through operational discipline. You can squeeze a process node, you can negotiate a better deal with TSMC, you can lean on a thousand suppliers until they bend. That’s exactly the kind of work Cook is good at, and it’s exactly the kind of work that doesn’t require a product person at the top.

Software is different. Software lives or dies on judgment calls a thousand times a day. Should this preference go in this menu or that one? Should this notification fire silently or with a sound? Should this Bluetooth handoff be aggressive or conservative? Those decisions can’t be operationally optimized. They have to be made by someone who actually uses the thing and has an opinion. Cook is famously not that person.

And the rot follows that exact line. Apple’s hardware reviews are still glowing. Apple’s software reviews… are not. The number of “I’m switching to Linux” or “I’m switching back to Windows” essays from longtime Apple loyalists has gone from a trickle to something that should worry someone on Apple Park’s executive row.

The grumbling isn’t about features. It’s about the texture of using the products. Which is the thing Steve cared about most, and Cook seemingly cares about least.

The Era of *aaS

There’s a related thread here. Cook’s Apple has gradually rebuilt itself as a services company that happens to make hardware. iCloud subscriptions. Apple Music. Apple TV+. Apple Arcade. Apple Fitness+. Apple News+. Apple One. AppleCare+ tiers within tiers. The recurring monthly nudges that show up in apps that used to be one-and-done.

There’s a real argument that this was a defensive move, and it worked. The Services line is now bigger than the GDP of small nations. But there’s also a reason long-time Apple users are uneasy. The company that ran the iPod silhouette ad is now the company that nudges you to try Apple Fitness+ when you open the Watch app for an unrelated reason. The texture changed. The thing that made Apple feel different is, slowly, less different.

And here’s where it loops back to the bug list. When recurring revenue becomes the thing the company optimizes for, the tolerance for friction goes up. A slightly annoying subscription upsell is acceptable as long as the funnel still works. A weird Settings menu is acceptable as long as nobody actually leaves. That’s how product standards quietly erode. Not through one dramatic bad decision, but through a thousand tolerated ones.

Was that the right business call? Maybe. Was it the right product call? Different question. And it’s the question Steve would have asked.

Enter John Ternus

The honest read on Cook’s tenure: he was the right operations CEO for the post-Steve transition, and he stayed long enough to also become the wrong product CEO for the post-iPhone era. That’s not a damning legacy. It’s just a long career with two halves that needed different people.

So who’s getting handed the keys? John Ternus.

If you needed to pick someone inside Apple to course-correct away from the operations-CEO failure mode, Ternus is the right person on paper. He’s been SVP of Hardware Engineering for years. He came up working on the Mac, ran iPad development, and was a key player in the Apple Silicon transition. He’s the one Apple keeps putting on the keynote stage to talk about new hardware. By any honest read, he’s an engineer and a product person, not a salesperson, not an operator. That’s the pick Steve would have nodded at.

BUT…

The piece I just spent a thousand words complaining about isn’t a hardware problem. Apple’s hardware under Cook has been excellent. The thing that rotted is the software experience. The bug list. And Ternus, for all his strengths, has spent his career running hardware, not software. Whether his product instincts translate into fixing the software stack is the open question of his tenure.

The hopeful read is that an engineer-CEO will demand engineering rigor across the whole company, including from the software org that’s been getting away with shipping half-baked work for a decade. The cynical read is that hardware engineers and software engineers are different cultures, and you can lead one without knowing how to fix the other.

I’m cautiously in the hopeful camp. The fact that Apple chose a builder over another finance type or another operations type says they noticed the thing this article is about. That’s not nothing.

But the proof is going to be in the next macOS release. Does System Settings get rebuilt? Does AirPods routing finally stabilize? Does Mail get a rewrite? Do notifications get a coherent strategy across all four operating systems? If yes, this was the right pick. If we get another year of shiny new features with five new bugs and zero fixes for the old ones, then Apple just rearranged the deck chairs.

Because that’s what made Apple. The rest is supply chain.

So yes. Tim Cook is leaving. Good. And John Ternus is taking the keys at exactly the moment Apple needs to remember what it was supposed to be.

How function diversity scales, from cells to companies

Mike's Notes

Fascinating work. Something to test Pipi against using long-cycle simulations.

Resources

References

  • Scaling laws for function diversity and specialization across socioeconomic and biological complex systems. Authors: Vicky Chuqiao Yang, James Holehouse, Hyejin Youn, José Ignacio Arroyo, Sidney Redner, Geoffrey B. West, and Christopher P. Kempes. PNAS (February 12, 2025). DOI: 10.1073/pnas.2509729123

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Parallax
  • Home > Handbook > 

Last Updated

04/05/2026

How function diversity scales, from cells to companies

By: Santa Fe Institute
Parallax: 18/02/2026

Mike is the inventor and architect of Pipi and the founder of Ajabbi.

A mystery novel, a history book, and a fantasy epic may have little in common in plot or style. But count the words inside them and a strange regularity appears: many new words show up early, then fewer and fewer as the author reuses what has already been introduced.

That pattern, known as Heaps’ law, turns out not to belong to books alone. A new study in PNAS finds that the same rule also describes the growth patterns in many complex systems, from living cells and corporations to universities and government agencies — and could even be used to predict how they will change in the future.

The study, led by scientists at the Santa Fe Institute and MIT, doesn’t just document this regularity; it introduces a mathematical model that quantifies how different systems diversify and specialize. It finds that, while systems vary in how much they invest in creating entirely new functions, once those functions exist, their subsequent growth follows a remarkably universal rich-get-richer process.

“What’s striking is that these systems weren’t designed to follow the same rules,” says SFI Program Postdoctoral Fellow James Holehouse, who co-led the study with Vicky Chuqiao Yang, a former SFI Omidyar Fellow now at MIT. “Yet when you look at how they grow, you see the same trade-off between adding something new and building on what already exists.”

“It is remarkable that cells, bureaucracies, and companies, despite obvious differences, all grow their function repertoire with a similar pattern.”

In the study, researchers focus on what they call “distinct functions” — the different kinds of work a system performs. In a cell, that might mean different proteins. In an organization, it could mean different kinds of jobs. As systems grow, they do add new kinds of work, but they do so more and more slowly over time.

Using their model, the team analyzed dozens of bacterial and microbial cells, more than a hundred U.S. federal agencies, thousands of companies and universities, and hundreds of metropolitan areas. Across most of these cases, the same pattern appeared: as systems got bigger, the pace at which they added new functions steadily slowed, growing sublinearly.

In practical terms, sublinear growth means that doubling the size of a system does not double the number of functions inside it. Instead, growth increasingly comes from expanding what already exists. A growing organization hires more people into established jobs before creating new titles. A cell produces more of the proteins it already uses instead of evolving entirely new ones.

“It is remarkable that cells, bureaucracies, and companies, despite obvious differences, all grow their function repertoire with a similar pattern,” says Yang, an assistant professor at MIT Sloan and the Institute for Data, Systems, and Society. “This suggests that the regularity discovered in Heaps’ law applies not only to what humans create, like books, but also to human organizations themselves.”

Cities, however, follow a different version of the same trend. They still add new kinds of jobs as they grow, but they do so much more slowly, following a logarithmic pattern rather than the power-law pattern seen in other systems. Even as populations soar, genuinely new job types become increasingly rare.

That difference reflects a deeper structural divide. Cells, firms, and agencies behave like organisms, with clear boundaries and unified goals. Cities, by contrast, resemble ecosystems shaped by the independent choices of individuals rather than centralized control.

Geoffrey West, a co-author and Santa Fe Institute Shannan Distinguished Professor, adds, “There are underlying regularities shaping how complexity builds, even in systems that look completely different on the surface.”

This material is based upon work supported by the U.S. National Science Foundation under Award No. 2526746

The Neural Harness: The new CPU

Mike's Notes

Some deep insights here from Will Schneck. Asking more questions than he answers. Especially deterministic vs probabilistic. Where does emergence emerge? 😎😎

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > The Focus AI
  • Home > Handbook > 

Last Updated

03/05/2026

The Neural Harness: The new CPU

By: Will Schenk
The Focus AI: 01/05/2026

I am a father, entrepreneur, technologist and aspiring woodsman.

My wife Ksenia and I live in the woods of Northwest Connecticut with our four boys and one baby girl. I have a lumber mill and all the kids love using the tractor.

I’m currently building The Focus AI, Umwelten, and Cornwall Market.

"Coding agents will build their own tools and their own agents. Agents will be used by non-engineers to manage other agents to manage parts of the org chart."


I'm on my second Claude Max plan. That's in addition to Cursor, Codex, Gemini, and a healthy Amp habit. Not to mention a Jetson AGX Thor I'm about to plug in at the office — more on that one later.

Overnight jobs parsing financial deal structures, ops stuff, research, monitoring logs, responding to events, all the little background things. The first plan tapped out, I added another, that one tapped out too, and now I'm provisioning a third the way you'd add a build runner. Mundane.

A new entry in an old list

Look at the paragraph I just wrote. Overnight jobs parsing financial deal structures, ops stuff, research, monitoring logs, responding to events. Half of those words are themselves names of native units of computing. Logs — log aggregators. Events — event streams. Research — search indexes. Ops — schedulers, orchestrators, deployment systems. Jobs — queues. The lede is already a list of older units I'm wiring into.

Computing has been accreting native units forever, and the way you build the next layer is by composing the units underneath it.

You combine adders and accumulators to make a CPU. You combine CPUs and memory and a bus to make a machine. You combine logic gates and clocks to make registers. You combine Boolean functions and a process model to make an operating system. You combine lexers and parsers and code generators to make a compiler. You combine source files and a compiler to make a program. You combine programs and a network stack to make a service. You combine services and a database to make an application. You combine applications and a queue to make a pipeline. You combine pipelines and a stream processor to make a real-time system. You combine streams and a log aggregator to make observability. You combine logs and a metric and an anomaly model to make a monitor. You combine all of it and a scheduler and you have a system that runs without you watching it.

Flat-color treemap of the computing stack: small blocks for adders, clocks, registers, cpu, memory, bus growing diagonally up and to the right through machine, os, compiler, program, service, application, pipeline, stream, observability, monitor — culminating in a large block for scheduler.

Each layer is just the layer below, composed. That's what a native unit is — the thing you stop writing yourself, the thing you wire to. You don't write a compiler. You don't write a Postgres. You don't write a Kafka or a Kubernetes or a Lucene or a git. You pick the unit, you combine it with other units, you build on top.

Now look at that list again. Everything on it is sitting on top of Boolean logic. Silicon, gates, arithmetic, state machines, if/then. Numbers, types, queries, schedules, indexes — all of it is deterministic logic resolving down to ones and zeros. You can climb that stack pretty high, but you don't get out of it.

19th-century geological cross-section: layered strata of fossilized circuit traces — gates, clocks, registers, CPU, OS, compiler, program, service, application — opening into a newly excavated neural floor below, soft coral and cream tones, neuron tendrils threading up into the rock. The new floor under the old stack.

Neural nets aren't more of that. They're a different kind of logic. Pattern, association, similarity, fuzzy matching, generation. The thing silicon-and-Boolean was bad at, that we kept failing to solve with cleverer rules, the neural net does natively. We added a new floor — GPUs, TPUs, the Cerebras inference fabric, the Jetson on my desk — and a new kind of computation running on it that doesn't reduce to if A and B then C.

By themselves these things predict tokens. They don't loop, they don't read files, they don't remember. To get computation out of one you wrap it. A loop, some tools, file access, a shell, a way to manage context. That wrapper is the harness. The harness is the unit that turns "predicts the next token" into "does the work" — and lets the new kind of logic compose with the old kind.

The neural harness is to neural nets what the compiler was to source code. New entry on the list, joining the family rather than replacing it. The work I'm running on these two-going-on-three Max plans is mostly the harness wiring into the older units — tailing logs, querying state, watching streams, kicking off jobs, hitting indexes. New unit, old units, composed.

That's why the second Max plan isn't weird. The bill scales with how much work you're doing in the new unit. I'm doing a lot of work in the new unit.

How it shows up in a day

It really has stopped being a tool I reach for; its just the tool.

When I'm coding, I'm in a harness. When I'm reading a PDF I needed to read anyway, the harness is the thing reading it. Operations folder — SOWs, invoices, content ideas, project status — that's a harness. Parsing 20 financial deal docs and writing me a summary while I sleep — harness. Family infographics, fasting tracker, oura ring trends — harness, harness, harness. Different work, same unit.

Small-multiples grid: the same harness icon repeated across sixteen everyday domains — code editor, PDF reading, invoice, SOW draft, content ideas, project status, financial deal, overnight job, log monitor, email triage, family infographic, fasting tracker, Oura trends, calendar, research note, ops dashboard. One unit, many domains.

Coding was just the first place this paid off, because the feedback loop is tightest. Compile or don't, test or don't, the world tells you you're wrong inside a second. So that's where the harness got tuned first. That's why the unit is called a "coding agent" right now. But "coding" is vestigial. The thing isn't a coding agent. It's a harness around a model, and what runs in it is whatever you have tools for.

Rick Blalock said it in AI Engineering Miami — coding agent as universal software primitive. A 60-year-old in Texas replaced a $10k/month HubSpot bill by pointing one of these at the problem for three months. A 24-year-old window cleaner in Florida runs marketing, sales, and estimating off the same primitive. Both of them bought MacMinis. Tim Cook didn't have that on his bingo card.

The model question is below the harness question

Here's something I noticed about my own behavior: I'm mainly on Claude. Have been for months. I dip in and out of GPT and Grok and Gemini, but just sort of end up back here. Not because I reasoned out a model strategy — because Claude Code defaults to it and now I'm on Opus all day every day. Amp has its opinion and I try to set Cursor to super max mode, but really the model picked itself by way of the harness picking it for me.

So the perennial "Opus vs GPT-5 vs Gemini 3" argument is pitched one floor below where the action is. It's not model-vs-model. It's harness-with-default-model vs other-harness-with-default-model. The harness drives the model choice, often without telling you.

And underneath that, there's a whole zoo. Frontier reasoning models. Cheap fast models. Code-specific fine-tunes. Local models that run on the GPU you already own. Cerebras-fast inference at 1,200 tokens/sec, a different regime entirely. And the inside-the-harness thing: Tejas Bhakta at Miami called it "everything is models" — a compaction model running every two seconds, a code-search model at 80k tokens/sec, a frontier model doing only the heavy reasoning, all stitched together. Software 3.5, he called it. The harness picks all of that for you, or doesn't, depending on which harness.

Da Vinci anatomical-plate: a single mechanical harness apparatus on top labeled HARNESSIS — UNITAS SUPERIOR with four tool-attachments (LEGERE, SCRIBERE, IMPERARE, ITERARE), and below it a labeled menagerie of seven model 'species' — Frontier, Velox, Codicis, Localis, Compactionis, Quaerens, Cerebras — drawn as small mechanical creatures on aged parchment.

Which means the harness is a model strategy. Picking a harness on purpose means picking which models do which jobs inside it.

So which harness?

A separate post coming soon — each one deserves its own treatment and the conversation moves week to week. The shape of it:

You can build your own in a weekend. About 50 lines gets you the loop. Highly recommend, even if you never use it. Claude Code is the one everyone uses, and — by Anthropic's own model on Anthropic's own benchmark — the worst Claude harness on offer. (Niels Rogge posted Terminal-Bench 2: same Opus 4.6, Claude Code last, ForgeCode and Capy at 70-75%. Twenty-five points of accuracy from picking a different harness.) Picode is Mario Zechner's minimal, self-modifying one — four tools, the agent writes its own extensions, hot-reloads in the session. The most fun one to play with right now. Amp is the one I'm most fascinated with — though to be clear, I'm editing this post in Cursor. The multimodel thing actually works now. In January I wrote that Amp "should be better, but, you know, isn't." Four months later: it is.

Tufte-style horizontal bar chart of Terminal-Bench 2 scores on the same Opus 4.6: ForgeCode 74%, Capy 71%, Picode 62%, Amp 55%, Claude Code 49% — outlined in vermilion. Annotation on the right: 25-point gap from picking a different harness.

The point of this post is the unit, not the catalog.

What I'm still circling

Da Vinci notebook spread with marginalia: a Jetson AGX Thor on a small workbench labeled MACHINA LOCALIS, a brass token-cost gauge labeled STIPENDIUM TOKEN — quanto?, a half-configured harness with question marks labeled HARNESSIS CONFIGURATA — UNITAS NAVIS?, and a small chart of a rising line labeled LINEA NOVA IN STATU FINANCIALI. Sepia ink on parchment, inkwell and quill in the corner.

What's the unit of shipping? Ben Davis's claim in Miami was that it's becoming a directory of skill files plus a coding-agent runtime. That feels right. But the runtime is also moving — picode's bet is that it should be malleable inside the session, so you can't pin it. Maybe the unit is even smaller. Maybe the unit is the harness, configured.

What about the Jetson on my desk. The other thing the bill is about to teach us is that some of this work shouldn't be paying a subscription at all. Local models on local hardware — gpt-oss, Qwen, MiniMax, whatever's frontier-enough for the job — running on the GPU you already own, or the Jetson, or the laptop. Cheap as electricity. No data leaving the building. The harness doesn't care which model it's calling. The bill cares a lot. I think a real chunk of what's running on the second Max plan ends up local by the end of the year.

When the bill becomes a real line item — and it will — what does that conversation sound like? "Cloud spend" took ten years to become its own column on the financial statement. "Token spend" might take less. We're paying for a unit of computation, not for software. Different shape entirely.

I'll get the third Max plan tomorrow. There's another job.

Into the Box 2026 - Keynote - Day 1

Mike's Notes

A video of the keynote speech at Into the Box 2026. Very impressive BoxLang progress, including these new features;

  • Rust VM
  • BoxLang Administrator
  • BoxLang Desktop
  • AI Administrator
  • etc
I will put up all the videos, day 1, day 2, etc.

Pipi 10 (2027-2028)

Pipi 10 will run on BoxLang, continue to use CFML, and also support through its multi-parser architectureBoxLang, Cobol, Groovy,  JavaPHP, PythonRuby, and Rust. More languages are coming.

Pipi Codebase

Over time, Pipi will self-migrate its existing CFML codebase to other languages based on performance, feature set, and other factors. All code languages are great; some are better for some jobs.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library >
  • Home > Handbook > 

Last Updated

02/05/2026

Into the Box 2026 - Keynote - Day 1

By: Luis Majano
Ortus: 01/05/2026

Luis Majano, CEO of Ortus Solutions, has been programming since the age of nine. A Salvadoran innovator, Luis has created some of the most widely used tools in the ColdFusion ecosystem, including ColdBox, ContentBox, and WireBox. His expertise in scalable and efficient JVM solutions drives the BoxLang Runtimes, ensuring they meet the needs of modern development.

Luis is not just a coder; he’s a leader dedicated to fostering a strong community around BoxLang. His hands-on approach and commitment to open-source projects have made him a trusted voice in the industry.

Join Ortus Solutions live from Into the Box 2026 as we kick off Day 1 with a keynote focused on Modernisation in Motion. Discover the latest innovations across the Ortus ecosystem—including BoxLang, ColdBox, CommandBox, and TestBox—and see how developers are building faster, modernising legacy systems, and scaling with confidence.

This session dives into the future of development: cloud-native architectures, AI-driven workflows, and the tools you need to adapt and thrive in a rapidly evolving landscape.

Day 1

Day 2

Join Ortus Solutions for the Day 2 keynote as we continue our journey of Modernization in Motion. Building on the momentum from Day 1, this session dives deeper into the evolution of the Ortus ecosystem—featuring BoxLang, ColdBox, CommandBox, TestBox, and the innovations shaping the future of development.

Explore what’s next: from advanced tooling and performance breakthroughs to cloud-native strategies, AI-driven development, and real-world success stories from the community.

Day 2 is all about going further—turning ideas into execution and equipping you with the tools to build what’s next.

Anthropic Mythos -- We've Opened Pandora's Box

Mike's Notes

This is why Pipi Core is in its own data centre, physically isolated from the internet, to ensure 100% security and protect people's privacy.

I endorse Steve Blank's conclusion. The risks are enormous and growing.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Steve Blank
  • Home > Handbook > 

Last Updated

01/05/2026

Anthropic Mythos -- We've Opened Pandora's Box

By: Steve Blank
The Cipher Brief: 23/04/2026

Adjunct Professor at Stanford and Co-founder of the Gordian Knot Center for National Security Innovation

Steve Blank is an adjunct professor at Stanford and co-founder of the Gordian Knot Center for National Security Innovation. His book, The Four Steps to the Epiphany is credited with launching the Lean Startup movement. He created the curriculum for the National Science Foundation Innovation Corps. At Stanford, he co-created the Department of Defense Hacking for Defense and Department of State Hacking for Diplomacy curriculums. He is co-author of The Startup Owner's Manual.

EXPERT OPINION

For a decade the cybersecurity community was predicting a cyber apocalypse tied to a single event - the day a Cryptographically Relevant Quantum Computer could run Shor’s algorithm and break the public-key cryptography systems most of the internet runs on. We braced for a one-time shock we would absorb and adapt to. The National Institute for Standards and Technology (NIST) has already published standards for the first set of post-quantum cryptography codes.

It’s possible that the first cybersecurity apocalypse may have come early. Anthropic Mythos now tilts the odds in the cybersecurity arms race in favor of attackers - and the math of why it tilts, and how long it stays tilted, is different from anything our institutions were built to handle.

In 2013, Edward Snowden changed what people knew

In 2013, Edward Snowden changed what people understood about nation-state cyber capabilities. In the decade that followed disclosures and leaks of nation state cyber tools reduced uncertainty and accelerated the diffusion of cyber tradecraft.

The defensive playbook that followed - compartmentalization, need-to-know, leak-surface reduction, clearance reform, “worked” because the Snowden leaks and those that followed were one-time disclosures, absorbed over a decade, with the system returning to something like equilibrium.

We got good at responding to the shocks of disclosures. It became doctrine. It was the right doctrine for the wrong future.

Pandora's Box

In 2026, Anthropic Mythos (and similar AI systems) is changing what people can do. Mythos found Zero-day vulnerabilities and thousands of “bugs” that were not publicly known to exist (a must read article here.) Many of these were not just run-of-the-mill stack-smashing exploits but sophisticated attacks that required exploiting subtle race conditions, KASLR (Kernel Address Space Layout Randomization) bypasses, memory corruption vulnerabilities and logic flaws in cryptographic libraries in cryptography libraries, and bugs in TLS, AES-GCM, and SSH.

The reality is a number of these were not “bugs.” There were nation-state exploits built over decades.

What this means is that Anthropic Mythos, and the tools that will certainly follow, has exposed hacking tools previously only available to nation-states and transformed into tools that Script Kiddies will have within a few months (and certainly within a year.) No expertise will be required to apply that tradecraft, compressing both the learning curve and the execution barrier.

All Government’s Will Scramble

When Mythos-class systems are used to analyze the code in critical infrastructure and systems, the hidden sophisticated zero-day exploits that are already in use, (including ones nation-states have been sitting on for years) will be found and patched. That means intelligence agency sources of how to collect information will go dark as companies and governments patch these vulnerabilities.

Every serious intelligence service will scramble, likely with their own AI, to find new access before the visibility gap costs them something they cannot replace. A new generation of AI-driven exploits will rise to replace the ones that have been burned.This will build an arms race with a new generation of AI-driven cyber exploits looking to replace the ones that have been discovered. Whichever side sustains faster AI adoption - not just “procures” it, but ships it into operational systems, holds a widening advantage measured in powers of two every four months.

The binding constraint is not budget. Not authority. Not access to models. It is institutional capacity for change - the rate at which a defender organization can actually change what it deploys.

The Long Tail Will Not Be Patched

Anthropic has given companies early access to secure the world’s most critical software. That will help Fortune 100 companies. But the Fortune 100 is not just a small part of the software attack surface.

The attack surface includes the unpatched county water utility, the regional hospital, the third-tier defense supplier, the school district, the state Department of Motor Vehicles, the municipal 911 system, and the small-town electric co-op. Tens of thousands of systems running software nobody has time to patch, maintained by teams that have never heard of KASLR.

Every one of those systems is now exposed to nation-state-grade tradecraft, wielded by attackers with no expertise required. Mythos-class hardening at the top of the pyramid does not trickle down. The long tail will stay unpatched for years.

Attackers Advantage - For Now

Under continuous exponential growth of AI designed cyberattacks, a cyber defender using traditional tools can't just respond just once and stabilize their systems. They’ll need to keep investing at a rate that matches the offense's growth rate itself. A one-time defensive shock like compartmentalization might work against a sudden attack, but it will fail against sustained exponential pressure because there's no stable equilibrium to return to. The defender's investment rate has to track the offense's growth rate.

Ultimately and hopefully, the next generation of AI driven cyber-defense tools will create a new equilibrium.

What We Need to Do

Mythos and its follow-ons will change how we think about cyber-defense. We can’t just build a set of features to catch every exploit x or y. We need to build cyber systems that can maintain or exceed the capability rate of the attackers.

Here are the three tools governments and cyber defense companies need to build now:

  1. Measure the Gap Between Attackers and Defenders. We need to know the gap between what the attackers can do and what we can defend against. We need to develop instrumented red/blue exercises (a simulation of a cyberattack, where two teams – the red team and the blue team – are pitted against each other) to estimate the number of new vulnerabilities vs cyber defense mitigation. (This can be built in six months, with a small team.)
  2. Measure the Defender Response Time. For each corporate or government mission system, measure how long it takes to implement a change from identification to production deployment. Treat each organizational obstacle as equivalent to technical debt that needs to be remediated.
  3. Specify Speed, Not Features. Any new Cyber Defense tools and architecture - including the next-generation cloud-native systems sitting in review right now - should have explicit ‘rate’ requirements. Claims of “our product delivers X capability is now the wrong specification. “Closes detection gap at rate greater than or equal to the offense growth rate” is the right one.

Buckle up. It's going to be a wild ride - for companies, for defense and for government agencies.

Mythos is a sea change. It requires a different response than what the current cyber security ecosystem was built for, and one the current system is not built to produce. We are not behind yet. The gap between Mythos and what we can build to defend is small enough today that a serious response can still match it. A year from now, the same response will be eight times too slow. Two years, sixty-four.

By the way, the only thing left in Pandora’s Box was hope.