Running Pipi on Cerebras using SDK

Mike's Notes

Pipi doesn't use vectors, which means no need for GPUs. Pipi 9 is designed to run on CPU + Cerebras Wafer-Scale Engine-3 (WSE-3) and maybe a little occasionally leased TPU. 

Here are some working notes copied from the Cerebras SDK, plus experimental code written for Pipi to run on 900,000 AI cores on a single wafer. The wafers are the size of dinner plates and very power-efficient compared to GPUs, which use matrix multiplication.

This is a promising long shot, very expensive, and will need a bit of discovery and a lot of learning😎.

Resources

References

  • Reference

Repository

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

Last Updated

05/08/2026

Running Pipi on Cerebras using SDK

By: Mike Peters
On a Sandy Beach: 01/08/2026

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

Big picture

  • Pipi runs very well on CPU. 200 autonomous agents can run on a 16GB utility server. Why use vectors?
  • Running genetic algorithms in a fitness landscape would be better done on a Cerebras Wafer-Scale Engine. I need to test that assumption.
  • Got the CSL and Python code ready to test.
  • Can test on a local sandbox and then run further tests on a VM in the cloud using cheap spot compute.
  • Start with small arrays and scale up, trying different fitness algorithms.
  • Pipi could easily automatically run this deploy to GCP, run, get result, destroy cloud deployment.
  • Later, run directly on Cerebras (will require research grade, given using SDK to directly configure wafer cores).
  • Talk to Andrew at SemiAnalysis.

From Cerebras SDK

"

Cerebras SDK: A Conceptual View

Learn how the Wafer-Scale Engine architecture works, how processing elements communicate, and how the host and device interact.

The Cerebras Wafer-Scale Engine (WSE) is a wafer-parallel compute accelerator, containing hundreds of thousands of independent processing elements (PEs). The PEs are interconnected by communication links into a two-dimensional rectangular mesh on one single silicon wafer. Each PE has its own memory (used by it and no other) and its own program counter. It has its own executable code in its memory. 32-bit messages, called wavelets, can be sent to or received by neighboring PEs in a single clock cycle.

The PE also has dataflow control characteristics. An instruction can terminate the currently running thread (called a task), at which time, hardware selects a new task from among the set of tasks that constitute the PE’s code. It selects a runnable task, one that has been activated (and unblocked; we will describe this in more detail later). Incoming wavelets travel along a virtual channel, called a color. All colors transfer data on a single physical channel. The congestion of one color does not block the traffic of another color. For each color used for incoming wavelets, there may be a task that is activated by its arrival.

The Cerebras System (CS) is a self-contained rack-mounted system containing packaging, power supply, cooling and I/O for a single WSE. The CS communicates via parallel 100 Gigabit ethernet connections to a host CPU cluster. Throughout this documentation, the CS is referred to as the “device,” the host CPU cluster as the “host,” and the ethernet connections connecting the two as “host I/O”. The SDK provides mechanisms for using host I/O to move data between host and device or launch functions on the device.

The below figure gives a visual representation of the mesh of PEs that make up the WSE, and its connections to the outside world. Data is streamed onto the device via host I/O, and enters the WSE through a series of links along its edges. The programming model of the SDK abstracts away the details of these links, and allows the programmer to copy data from the host to arbitrary PEs on the device.

A Processing Element (PE)

A PE contains three key elements:

  1. A processor. Also referred as a compute engine (CE).
  2. A router. The router of a PE is directly connected via bidirectional links to its own CE and to the routers of the four nearest neighboring PEs in the mesh. The link to its own CE is called the RAMP, and the links to the four neighboring PEs are referred to by their cardinal directions. The router is the only communication device the PEs use to send and receive data.
  3. The local PE memory. All of the PE’s data and code are stored within this memory. Neither the CE nor the local memory of a PE is directly accessible by other PEs.


The Programming Model

To develop code for the WSE, you write device code in the Cerebras Software Language (CSL), and host code in Python. You then compile the device code, and run your program on either the Cerebras fabric simulator, or the actual network-attached device. The host code is responsible for copying data to and from the device, and launching discrete programs referred to as kernels.

... "

By , No comments:
Tags , , ,

Digital Accessibility Training

Mike's Notes

I stole this content from all over the place. Sorry if I didn't credit you; I forgot where this came from. All useful stuff.

Resources

References

  • Reference

Repository

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

Last Updated

04/08/2026

Digital Accessibility Training

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

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

Accessibility For Everyone (https://lnkd.in/dVvgMG29), a wonderful free book on web accessibility for designers, developers, content folks — pretty much everyone. Written 9 years ago, but still very much relevant today. With sections on disabilities, impairments, planning for accessibility, design and testing. Kindly released by Laura Kalbag.

Free Books on Accessibility

Giving A Damn About Accessibility, by Sheri Byrne-Haber (disabled)

PDF: https://lnkd.in/eqbz5Npw

  • Audio: https://lnkd.in/emYMbEDc

Web Accessibility In Plain Language, by Charlie Triplett

  • https://lnkd.in/e2AMAwyt

AccessAbility Playbook, by Government of Canada

  • https://lnkd.in/e2W3viJb

Appt Accessibility Handbook, by Jan Jaap de Groot, Paul van Workum CPACC

  • https://lnkd.in/e3V7eTU9

Accessibility Foundations (Free Guide), by Henny Swan

  • https://lnkd.in/erGd9vX7

WCAG 2.2 Card Deck (Updated!), by Johannes Lehner

  • https://lnkd.in/eQgDsY9j

Free Practical Books For Designers

  • https://lnkd.in/dsxAukXq

And a *HUGE* thanks yet again to wonderful Laura Kalbag and everyone sharing their insights, learnings, and experiences in wonderful resources like these — for everyone to learn from and build open. Your work doesn’t go unnoticed!

By , No comments:
Tags , , , , ,

How I work effectively

Mike's Notes

I found it helpful to get this down on paper, so the process I use is conscious and can be tweaked over time.

This process has slowly evolved over many years since I was 15, when I started by grabbing non-fiction public library books off the shelves each week based on intuition. Practising this visual learning method, getting better over time and adding more steps seems to have worked a treat.

Most important is testing all assumptions.

I'm happy to receive suggestions.

Resources

References

  • Reference

Repository

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

Last Updated

03/08/2026

How I work effectively

By: Mike Peters
On a Sandy Beach: 30/07/2026

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

My creative problem-solving and build process is evolving, and the loop is getting faster.

  • Understanding the problem starts with reading or talking with someone, watching a YouTube talk, or listening to the radio.
  • Do lots of research, mostly reading books (days to months).
  • Cheap thought experiments. What ifs.
  • Drink plunger coffee.
  • Print off a paper(s) or article(s) and file it in an indexed A4 3-hole ring-binder.
  • Drink Chamomile tea.
  • Daydream (solutions come within hours or months later).
  • Drink plunger coffee.
  • Draw the solution as many colour-coded A4 architecture drawing(s).
  • Drink more coffee (Cappuccino).
  • File the drawing(s) with the printed paper.
  • Use the drawings to prompt Google Search AI Mode (free) with detailed instructions on what to build.
  • Output teaches me, describes data model, code, documentation.
  • Print off and file with the rest.
  • Walk a dog. Plant a tree. Watch the sun rise.
  • Read the printed AI output, colour-code, add doodles, correct, test, edit names, build, use in Pipi, while listening to music. (I don't copy-paste. I manually type to copy, because it helps me learn and understand.)
  • Throw away all the paper except for the original research, which is moved from DevOps to the research library.
  • Pipi then generates self-documentation, including mermaid drawings.
  • Repeat.

Each loop cycle takes weeks to years. There are hundreds of cycles running in parallel at any one time. It's a pull system. I work on Pipi when something needs to be solved using my library of solutions. Totally intuitive, like an artist, not an engineer, and always fun like a kid playing with Lego.

Another important part of this process is writing up notes for this blog. As a slow writer, I need to allocate a regular slot each day to do this using Grammarly. I find it reflective; it makes me think a lot. A bit like teaching someone else a skill you have.

It's becoming more important to have regular habits (an autism strength) and replace personal deadlines with going with the natural flow (artistic strength). It's more productive in the long run.

These changes are made possible because of the detailed work done over the last few months, removing barriers, including modifications to Pipi, reorganising space, equipment, and routines. It's also been made possible by the rapid advances in LLMs in 2026.

I think I have now solved all major problems to get Pipi 9 Core (Loki) running 24x7x52. Anything else that pops up can be quickly solved along the way as part of maintenance.

Now to execute very fast.

By , No comments:
Tags , , , ,

Jessica Kerr on Symmathesy

Mike's Notes

I was watching "A Learning System Made of Learning Parts" on Still Burning, an episode of Kent Beck's video blog.

Jessica Kerr joins Kent by the fire to argue that AI didn't take the programmer's job; it split it in two. The part we loved, crafting code by hand, has been commoditised like IKEA furniture. What's left is harder and more human: understanding what to build, proving it works, and stewarding the living "symmathesy" of people, code, and agents all learning from each other. They get into accelerated learning, why play is a signal you're learning, the loop that "becomes a noose," and choosing excitement over fear while the ground keeps shifting."

Resources

References

  • Symmathesy — A Word in Progress Proposing a New Word that Refers to Living Systems. Nora Bateson. Nora Bateson Foundation

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Still Burning
  • Home > Ajabbi Research > Library > Authors > Kent Beck
  • Home > Handbook > 

Last Updated

02/08/2026

Jessica Kerr on Symmathesy

By: Jessica Kerr
Jessitron: 15/04/2018

Jessica Kerr manages the Developer Relations team at honeycomb.io, because observability is one way our teams learn from our software. In speaking and teaching, Jess works across languages and communities, spreading cheerful deep thoughts. Code, tools, and people are not separable; all form the team that operates useful software.

Symmathesy is a term coined by filmmaker and systems theorist Nora Bateson in 2015 to describe a learning system made of learning parts, emphasising mutual learning that occurs within and between living contexts. Derived from the Greek roots sym (together) and mathesi (to learn), it serves as a response to mechanical, rigid frameworks by shifting the focus from individual elements to the dynamic relationships that generate evolution and adaptation.

In a symmathesy, learning is not an isolated process of acquiring information; it is an ongoing, multi-contextual process of mutual adjustment and calibration.

Collective problem solving in music, art, science, and software

A Learning System Made of Learning Parts

By , No comments:
Tags , , , , ,

Why Handwritten Notes Matter Now More Than Ever

Mike's Notes

So true.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > 1000 Libraries Magazine
  • Home > Handbook > 

Last Updated

01/08/2026

Why Handwritten Notes Matter Now More Than Ever

By: Vincent Phan
1000 Libraries Magazine: 15/06/2026

Editor-in-Chief, 1000 Libraries Magazine. At 1000 Libraries, we believe in humanity’s inherent goodness and celebrate the enduring power of books as symbols of our capacity to do good. In a world dominated by digital noise and disheartening news, we cherish the joy of reading—a quiet yet powerful revolution. Our mission is to make inspiration accessible to everyone through the best book-related stories, fostering a diverse, non-religious, non-political community of book lovers who are keeping the written word alive in the 21st century. 

Discover why writing by hand makes the brain work harder, remember more, and process information deeper than typing on any keyboard.

Dear Juliet,

I’m writing to you, in this beautiful city of Verona, to tell you of my own tale of love. Everyone has heard the story of you and Romeo and fallen quite in love with it, although in truthfulness we hope our own affairs have gentler endings. I am here, putting pen to paper, because some tales deserve effort. And because, even if I don’t admit it to myself, writing down such details makes them all the more real.  

For the lovers and romantics out there, a letter like this might ring familiar. In the city of Verona, Italy – the backdrop for Shakespeare’s Romeo and Juliet – there exist those who still believe in the power of handwritten letters. 

The ‘Secretaries of Juliet’ are the guardians of love letters, and they have been since 1972. In the 1930s, Ettore Solimani, the guardian of Juliet’s Tomb, noticed he was receiving letters addressed to Juliet. These powerful letters of love touched Solimani in such a way that he never left one unread. They moved him so much that he began to reply to each notelet of love, and thus he became the original ‘Juliet’s secretary.’ 

Why Handwriting Feels Human

Photo Credit: Tehiya Benzur

Each year, the ‘Juliet Club’, a club made up of many such secretaries of Juliet, receives tens of thousands of letters. All of them are simply addressed to ‘Juliet, Verona’, and each one of them ends up read, translated, and responded to. People from all cultures, who speak all languages, have poured their hearts out and into their ink, all to be read by a stranger, often on the other side of the world.

Photo Credit: DongHyun Park

These letters contain something rarely seen in our digital age – a sense of vulnerability and raw imperfection. Unlike a laptop or computer, handwritten notes or letters cannot be easily erased or started again. You have to carefully consider the things you want to say and accept that they might not be what we consider ‘perfect’. Humans, or any non-robotic entity, have flaws.

We put our own human fingerprint into everything we do, mostly without realising it. Yet this only adds to the beauty. Anyone can create and read AI-generated articles or stories, but most of us are (thankfully) more drawn to things crafted by human beings, imperfections and all. 

Why the Brain Prefers Pen and Paper

The beauty of the handwritten extends past just the human fingerprint. Beyond literary appeal, handwriting is often better for our brains. Despite most of our lives – professional, academic, and personal – moving onto screens, one cannot deny the scientific evidence that suggests a return to the era of analogue. 

Typing takes mere seconds, but handwriting takes much longer. Some may see this as an inconvenience, time wasted, but neuroscience argues that this added time embeds the information into our brains. Writing out each word in pencil or ink doesn’t just look better but slows our minds down enough to consider what we are writing.

We think about the ideas, the information, and the meanings contained within them. Such an activity engages our motor, visual, and language skills, and helps us truly understand and memorise the content of our writing. 

What Neuroscience Says About Writing by Hand

Schoolchildren who grew up having to physically write all of their notes and assignments might have complained about such labour, but perhaps they were able to better retain the information they wrote. In fact, if we were to look at the scientific literature, we could say they definitely retained this information better. Audrey van der Meer, professor of neuropsychology at NTNU, found that students of this generation were often ‘typing without thinking’. Hearing the words and repeating them on their screens, with little interaction with their content. Prioritising swiftness rather than subject matter. 

To further test this hypothesis, researchers set up a test that examined the brain activity of a group of students as they were writing. The first time they ran the test, students wrote by hand; the second time, they typed. The difference was astounding. Handwriting lit up brains like a summer carnival, whilst typing produced minimal activity. Unlike a key on a keyboard, a person writing feels the difference between each letter. There is a bodily experience for each new word or phrase. Experiences like these help inform the brain of a person’s next action and give them the necessary information on how best to act in their environment.  

So, whilst critics might complain that writing is ‘outdated’, can we really call it ‘progress’ if it achieves worse results? The digital age has brought many undeniable benefits – but that was never in contention. Now we should perhaps question how much digitalisation is too much and allow the simple pleasures of handwriting to slow down our brains. 

Slowing Down in a Digital Age

I am not claiming to exist sans technologie, but I know my mind thanks me for returning to ink and paper every so often. I truly believe we are all continual learners. Graduating from school does not mean graduating from life – and being the best, most empathetic versions of ourselves means being an eternal student. So, when I find a subject that I am intrigued by, I make a note to write down whatever I learn by hand. After all, often the smallest changes make the biggest difference.

Perhaps people still write handwritten letters to Juliet because they know love deserves time. Our innermost thoughts – whether they are full of light or darkness – are those that demand to be written.

By , No comments:
Tags ,

No posts for a wee while

Mike's Notes

I was on holiday for the last few weeks and am back now. There will be no blog posts, newsletters or meetings until Pipi Core is back up and running.

Update 27/05/2026

Lots of surprises. Making rapid progress. The peace and quiet are bliss.

Update 31/05/2026

The problem and solution are how things are named. Pipi auto-generates thousands of code names using multiple pattern languages, and all the naming conventions require many minor fixes for several unexpected reasons after migrating from a developer laptop to a production server environment. Everything else is absolutely fine.

Other naming problems are also being solved now, including:

  • The rapid development of Boxlang by Ortus has brought forward another challenge. Pipi 10 will be migrated to run on top of Boxlang in 2027 to support multiple languages, including C++, CFML, COBOL, Go, Java, JavaScript, PHP, Python, Rust, etc.
  • Future integration with cloud-based LLMs.
  • Future integrations with Office365, Google Workspace, Zoho, LibreOffice, etc.

The common solution is to create standardised naming systems that are simple, stable, robust, schema-based, versioned, self-documenting, and extensible to meet unanticipated future needs.

This is done by replacing code-based naming rules with database-driven ones that can be easily edited in the future via an admin UI.

90% of these names are internal, hidden in the closed core, and how they work and what they are will not be discussed here. The rest will be publicly and fully documented as part of the open-source workspaces for developers to work with.

Update 02/06/2026

I'm changing the disclosure boundary between the Pipi closed-core and open-source workspaces. Previously, "disclose everything unless there is a security reason not to". This is now changed to "disclose on the basis of need to know".

Closed-core accounts for 90% and open-source workspaces for 10% of lines of code, databases, etc.

This will reduce the documentation burden, given Pipi's vast scale. So, the open-source workspaces will be fully shared and documented on GitHub, etc, without restriction. This includes;

  • Standards schema
  • Ontologies
  • Parameters
  • Laws of physics
  • HTML + CSS
  • Algorithms
  • Module DDD models
  • Workflow diagrams
  • Documentation
  • API schema
  • UI code
  • etc

This also means some existing technical documentation about the closed-core will become hidden and only available internally.

Update 07/06/2026

Pipi Core is the IDE used to edit Pipi Core (AKA: which came first, the chicken or the egg?). Temporary UIs have been created and are being used across multiple engines to edit the names in use. This is much faster than directly editing data, which had to be done initially. The next step will be turning auto-generation back on. Once that's done, temporary UIs will be used to build permanent UIs. More automation will then be enabled via the UIs, and so on, as Pipi Core builds itself with a human in the loop.

Update 08/06/2026

The list of code cases available to use now for auto-generated naming, I/O translation, etc with examples, includes;

  • camelCase: userProfilePicture
  • kebab-case: user-profile-picture
  • PascalCase: UserProfilePicture
  • snake_case: user_profile_picture
  • SCREAMING_SNAKE_CASE: USER_PROFILE_PICTURE
  • Train-Case: User-Profile-Picture
  • flatcase: userprofilepicture
  • UPPER-CASE-KEBAB-CASE: USER-PROFILE-PICTURE
  • Sentence case: User profile picture
  • Title Case: User Profile Picture
  • middot·case: user·profile·picture
  • dot.case: user.profile.picture
  • UPPER CASE: USER PROFILE PICTURE
  • lowercase: user profile picture

Update 12/06/20026

Checking that these changes to variable names and internal messaging do not clash with the Gödel Machine.

Update 17/06/2026

The DevOps Engine (dvp) has unexpectedly proven to be critical to solving this puzzle. Mostly fixed last night. Watching the rather excellent live Google talk, Beyond the GPU: Maximising goodput with self-healing AI infrastructure, this morning has given me valuable insights into how to fix the remaining issues by reviewing Google HPC YAML files. 😎😎 Sometimes insights come from the strangest places.

Update 01/07/2026

The main work now is rapidly configuring Pipi for production and full autonomous automation. Using Google Search AI Mode (Gemini) and then Grammarly Pro makes the work easier and 100x faster.

  • I have decided to have Pipi re-render the many Ajabbi draft public websites with the new and missing developer information. (20K pages)
  • The website's .robot.txt file will then be unlocked to enable search engines.
  • The HTML will be updated to make it easier for AI to read.
  • This blog will be imported into Pipi, cleaned up, re-exported from Pipi, and published to Blogger via the API.
  • The new posts created in Pipi will return to A Sandy Beach to discuss something already built rather than being built.

Update 02/07/2026

The DevOps and IaC engines are getting rapid data model overhauls. The IaC engine is a great test for the variable names. I'm building a capability into Pipi to autonomously and automatically run OpenTofu and Ansible, initially targeting the Pipi Data Centre, then GCP and AWS for deployments. It's going very well and making rapid progress.

Update 05/07/2026

Pipi will initially run the open-source enterprise applications on Google Cloud Run and Google Cloud Storage (GCS). The code is complete and will be very low-cost to run, giving Ajabbi, a bootstrapping-purpose startup, a very long runway.

Update 18/07/2026

The job has now shifted to configuring, networking and deploying many physical servers. Installing software, including Pipi, labelling cables and rack gear, throwing out junk, tidying, etc., leaving nothing to chance. Shipping delays are holding up part deliveries.

Update 28/07/2026

Most of the equipment has arrived, and the small data centre setup is coming together. More deliveries later this week. It's already running a lot better and is much more productive.

Update 31/07/2026

Work on Pipi has reached a tipping point or system phase change as Pipi takes over tasks using autonomous automation. Pipi now has deadlines, not me. Soon it will set the deadlines. It's now a downhill run; daily posts from me resume tomorrow, and much more will come.

In hindsight. This whole project has been systematic trial and error, spending 10 years learning how to crack a hard problem.

Resources

References

  • Reference

Repository

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

Last Updated

31/07/2026

No posts for a wee while

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

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

I was on a no-coding holiday for the last few weeks to clear my mind, and it has been great. I am back on the job today.

Suspended

Until the closed-source Pipi Core is back up and running 100% on autopilot, 10x faster, the following are suspended.

  • New posts "On a Sandy Beach
  • All newsletters, including the weekly Friday Report and the monthly Ajabbi Research Newsletter.
  • The fortnightly online Open R&D meeting.

Rapid refocus

  • A new developer area with five coding screens, designed to be more productive for hypervisual learners.
  • A better library has been set up for my A4 drawings in ring binders, the many reference books I use, and more bookshelves are on the way.
  • The server rack has been moved to a better location.
  • The light levels have been adjusted.
  • A big office tidy is almost done. An office-work-only desk has yet to be set up with a cat bed included.
  • A separate area with no screens for the happy cat, coffee, music, reading and drawing.

Less is more

Minimise screen time to be more productive at work. The new setup is also much less tiring.

Get the job done

The good thing is that, with a holiday and lots of drawing, I now have mental clarity about what needs fixing and how to fix it. Mainly, quite delicate changes here and there, organised into a list of steps. Now, I need to concentrate on one thing only: go as fast as possible, without meetings, post-deadlines, phone calls, or other distractions.

How

1. Use an AI workforce

Be the architect, and AI fills in the dots to make it happen.

Use Google Search AI mode (Gemini) to generate 99% of the code in one-page chunks (including references) to copy and paste, then manually change the variable names and SQL. Careful, test everything, resulting in 100x faster progress. Know how everything works and rapidly raise personal skill level.

2. Then build a cathedral

Make a wooden scale model of a cathedral for the builders. Google Search AI mode (Gemini) makes each brick, and Pipi Core assembles the bricks into floors, arches, walls, and vaults...

Speed is king

With the 100x coding productivity gains from Google Search AI mode (Gemini), plus the 10x10x10x speedup of Pipi Core currently underway over the next few months, what previously took a year will be done in hours and better.

Phase transitions

Once these initial migration issues from laptop to server are resolved, further transitions can be anticipated as the number of engines rapidly increases beyond 20. Increasing the number of engines slowly changes the whole system's behaviour from deterministic to probabilistic and adaptive.

Here is a partial list of transitions expected as the number of engines increases from 0 to 200. The actual numbers are a bit of a guess.

  • 20 engines enable Pipi 9 Core in a simple, deterministic structure.
  • 40 engines enable a workspace with a UI for administering Pipi Core.
  • 60 engines enable self-generation of user documentation.
  • 80 engines enable REPL and IAC (infrastructure-as-code).
  • 100 engines enable Workspaces for different user accounts.
  • Different Pipi 9 editions are made with the same engines, which recombine differently in response to the external environment.
  • And so on until...
  • 200 engines self-organise into a multi-layered complex fluid structure with probabilistic behaviour and emergent properties, as engines also act as agents.
  • 200+ engines enable Pipi 10 to interact with externally cloud-hosted LLMs, combining the very different strengths of both.
By , 2 comments:
Tags , , , , , , , , , , , , , , , ,

The luxury of statistics

Mike's Notes

A great article by David Court lays out a fundamental truth about the business of filmmaking.

Resources

References

  • Reference

Repository

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

Last Updated

08/05/2026

The luxury of statistics

By: David Court
Compton: 03/05/2026

Founder of Compton School, the business school for creative people: ‘The movie industry is a crucible where money and talent are refined down to their essence. It has so much to teach us about business, creativity and human nature.’

Why filmmakers can never see eye-to-eye with movie studios.

When filmmakers and studio executives come together there is always a great display of bonhomie.

Hands get shook and backs get slapped. As though they were bound together in their mutual enterprise: the movie business. Perhaps there’s some argy-bargy about profit shares but basically they are on the same page.

Yet the truth is: there is a fundamental disjunct between filmmaker and executive.


It’s not just that one is on salary while the other is eating their savings. Nor is it the power imbalance between them, or the different pathways they have followed to arrive where they are. It’s that one is operating at 30,000 feet and the other is dug in at ground level.

If you’re making a film, it occupies your entire field of view. You can’t see past it. You don’t have time or bandwidth to think about anyone else’s film. You are all in on one thing — the film you are making.

This is true financially too. You have put all your chips down on one square and you can’t take them back. Whereas the studio executive is managing a slate of films. They’ve got chips on 20 squares.

Harvard professor Mihir Desai calls this the core of finance. He starts his book The Wisdom of Finance with a story about chance and pattern. Chance is what the world looks like close up: an arena of luck, accidents, flukes, coincidences, or what the ancients called fortuna.

Whereas pattern is chance viewed over time – statistically. It’s what we notice when we study the world and keep records. It’s the view from 30,000 feet.

‘Finance, ultimately, is a set of tools for understanding how to address a risky, uncertain world’ – Mihir Desai

The study of patterns is what gave us the insurance business (the averaging of bad luck), portfolio theory in finance (strategic diversification) and the studio slate (the search for a hit). These are all methods of managing risk, of taming fortuna.

But our filmmaker has wandered into a casino and bet everything on single spin of the wheel. Their risk is irreducible. They don’t have the luxury of statistics.

So for all the backslapping, the studio executive and the filmmaker are really two different species. Different stakes, different aims, different view of the world.

For our filmmaker, chance is the whole point. The risk is not to be managed but to be taken.

This post is the first in a series I plan to publish based on my reading – the insights I’ve gathered and think worth sharing.

By , No comments:
Tags ,

Context Engineering for Coding Agents - Fausto's Amsterdam workshop

Mike's Notes

The MLOps Community is fantastic, and it has a regular newsletter from Demetrios.

100% better than anything coming out of NZ  or Australia. I attend MLOps events remotely whenever possible. Now I know where to find the talent capable of working on Pipi in future.

This is taken from a recent newsletter. Interesting how deterministic and probabilistic contexts are handled in generative AI.

All Pipi Engines are both deterministic and probabilistic as required.

The April 21 2026, MLOps Community Netherlands workshop video and slides are available.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > MLOps Community
  • Home > Handbook > 

Last Updated

10/05/2026

Context Engineering for Coding Agents - Fausto's Amsterdam workshop

By: Demetrios Brinkmann
MLOps Community: 07/05/2026

Demetrios founded the largest community dealing with productizing AI and ML models. In April 2020, he fell into leading the MLOps community (more than 75k ML practitioners come together to learn and share experiences), which aims to bring clarity around the operational side of Machine Learning and AI. Since diving into the ML/AI world, he has become fascinated by Voice AI agents and is exploring the technical challenges that come with creating them.

Fausto's workshop focused on the part of agent systems you can control: what gets injected into the context window, when it gets loaded, and what should live somewhere else. You are not training the model on a daily basis, so the engineering work shifts to managing context, memory, tools, and retrieval.

His rule of thumb was to keep context usage under 25%, regardless of whether you are working with a 200k or 1M token model. Past that, things get slower, more expensive, and more error-prone, with cleaner options than letting the context window bloat.

The lens for the rest of the talk was a brain analogy. Attention is finite, memory shapes attention, and knowledge does not get embedded in a vacuum. An agent will only notice the right things if you have given it the right priors.

From there, Fausto split context into three categories.

  • Deterministic context includes CLAUDE.md, project rules, hooks on lifecycle events, auto-memory, and scheduled loops. His point on rules was especially practical: coding conventions belong in path-scoped or file-extension-scoped rules, not dumped into CLAUDE.md.
  • Human context covers chat turns, slash commands, and references.
  • Probabilistic context covers sub-agents, retrieval, MCPs, skills, and observers. Sub-agents are useful because they do not inherit CLAUDE.md, memory, or the default system prompt, which makes them better suited for specific non-coding tasks. Skills are markdown plus optional scripts, and can also wrap calls to other models when Claude cannot handle the job. Fausto's example was routing native video analysis through Gemini.

Two practical tips came out of this section. Turn on deferred tool loading, a single flag that reduces what gets injected at session start. And lean toward project scope over user scope for skills and MCPs, so the agent has the full descriptions it needs to choose well at runtime.

The second half made the case for treating long-term memory as a folder of markdown files rather than defaulting to a vector store, inspired by Karpathy's wiki memory idea.

The structure is an index plus raw source files, processed summaries, and a policy that decides what to ingest and retrieve. Concepts that recur get weighted up. Concepts that go unused decay over time. An observer agent watches the session and either pulls relevant knowledge into the active context or pushes new findings into the wiki.

To show the difference in practice, Fausto ran two Claude Code sessions on the same cellular automata task. Same model, same skills, same sub-agents, same CLAUDE.md. The only difference was that one had a populated wiki and the other did not. Under a five-minute timer, the wiki run pulled the concepts it needed and produced a working visualization. The default run fell back on parametric memory and live search, then ran out of time.

Context Engineering for Coding Agents: Hands-on Lab + Agent Build-Off

21 April 2026
Prosus NV
Gustav Mahlerplein 5, 1082 MS Amsterdam, Netherlands

A hands-on workshop on configuring Claude Code for real work.
​Claude Code is powerful out of the box. But there's a gap between using it and mastering it. Closing that gap is mostly a matter of context: what the agent knows, where its memory lives, which rules it follows, and how its output gets verified before it ships.

​This workshop is three hours of hands-on practice to optimize your Claude environment. After a short primer you join a pre-assigned team and build out a Claude Code setup in a prepared sandbox — working on memory, rules, hooks, retrieval, and prompt quality. In the final stretch we drop an unknown technical drawing on the screen and your system gets one run at it. Scores go on a live leaderboard, winners are announced in the room.

​What you'll practice

  • ​Shaping what the agent sees and remembers
  • ​Writing rules and hooks that actually fire
  • ​Designing memory so it finds what matters
  • ​Judging output before it leaves the loop

​Format

​One continuous team build, one unknown challenge, one live leaderboard, closing with pizza and drinks. — The system you build in 60 minutes is the score you receive.

​Agenda

  • ​5:00 PM — Walking dinner & Drinks
  • ​please be on time :)
  • ​5:30 – 5:45 PM — Welcome by Prosus
  • ​Opening and framing for the evening.
  • ​5:45 – 6:00 PM — Opening
  • ​6:00 – 7:00 PM — Theory + Mini-Demos
  • ​7:00 – 8:00 PM — Build Lab
​Six phases: mission lock, sandbox orientation, second brain, skills + guardrails, self-test, freeze. Teams build their Claude Code system against the run contract. Facilitators float; the deck runs a silent timer.
  • ​8:00 – 8:15 PM — Drawing Reveal + One-Shot Run
  • ​An unknown technical drawing is broadcast into every team sandbox. Each system gets a single run. Whatever it produces is what gets scored.
  • ​8:15 – 8:20 PM — Processing Break
  • ​Last runs finish, evaluator collects output.
  • ​8:20 – 8:30 PM — Live Leaderboard + Winners
  • ​Scores land on screen. Jury walks through the top runs and the most interesting architectural choices.
  • ​8:30 – 9:00 PM — Pizza + Networking
  • ​Pizza, drinks, Q&A.

​Who this is for

​Technical practitioners who have already used Claude Code (or a comparable coding agent) and want to push past the default setup. Comfortable on the command line, and with Github, fluent enough in Python to read and edit a small repo.

​What we provide

  • ​A pre-configured cloud sandbox per team, with Claude Code installed and API access included. Minimum requirement is to have a Claude Pro account — and bring your laptop.
  • ​Registering is not a confirmed seat — we curate the room and send confirmations separately
​Delivered by Fausto Albers · GenAI R&D, AUAS · WonderWhy.ai

YouTube 2:27:28

By , No comments:
Tags ,

3 constraints before I build anything

Mike's Notes

Note

Resources

  • https://jordanlord.co.uk/blog/3-constraints/

References

  • Reference

Repository

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

Last Updated

08/05/2026

3 constraints before I build anything

By: Jordan Lord
Jordan Lord: 07/04/2026

Building radically simple, open tools and worlds through constraint-driven engineering.

These are the 3 constraints that I use before I start building anything. I'm a believer in constraints as an enabler for creativity. Constraints help us collapse the search space, and figure out innovative solutions to problems.

I've been a builder for 10 years, and I've built products that went nowhere because they were either too complex or had no identity. These are the constraints that I landed on after making those mistakes.

One page or it doesn't get built

This constraint limits complexity and ambiguity.

Write a one pager for all of your ideas. Your one pager captures your north star. It's non-negotiable, precise, ambitious, and lean. Once your one pager is written, it is applied to all different types of communication. Share it as a memo for investors, contributors, team members, friends, or family. Working collaboratively on a product, there will always be contention points and conflict, it can sometimes be difficult to know what battles to pick. If it's not in the one pager, then it's either not worth fighting over, or the one pager ought to be amended to include the thing. Not only is a one pager useful for communication, it's useful for organising your own thoughts. If you can't fill one page, don't fill the gaps with fluff, it means you're not ready to build. First research, plan, prototype, then write the one pager again. Iterate. If it requires more than one page, it's too complex, don't build it.

The core tech must be separable from the product

This constraint limits you to ideas that have real leverage and originality.

Develop a core piece of technology that supports your product and is not the product itself. The core tech is a method, skill, tool, or even product that supports what you're doing today but must survive without it. It's a type of reusable IP. Why? Separating the core tech forces you to think beyond the product that you're building. Products pivot in direction all the time, while your core tech is constant and compounding. Compounding efforts have non-linear gains over longer time horizons. Linus Torvalds developed git to improve the Linux kernel development workflow. HashiCorp has HCL (HashiCorp Configuration Language). Google has Kubernetes. But you don't need big tech resources to build core tech, it could be a library that you extract from your codebase, or even a methodology that you refine and commit to. Your core tech is your long term commitment. It is independent of your product's direction. However, it must be aligned with you or your company's long term vision. If your idea doesn't enable core tech, then it isn't high enough leverage.

One defining constraint must shape the product

This constraint limits feature creep and forces identity.

Define your own constraint that is front and centre to your product. That means the user sees and interacts with it all the time. It is obvious and it is what gives your product identity. A good constraint gives your product a feel, it permeates through all parts of the user experience. Minecraft is built entirely from blocks. IKEA is flat-pack, self-assembly furniture. The constraint that you choose limits scope by reducing your decision space, enabling you to concentrate on the problems that really make the difference. If you don't choose a constraint, or choose a bad constraint, you will build a bloated product that will try to do everything. The design of your product will "fall out" of a well-designed constraint. Like in your product, your constraint must be front and centre in your one pager.

Closing Rule

When it comes to deciding what to build, if it fails any of these constraints, then I don't build it.

By , No comments:

Everything to Gain from Thriving Southland

Mike's Notes

My notes from an all-day workshop organised for farmers, which I attended yesterday.

Resources

References

  • Reference

Repository

  • Home > Ajabbi Research > Library > Subscriptions > Thriving Southland
  • Home > Handbook > 

Last Updated

08/05/2026

Everything to Gain from Thriving Southland

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

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

I attended the all-day workshop "Everything to Gain" on 6 May 2026, held at the Ascot Park Hotel in Invercargill, New Zealand. Organised by Thriving Southland.

It was a day full of informative speakers on the global agricultural market, attended mainly by working farmers.



I learned a great deal from the objective data presented and from chatting with the farmers at our table. Hard times are ahead.

Thinking visually while listening

I mentally ran the Workspaces for Agriculture, testing the model assumptions against what I learned.

I also did a brain dump by creating 12 A4 drawings and solving the problem with variables in the current Pipi Core buildout.

Lessons I learned

Shifting a working Pipi 9 from a laptop to a data centre led to several unexpected consequences.

I underestimated the impact of

  • The naming, generation, and pub/sub of variables.
  • Host environment.
    • OS
    • Java
    • CFML Engine
  • Needing to turn Pipi into 4 separate role-based editions, which then exposed some hidden problems.
  • Adding a nest structure between Pipi and the host environment.
  • The impact of all of the above when each engine can pub/sub and be both deterministic and probabilistic, with multiple copies of each engine, and many in different locations.
  • Path length constraint in Windows vs Linux.

This very hard problem can only be solved by running a simulation of all 18 engines in parallel and watching the interaction. Lots of feedback loops.

Yesterday, a lot of progress was made visually, answering these questions. The variable-naming convention used for 12 months has held up, despite some earlier false flags.

  • More work is needed on variable distribution rules (messaging) for automation.
    • Global
    • Local
    • etc

Today I did another 8 drawings. They were of the Messaging Engine (msg) routing variables between the engines in both deterministic and probabilistic modes.


I will sleep on all this for a few days to see if anything else pops out, then commit it to code.

By , No comments:
Tags , , , , ,
Subscribe to: Posts (Atom)