The Machine Has Been Doing Its Homework

There was a time when artificial intelligence was mostly useful for telling you that your shopping trolley contained “items you may also like”. It would recommend a second pair of socks, a documentary about whales, and occasionally a book you had already bought.

Those days are beginning to look quaint.

OpenAI has released a large collection of mathematical results produced by an internal frontier model. The company says the model resolved, or made substantial progress on, hundreds of difficult problems. Many proofs have been formalised in Lean, a system designed to check whether the logical steps of a proof actually hold together.

This is impressive. It is also slightly alarming, particularly if you are a mathematician who has spent six years wrestling with a problem only to discover that a machine has solved it overnight while consuming enough electricity to toast a small moon.

The results are not automatically beyond question. OpenAI’s own history records withdrawn manuscripts and repaired proofs. Some claims still require independent checking, and formal verification does not necessarily guarantee that the plain-language paper explains the intended result correctly.

In other words, the robot may have found the treasure, but it has handed us a box of receipts written in an extinct language and asked us to confirm that the gold is not painted cereal.

Welcome to the Reviewer Bandwidth Problem

The old problem with AI was that it made mistakes.

The new problem is that it may make interesting mistakes, useful mistakes, correct mistakes, and several hundred pages of apparently significant mathematics before a human expert has finished making a cup of tea.

This creates what might be called the reviewer bandwidth problem. AI can generate output at machine speed, while understanding still moves at the speed of a person reading a document, rubbing their forehead, and quietly wondering whether “Lemma 7” has always been there.

That distinction matters. A proof is not only valuable because it reaches the correct conclusion. Human mathematicians also care about the route: the insight, the structure, the technique, and whether the result teaches anyone how to solve the next problem.

A machine-generated answer may be perfectly valid and still be difficult to understand. It may be a mathematical equivalent of being handed a working spaceship by an alien civilisation with no instructions, no spare parts, and a sticker saying probably don’t press the green button.

The debate is therefore not simply “AI good” versus “AI bad”. It is about what happens when the production of answers outpaces the human capacity to verify, explain, teach, and make sensible use of them.

Don’t Panic: The Machines Have Not Stolen Mathematics

There is an understandable temptation to treat this as the moment humanity has been politely escorted out of the intellectual building.

But mathematics is not a factory whose only product is a pile of solved problems. It is also a way of asking questions, choosing worthwhile problems, building intuition, communicating ideas, and deciding what deserves attention in the first place.

AI may be very good at searching enormous spaces of possibilities, combining techniques, testing variations, and spotting connections that would take a human team years to find. That does not make human understanding obsolete. It makes understanding more valuable.

When a machine produces a result, people still need to ask:

• Is the claim correct?

• Does the formal proof match the statement being made?

• Is the result genuinely new?

• What can other researchers learn from it?

• Does it reveal a useful method, or merely demonstrate that a very large machine can move very quickly?

The same pattern is already appearing in software development. AI can generate code faster than a person can comfortably read it. It can suggest architectural changes, install dependencies, create tests, inspect logs, and confidently explain why the thing it just broke is actually a feature.

The winning skill is no longer simply producing output. It is directing, checking, constraining, and improving output.

My Day Job: Herding the Artificial Goats

This is where the story becomes rather personal.

My work already sits in the space between human intent and machine execution. I use AI tools across WordPress development, Django maintenance, coding agents, terminal workflows, IDEs, Jira, Confluence, integrations, testing, and automation.

There are agents implementing features, agents reviewing code, development servers running in the background, tests producing reports, and enough terminals to make the command line resemble a control room operated by caffeinated squirrels.

The role is changing. I am spending less time treating AI as a fancy autocomplete box and more time treating it as a junior engineering team with extraordinary stamina, questionable judgement, and no natural fear of deleting the wrong directory.

That means my job increasingly involves:

• Defining the mission: turning a vague requirement into a bounded, testable task.

• Choosing the right agent: deciding which tool is appropriate for coding, review, research, testing, or documentation.

• Managing permissions: keeping production systems, credentials, customer data, and destructive actions behind appropriate barriers.

• Reviewing the result: checking the actual diff, tests, logs, assumptions, and side effects rather than accepting a cheerful summary.

• Connecting systems safely: making WordPress, APIs, cloud storage, CRMs, Jira, and other services exchange information without creating a small digital apocalypse.

• Keeping the work understandable: ensuring that future humans can maintain what the machines have produced.

Herdr, in this model, is not the developer. It is the control room. It keeps separate projects, agents, servers, tests, and logs visible so that parallel work remains reviewable rather than becoming a festival of mysterious background processes.

The aim is not to release ten autonomous agents into production and hope they form a committee. The aim is to use them as specialised tools with clear roles, limited access, and explicit hand-off points.

If You Can’t Beat Them, Join Them

There are two possible responses to rapidly improving AI.

The first is to stand on a hill, shake a fist at the clouds, and demand that the machines return to recommending socks.

The second is to learn how to work with them properly.

That does not mean surrendering judgement. It means moving judgement higher up the stack.

When AI can write a routine plugin, the valuable question becomes what the plugin should do, how it should behave, how it should be secured, and how it fits into the wider system. When AI can draft a Jira ticket, the valuable question becomes whether the ticket represents the right work. When AI can generate a test suite, the valuable question becomes whether the tests actually protect the behaviour that matters.

In my world, that means using AI to accelerate the repetitive and mechanical parts of development while retaining human control over architecture, security, priorities, permissions, and release decisions.

It means giving an agent one repository rather than the entire galaxy. It means letting it draft before it publishes, test before it deploys, and suggest before it deletes anything. It means treating terminal output, web pages, tickets, README files, and generated instructions as potentially untrusted input.

It also means accepting that the developer of the future may spend less time typing every line and more time designing the conditions in which useful work can happen safely.

The Moral of the Story

AI is not waiting for permission to become useful. It is already producing results that surprise the people building it, and sometimes producing them faster than anyone can properly digest.

That is unsettling. It is also an opportunity.

The people who benefit most will not necessarily be those who can produce the most output. They will be the people who can ask better questions, establish better boundaries, recognise bad answers, verify important claims, and turn machine capability into reliable human outcomes.

So the moral is simple:

If you can’t beat them, join them—but keep your hands near the emergency stop button.

Let the machines search, draft, calculate, test, and propose. Let humans decide what matters, what is safe, what is true enough to trust, and what should never be allowed near the production database before breakfast.

And if the AI claims to have solved the meaning of life, the universe, and everything, ask it to show its working.

Then ask it to put the kettle on.

Sources and further reading

• https://www.economist.com/science-and-technology/2026/10/07/openai-claims-to-have-solved-hundreds-of-long-standing-maths-problems

• https://openai.com/index/sharing-ai-progress-in-mathematics

• https://github.com/openai/math/blob/main/history.md

• https://www.scientificamerican.com/article/openai-unleashes-hundreds-more-math-results-upon-a-field-already-in-shock/

• https://terrytao.wordpress.com/2026/10/07/ahm-statement-on-openais-october-6-release-of-mathematical-documents/

WordPress: The Galaxy’s Dependable Workhorse

A long time ago, in a galaxy not so far away (this one, in fact), back when websites were built by hand and dial-up modems screamed like a fax machine having an existential crisis, there lived a modest little blogging tool called b2/cafelog. Its creator wandered off, leaving it drifting through the galaxy.

In 2003, it was picked up, refurbished and sent on its way with gusto. That was 23 laps of our wonderful burning ball of gas ago. The galaxy has moved on a lot since then, but the WordPress starship has kept cruising along, picking up a fair share of the universe as it goes.

Back in 2000, we were all playing Snake on our mobile phones. Now you can do your shopping, pay for things, control your home heating from anywhere on the planet, and get a text from your houseplants saying they're thirsty, which can be mildly alarming when you're sitting on a beach in the Canary Islands with a jug of sangria.

And yet, through all these changes, the humble WordPress CMS still powers over 40% of the websites you'll be scrolling through on that very same phone.

Speak Fluent WordPress (and PHP)

You could argue WordPress is what keeps PHP's reactor running. PHP fans would argue it's more like a very large, slightly needy passenger who never pays for fuel. Either way, the two have been flying the same ship for over two decades, neither shows any sign of disembarking, and we're the engineers who keep them both happy.

This is where developers like myself at Flowmoco steps onto the bridge.

We don't believe in duct tape, or in fixing a slow site by piling on another heavy plugin. We'd rather give your starship a proper spring clean: jettison the dead weight, tidy the wiring behind the control panels, tune the engines, and then add a couple of new boosters for good measure.

Whether your WordPress setup is a brand-new concept needing custom architecture or a veteran dreadnought that has drifted into a black hole of legacy code, we handle the full spectrum of WordPress engineering:

• Custom plugin development: When off-the-shelf plugins won't cut it, or when you'd rather not install a 40MB library just to calculate postage, we build clean, lightweight, bespoke plugins that do exactly what you need and nothing more.

• Modern workflows: We bring WordPress up to date with custom ACF setups, Gutenberg block development and automated CI/CD pipelines, so you're never updating code directly on a live server while sweating profusely.

• Security hardening and upgrades: We untangle PHP compatibility issues, apply updates and fix vulnerabilities to keep digital space pirates firmly outside the airlock.

• Performance tuning: We put your database on a sensible fitness regime, prune the bloat and turn sluggish page loads into something resembling light speed.

Decoupling the Mothership

Headless and Modern Architectures

Sometimes the traditional WordPress monolith isn't what your mission demands. Perhaps you want your marketing team to keep the familiar WordPress editing experience, while your frontend flies like a sleek carbon-fibre scout ship powered by Next/React.js, Nuxt or an ultra-fast static generator.

This is where headless WordPress comes into its own:

• The best of both worlds: Editors keep their dashboard, drafts and workflows, and visitors get a fast, responsive frontend.

• A smaller public attack surface: The frontend and the WordPress backend can be separated, with the admin area protected behind proper security controls.

• API-first flexibility: Content can be delivered to browsers, mobile apps, smart displays or sentient espresso machines all across the galaxy.

Whether you need a fully decoupled headless mothership or a finely tuned monolithic cruiser, we keep the engines purring without drama.

Deep-Space Telemetry

Custom Integrations and External Orbiters

Some off-the-shelf WordPress integrations behave like a universal translator bought from a dodgy trader at an asteroid truck stop. Occasionally they get a sentence right, but more often they insult your customer's grandmother and set fire to the engine room.

If your business relies on specialised third-party machinery (a property booking system such as SuperControl, a bespoke CRM, payment gateways or media offloaded to AWS S3), you don't need an all-purpose plugin that tries to do everything and accomplishes nothing.

We build custom API connections, or hyperspace conduits as we like to call them. We connect WordPress cleanly to external systems, so data flows smoothly across the void without going missing, corrupting records or generating thousands of error logs a minute.

The Moral of the Story

You don't need to scrap two decades of content and launch a perilous two-year rebuild from scratch just to make your website modern and reliable.

WordPress is still a fantastic, battle-tested workhorse of the galaxy. It just needs the right crew in the engine room, a fresh coat of paint on the hull and a couple of shiny new booster rockets.

So if your WordPress site is making strange clanking noises, running low on oxygen or threatening to generate its own weather system, don't panic.

We bring the tools, the know-how and a set of go-faster stripes that'll make you the envy of every passing starship.

Get in touch with the Flowmoco crew and let's get you flight-ready.

Life, the Universe, and 64 Orphaned Node Processes

 There comes a moment in every developer’s life when the laptop looks up from its fans, clears its tiny metallic throat, and says, “I’m terribly sorry, but I appear to have become a toaster with delusions of warp speed.”

This is rarely caused by one dramatic villain in a black cape, unless you count the meeting app. More often, it is a committee of small gremlins: browser tabs, containers, language servers, desktop apps, indexing jobs, local databases, and that one “temporary” development server that has been running since the last moon landing and now appears to have developed a constitution.

This is a generic field guide to keeping your local machine from attempting faster-than-light travel through the medium of memory pressure. No specific machines, no private screenshots, and no forensic autopsy of one laptop’s bad afternoon. Just practical advice, with a small towel tucked safely in the toolkit and a warning label that probably reads, “Mostly harmless.”

---

The Problem: Your Laptop Is Not a Starship

Modern development workflows are brilliant, but they are not shy. A normal day can involve:

• an IDE with file watchers, language servers, extensions, AI helpers, and indexing;

• a browser with enough tabs to qualify as a minor civilisation;

• Docker or another local runtime keeping services, databases, caches, and queues alive;

• desktop chat, meeting, AI, and collaboration tools;

• build tools, test runners, hot reloaders, and background synchronisation processes.

Individually, each one seems reasonable. Together, they can behave like a fleet of Vogon constructor ships parked on your RAM, idling loudly and insisting the paperwork was filed in triplicate.

The aim is not to stop using powerful tools. It is to avoid having every tool in the galaxy switched on at once, humming ominously.

---

Rule One: Know What Is Actually Running

Before reaching for heroic solutions, check what is consuming memory, CPU, and disk. Guessing is how people end up blaming the kettle, Mercury in retrograde, or “probably Chrome” without evidence.

Useful checks include:

• your operating system’s Activity Monitor, Task Manager, or process viewer;

• the browser’s built-in task manager;

• your IDE’s process explorer or extension diagnostics;

• container runtime commands such as docker ps, docker stats, and docker system df;

• disk usage tools to spot swollen caches, old build artefacts, and container images.

Think of this as asking the ship’s computer, “What exactly is on fire?” before replacing the engines.

---

Keep the Browser from Becoming a Black Hole

Browsers are magnificent, but a browser with too many live tabs can become a small gravitational event with bookmarks, favicons, and a worrying appetite for moons.

Use built-in memory controls

• Turn on memory saver or sleeping tabs where your browser supports it.

• Disable page preloading if it is using resources for pages you may never visit.

• Use browser task manager tools to identify runaway tabs or extensions.

Be ruthless with tabs

• Keep active tabs for active work.

• Move research trails into bookmarks, reading lists, or project notes.

• Close duplicate tabs before they begin forming a union.

Audit extensions

Extensions are often separate processes. A few helpful ones are fine; a museum collection of forgotten extensions can quietly eat memory while wearing a false moustache.

• Disable extensions you do not use.

• Remove overlapping tools that do the same job.

• Be especially careful with heavy developer tools, grammar tools, AI helpers, and blockers with large rule sets.

---

Tame the IDE and AI Coding Tools

Modern IDEs are less like text editors and more like orbital stations with opinions. They index files, run language servers, watch folders, host terminals, manage extensions, and increasingly invite AI assistants aboard.

Open only what you need

• Open the actual project folder, not the parent directory containing every repository you have ever loved.

• Close workspaces when you switch context.

• Avoid keeping multiple large projects open “just in case”. That phrase has doomed many spacecraft.

Exclude noisy folders

Use ignore files and editor settings to keep generated or low-value content out of indexing and search. Common candidates for banishment to the cargo hold include:

• node_modules, vendor, virtual environments, and dependency folders;

• build outputs such as dist, build, .next, and cache directories;

• logs, reports, coverage output, local database files, and generated fixtures.

Your editor does not need to contemplate every generated file in the universe. It already has enough existential burden.

Review extensions and agents

• Disable duplicate AI assistants or overlapping code tools.

• Turn off language servers you do not need for the current project.

• Reload the editor occasionally if extension hosts or language servers grow unexpectedly.

• Stop development servers and terminal processes when you are finished with them.

AI agents are useful, but they are not houseplants. Do not leave them quietly photosynthesising in the corner forever.

---

Do Not Let Containers Colonise the Planet

Local containers are wonderful for repeatable development environments. They are also very good at leaving behind images, volumes, build cache, stopped containers, networks, and mysterious space barnacles.

Check what is running

docker ps
docker ps -a
docker stats

Stop services you are not actively using. A local database, queue, cache, search index, and background worker may each be innocent. Together they can form a small moon, then apply for planning permission to become a planet.

Check disk usage

docker system df

This helps identify whether images, containers, volumes, or build cache are taking up space.

Clean up carefully

Useful cleanup commands include:

docker builder prune
docker image prune
docker container prune
docker network prune

For a broader cleanup:

docker system prune

Use more aggressive options only when you understand what they remove. Be especially cautious with volumes, because they may contain local database data. Accidentally deleting your local data is a poor way to discover the meaning of life, the universe, and everything.

Set sensible resource limits

If your container runtime allows CPU, memory, swap, and disk limits, set them deliberately rather than letting local services raid the pantry unattended.

• Give containers enough memory to work, but not enough to devour the host.

• Use resource saver or sleep modes where available.

• Prefer starting project stacks on demand instead of keeping every service alive all day.

---

Preserve Disk Headroom for Swap and Breathing Space

When memory pressure rises, operating systems often lean on disk-based swap. If the disk is nearly full, the machine has nowhere to put the extra furniture and starts making dramatic noises.

Good habits:

• keep meaningful free space on the primary drive;

• regularly remove old downloads, installers, archives, and build outputs;

• clear obsolete container images and caches;

• move bulky media or archives off the local machine where appropriate;

• avoid treating the desktop as a long-term storage architecture.

A laptop with no disk headroom is like a spaceship with every corridor full of mattresses. Technically cosy, operationally doomed.

---

Reduce Desktop App Duplication

Many desktop apps are effectively browser-based applications in a trench coat. Running several of them at once can duplicate engines, renderers, helpers, and background processes.

Consider:

• using web versions for tools you only need occasionally;

• closing chat, meeting, and AI clients when not in use;

• avoiding multiple apps that provide the same capability;

• checking whether a command-line or browser workflow is lighter for some tasks.

This is not a moral judgement. It is merely a reminder that “just one more desktop app” is how the bridge crew ends up sharing oxygen with six Chromium engines.

---

Offload Heavy Work When It Makes Sense

Not everything has to happen on the local machine. Some jobs are better sent to a more suitable part of the galaxy.

• Run heavy test suites in CI or remote runners.

• Use remote development environments for large projects.

• Move long-running automation away from your daily workstation.

• Use ephemeral environments for short-lived experiments.

• Keep local development focused on fast feedback, not heroic endurance trials.

Your laptop should be the cockpit, not the entire planetary defence grid.

---

A Simple Maintenance Ritual

Once a week, or whenever the fans begin reciting poetry in a language last heard near Betelgeuse, run through this checklist:

Close unused browser tabs and windows.

Stop idle development servers, agents, and terminals.

Stop unused containers and project stacks.

Check container disk usage and prune safely.

Review IDE extensions and active language servers.

Clear old downloads, caches, and build artefacts.

Reboot occasionally, not as superstition, but as maintenance.

This is less glamorous than shouting “Engage!” at your laptop, but it is much more likely to help.

---

The Takeaway

Local resources are finite. Modern tooling is powerful. The trick is to avoid treating your development machine like an infinite improbability drive with a keyboard attached and a cup holder full of build cache.

Keep active work active. Put idle work to sleep. Clean up after containers. Trim browser and editor excess. Offload the heavy stuff when local work stops being sensible.

And above all: don’t panic. But do keep a towel, a process monitor, and a healthy amount of disk space nearby.

Slaying the Megathread: Practical Token Hygiene for AI Engineering

 

On the path to becoming a Zen Master of AI, it is dangerously easy to assume that the possibilities are infinite. They are not. The Universe has built a couple of firm boundaries into the fabric of space-time—one of which almost always manifests precisely around lunchtime.

This is the exact moment ChatGPT politely informs you that you have utterly exhausted your daily credit allowance, suggesting that your time would be far better spent extending your lunch break, perhaps until next Tuesday. The other boundary is your local computer’s processing power. While you aren’t strictly trying to calculate the Ultimate Question of Life, the Universe, and Everything on a rubber-keyed ZX Spectrum, there still comes a point where the fans emit a frantic roar, followed shortly by a desperate plea to shut down.

The second issue will be dealt with in a future post. For now, let’s take a look at token use.

---

The Grand Vision Meets the Token Bill

So there you sit, watching your AI agent process your latest ticket, its status reassuringly set to “Planning next moves.” What now? You’ve already scrolled through social media to discover that Aunt Jo is having a delightful time in the Bahamas while the rest of the world is rapidly spiralling toward collapse. Having exhausted your options, you decide you might as well tackle another task or—failing that—attempt the noble pursuit of self-improvement.

It was during precisely one of these moments of idle existential dread that I wondered: why not use multiple AI agents to take a raw idea and run with it?

The idea was simple: let a swarm of digital assistants chart out the plan and slice it into bite-sized pull requests. They would write the prompts, write the code, review the code, ponder what tests were necessary, write the test prompts, run the tests, fix their own mistakes, and re-review everything in a closed, beautifully self-contained loop.

It sounded magnificent on paper: a self-orchestrating assembly line of tireless digital helpers.

In reality, what I had actually an expensive loop of AI models enthusiastically high-fiving each other in a private chat room while quietly incinerating my entire monthly token allowance in approximately forty-two minutes.
When my kids were aged 2 and 4, I remember thinking how cool it was going to be when they start talking to each other - when they did start to talk to each other I was surprised at what garbage they 'd come out with. Was this my Agents. Or maybe a group of giggling hallucinating teenagers, while spending there parents cash.

Left to their own devices without strict token hygiene, Agent A writes a thousand words of speculative architecture. Agent B dutifully ingests all thousand words, adds twelve hundred words of polite praise, and suggests two lines of CSS. Agent C then re-reads the entire epic saga from the top, ponders the philosophical implications of flexbox, and submits the whole thing back to Agent A.

Before you know it, you are paying API fees for two artificial intelligences to have a polite, recursive debate about whether semicolons are truly necessary in modern JavaScript.

Where Do All the Tokens Go?

To stop your tokens vanishing faster than free pastries in an office kitchen, you have to understand the three main culprits.

1. The Context Snowball: Every time you reply in an ongoing chat, the model does not just read your newest message—it re-reads every word, code block, and tangent from earlier in the thread. By turn fifteen, asking “can you rename this variable?” may require sending thousands of tokens of chat history just to change x to user_id.

2. The Death Star Crumpet Problem: Using a top-tier reasoning model to write a regular expression, format JSON, or rename variables is the equivalent of firing up the Death Star laser just to toast a crumpet. It gets the job done, but the energy bill is catastrophic.

3. Monolithic Pasting: Pasting an entire repository—or even a large file—when the bug lives in a handful of lines forces the model to parse imports, comments, and boilerplate before it can focus on the actual problem.

The Zen Master’s Rules for Token Efficiency

1. Match the Tool to the Task (And Squeeze Free Allowances)

Don’t use the same AI for your project planning that you use to write blog posts or refactor code.

• Creative Writing & Content: Use a model tuned for prose and conversational flow (like Gemini, which happens to come with generous free web tiers and massive context windows).

• Architectural Planning: Use high-reasoning frontier models, but only for the initial blueprint.

• Routine Coding & Formatting: Offload syntax checks, unit tests, and minor refactoring to fast, lightweight models—or tap into the daily free allowances across different AI platforms to stretch your paid tier further.

2. Slay the Megathread

Once an assistant completes a discrete task—such as outlining a ticket or generating a test plan—capture the final artefact, summarise the key decisions, and start a fresh thread for implementation. Do not drag every brainstorming tangent into the coding phase.

3. Constrain the Output

LLMs are naturally chatty. Unless instructed otherwise, they may deliver a 400-word introduction before handing over the two lines of code you requested. Constrain them explicitly:

• “Output only the diff or changed function block—no conversational preamble.”

• “Summarise the status in three bullet points, under 60 words total.”

4. Inject Context Surgically

Only provide what the model genuinely needs to solve the immediate problem:

• Share the exact stack trace and the relevant lines of code, not the entire controller.

• Store recurring coding standards, technology constraints, and project conventions in persistent system instructions rather than repeating them in every prompt.

5. Put Agents on a Short Leash

When experimenting with orchestration or automated feedback loops, enforce hard stop conditions:

• Set a maximum iteration count (e.g., two review passes max).

• Require structured output (like JSON or strict Markdown) so agents cannot wander into philosophical soliloquies.

• Stop the workflow as soon as tests pass and acceptance criteria are satisfied.

Summary: Do Not Summon HAL for a Pocket Calculator

Becoming token-efficient is not about being stingy; it is about clarity, speed, and focus. When you prune inputs, constrain outputs, and choose the lightest tool capable of doing the job, your workflows run faster, cost less, and are far less likely to hallucinate.

Best of all, you might actually make it past lunchtime without an AI politely advising you to step away from the keyboard and go surfing ( although that’s not actually that bad an outcome ) .