DEV Community: Graham Trott

AI writes the code, humans review it — review is the coming skill

Graham Trott — Sun, 09 Aug 2026 14:31:08 +0000

Many articles on dev.to are about coding, but we are rapidly entering a world where this job is done largely by AI and where humans review the code produced. This has consequences for which skills matter, so I want to focus here on the relatively neglected but increasingly vital skill of code review, and later describe a working example — Doclets — a small tool you can run, read and adapt.

This is a personal view, and it is meant to be argued with.

Recognition is easier than writing

As time goes by, you are ever more unlikely to be asked to write code — that job is fast becoming one performed almost exclusively by AI. Your job will be first to prompt the AI, and then to review the code presented in the language chosen for the project. Review relies not on writing but on reading and recognition, and it becomes increasingly effective the closer the language comes to a human language. Most coding tools still focus on writing code, assuming human programmers will continue to do it. Tools that put readability first are the exception — and AllSpeak is a deliberate one.

AllSpeak is a coding tool closely resembling natural human languages. It can do most of the things normally done by Python or JavaScript, but its focus is on keeping code readable by humans. Most things can be described clearly using natural language, so it makes sense for AI to be asked to code using constrained, unambiguous dialects of the languages used by the humans in charge.

Assertion
If a thing can be described in English, it should, if at all possible, be coded in something resembling English. If it's too complex to describe in English, the likelihood is it's simply too complex. Period.

AI has no trouble writing AllSpeak code; in our experience it even makes fewer mistakes than when using mainstream languages. This is partly owing to the constrained syntax of AllSpeak and partly to the comprehensive guidance provided to AI when using it.

Like natural language, AllSpeak relies on an extensive vocabulary instead of complex syntax. When you read a book on an unfamiliar subject or even in a foreign language, the structure of the text seldom causes you any difficulty; it's usually the words themselves. You consult a dictionary for the terms you don't know. When reviewing AllSpeak code, the dictionary is an AI agent: an unfamiliar word or construct in the code is just a question away. "What does this word mean?" or "What is this block doing?" — and the agent explains it in plain language. Recognition, assisted by the dictionary, is enough to review what was written. When complexity is handled by words in the language rather than by syntax, this process becomes far easier. Most of us find complex syntax hard to follow, whereas we can absorb a huge range of vocabulary with little effort.

Why programmers resist

Many programmers find the foregoing argument hard to accept — so used are they to regarding code as something they own. "Reading the code" has always been unpopular, and mostly for good reason. Every cycle, someone promises readable code and fails to deliver — so the scepticism is earned. The difference this time is that the code is no longer written by hand at all. When using AllSpeak, AI is under strict instruction to provide clear and comprehensive documentation for each block of code, for the benefit both of itself and of the humans who will review the code. If this stipulation is enforced, then regardless of what coding language is used, at last we can rely on documentation that's both accurate and complete. But even the best documentation will not save the reader from having to know the language itself — and the expertise that mainstream languages demand is precisely what will be increasingly hard to gain. A language that reads like one you already speak removes that barrier.

I have recently begun to avoid the word "programmer" when referring to those creating software, because in this scenario the term stops being useful. The people who remain are engineers — and the skills they need are very different from traditional ones. When we delegate to AI the job of creating and managing complex structures, we are free to step back and view the big picture or to zoom in to examine specific details. This is the essence of review, and natural language adds to this by opening the door of opportunity to those previously denied access.

Review is the coming skill

It is widely accepted that there are fewer and fewer opportunities to gain coding expertise. Review is the coming skill — and if toolchains remain as they are now, few will possess it effectively unless the language of code moves closer to human language.

The only alternative to accepting — and embracing — more accessible forms of language is to abdicate software generation to machines entirely. That is not a future most of us would choose willingly — and it is the default if we do nothing.

AllSpeak is a first step, not a destination

AllSpeak is not a final destination; it is a first step towards a new paradigm, one that must gradually become familiar to engineers. The closer the language comes to a human language, the more effective recognition becomes, and the less foreign the code feels.

A working example: Doclets

The Doclets project is a working example of the pattern. Neither hand-coded nor vibe-coded, it was produced through exactly the process described above — a succession of deliberately small steps in which AI writes and humans review, block by block. It is an example of a pattern — one of the few patterns that explicitly acknowledges the gap between coding and review and points the way to bridging it.

Doclets started as a solution to a real-world problem, that of how to organise information, either for an individual or for a small team. Information is typically strewn over a wide range of documentation tools, social media, email, web pages and more.

The chosen solution was to create a central, searchable repository of Markdown documents ("doclets"), organised into topics, to be read and edited in a browser on any device. A small server process owns the documents and talks to the browser over MQTT.

Plain search is a substring match over every doclet's title and content:

Clicking a result line opens the doclet in prettified (HTML) format, with an option to switch to Markdown for editing.

A second way to search uses a local language model: tick "LLM query" and ask questions like "list the main topics covered by the doclets in the AllSpeak topic" — a short prose answer comes back, derived from the collection itself, running entirely on your own machine.

For small teams, each topic has an owner and a visibility setting: public topics are readable by anyone, private topics only by the owner and named readers, with separate grants for creating, modifying and deleting, and a simple activity log of who did what and when.

Why it is easy to customise

The construction is deliberately simple — and that is the point. One language for the whole stack (the browser client and the server are both AllSpeak), screens defined declaratively, MQTT for request/reply, and the one heavy component (searching, securing, and the LLM integration) consigned to a Python plugin that adds a small vocabulary of its own to the language.

Customising Doclets — a new field, a different screen, a renamed command — is often a matter of recognising and adjusting existing code, not writing new code from scratch. That is the review skill this article argues for, applied to a tool you can run today.

This is a general picture, not a specification — the details live in the repository.

Ask your agent

Doclets is deliberately and unashamedly an AI project. If you want the detail, point your AI agent at the Doclets repository and ask for a synopsis, a full technical breakdown, or anything in between. Every section of the code carries a doc block explaining why it exists, so the agent — and you — can read it block by block. Recognition, with the dictionary always at hand.

The code is not the point; what the code does is the point. If AI writes the code and we review it well, software production becomes a skill of judgment rather than of syntax. That is a change worth embracing.

Photo by Cookie the Pom on Unsplash

How to enjoy programming in a world of AI

Graham Trott — Sun, 14 Jun 2026 09:38:53 +0000

It's widely accepted that as AI writes more and more of our code, opportunities decrease for newcomers to gain the skills needed to become professional programmers. At the same time, experienced people bemoan the way AI is causing them to gradually lose the skills they took so long and worked so hard to gain.

Programming, like mathematics and perhaps music, sits in the middle between science and art. As science, it's all about capturing and organising knowledge, and as art, it's the application of creativity to problem-solving. Enjoyment - deep satisfaction or an emotional rush - can be had from either or both of these. But the perception is that AI is depriving us of opportunity, both to learn and to be creative.

Code written by a human reveals a lot about the coder. Their depth of knowledge of the coding language, their creative use of variable and function names, and even the visual layout of a script. You can often tell at a glance whether the writer truly cared about the code they wrote, or whether it was just a means to an end, to ensure their next pay packet arrives on time.

As AI improves, it makes fewer mistakes, but it also produces code that is increasingly hard for any human to read and truly understand. Since the job of a human in the coding loop is increasingly not to write but to validate code, this is becoming a problem. So here's my recent story, a series of happy accidents.

I've been using agentic AI for about a year. First with Copilot in VS Code, then more recently with Claude Code at the command line. At the start, I found Copilot to make a lot of mistakes and to produce rather repetitive, poorly-structured code, but looking back, a lot of that was probably down to my own ignorance of how to control the process.

The biggest problem I had was in validating JS or Python code. There was just so much of it, often using features of both languages I never fully got to grips with. I've never been a first-class programmer and most of my own code is pure vanilla. The project I was working on was AllSpeak, based on an English-like scripting language I'd written years earlier to help me create products without having to be a coding expert. AI gave me the chance to bring it up to date. But it was when Copilot started offering me AllScript fragments - uninvited - that I had a complete rethink.

The assumption usually made is that code must be written in a modern, high-level language like JS or Python. This is quite valid when a human is doing the coding, but it falls down badly for AI. The problem is, these languages are too complex, and they suffer from inconsistencies AI finds difficult to spot. Documentation is often out of date, and new versions of the language can break older code. Additionally, many features of these language are there as guardrails to stop humans making coding errors that gobble up memory or lie in wait to misbehave in the future. Since AI doesn't make the same mistakes as humans it doesn't need these guardrails; in fact it makes AI's job harder, not easier.

An obvious path revealed itself. If the agent was trying to write code in AllSpeak, why not let it finish the job? I built an AGENT.md file that instructed the agent to code in my language wherever possible, and gave links to the repo and to documentation that would help it do this without making errors.

The benefit was immediate. Instead of having to wade through huge piles of JS and Python, I could now see the application being built in something much closer to English. But it went much further than this. Every now and then, the agent would guess at a construct that wasn't valid, using its knowledge of other coding languages. This was usually down to limitations in the available documentation, but I figured that if the agent wanted to use such a construct, as long as it was syntactically valid and consistent with the rest of the language, it should probably be added. So I set up a permanent second session that deals with additions and changes to AllSpeak, and a rule that if the agent can suggest an improvement, it should do so.

Because AllSpeak is growing in this way, it might be regarded as an impediment to coding, given that it was designed in the first place to make coding simpler. But this changes when AI is doing the coding. The human's job becomes not to write code but to read it, and because the language is close to English, the meanings of new syntax can be made fairly obvious. I can pile in a load of new syntax that reduces repetitive boilerplate to a few words. I no longer have to remember all the syntax, merely to recognise it. This is a big difference.

The final part of this story so far (there may be more to come) was that I'm just an individual with a limited budget. Claude Code does a superb job, but it can get expensive. The pricing is non-linear; spending more gives you exponentially more tokens, but I was ending up not using my allowance. Reducing the cost meant I overran and had to top up.

Then I saw a mention that DeepSeek costs about 50 times less (yes, that's 2%) than Claude Code, so I had to try it. And it's true; after a couple of weeks of daily but not intensive work it's cost me $0.46. However, it's not as good at coding as Claude. It's quick, but it makes more errors, and from the verbose output it emits while working, it seems to struggle from time to time. How much of this is down to my still less-than-perfect documentation is hard to tell, but I definitely have to intervene more often. I understand that deepseek-v4-flash is optimised more for managing huge datasets than it is for coding, which could well be the explanation.

But this limitation brings an unexpected benefit. When working with Claude Code, I often felt myself to be merely a bit player. I gave the requests, but then had little part to play in how things were done as mistakes were few and far between. With DeepSeek I feel more like an equal. We have different roles; DS does the coding and I review it. And because it's written in something close to English, I can follow it far more easily than I would have, had it been JS or Python. I can spot things that aren't right and suggest improvements. I've started to feel like a programmer again, that I really have a role to play in the coding process. And that's where the enjoyment has returned.

So what started as a series of serendipitous accidents followed by a cost-saving trial has turned out to be a partnership of equals, restoring my enjoyment of the coding process. One conclusion I draw from this is that maybe instead of always assuming the latest model is better, consider whether it leaves you with a real part to play in that process, or whether you'll get more enjoyment out of taking on the role of teacher and helping a lesser model do its job, while saving money at the same time. Don't forget, happy people produce better results.

When AI writes the code, what should humans actually read?

Graham Trott — Mon, 11 May 2026 10:04:16 +0000

There is an open secret in the world of vibe coding. The people commissioning the work — the ones with the product idea, the domain expertise, the actual customer in mind — usually cannot read the output. They prompt, the model produces, and the result is a tower of TypeScript or Python they accept on faith because they have no way to verify it. The validation step gets quietly skipped. "It runs" becomes "it's correct."

This is not a moral failing. It's a tooling problem. And I think the way out of it is hiding in plain sight.

The problem with normal code in an AI-first workflow

If your premise is that AI is going to do most of the routine writing of code, then the human's job shifts. We move from authors to reviewers. From "did I express this correctly?" to "did the machine express what I meant?"

Reviewing is a different job from writing, and it has different tooling needs. When you're writing, you want a fast feedback loop — autocomplete, jump-to-definition, a fast test runner. When you're reviewing, you want comprehension support — context next to the code, an explanation of why this section exists, and confidence that what you're reading is actually what's running.

Most editors are still optimised for the writer. The reviewer has to piece things together: read the code, hunt for a docstring above it, hope the docstring still matches, then mentally verify against intent. For an experienced developer writing their own code, this can be fast. For a vibe coder reviewing AI output, it's almost impossible.

Two things to fix

I've been working on the editor side of this for AllSpeak, a multilingual scripting language. AllSpeak allows the same programs to be written in French, German, Italian, or any other language we add. The combination of natural-language source with a review-first editor is starting to look like a real answer to the validation gap.

The first screenshot below shows the editor in normal ("raw") mode, showing a documentation block followed by some code. Because of the color-coding, the eye skips over the documentation quite easily; it's not meant to be read here.

The second screenshot shows the editor in Blocks mode, displaying the same piece of code but with its documentation in the right-hand pane, making code review far simpler. On the left is a list of all the blocks, for navigation, or you can use the up and down arrows in the toolbar. This is just a starting point; the editor could have a long way to go.

Maintaining such a structure would be a daunting task without the help of AI. This is an almost free gift we should take full advantage of.

There are two specific changes I'm making.

First, sections of code get a documentation block above them, in a structured comment format. Nothing radical there — literate programming has done variations on this for decades. The new bit is that each block contains two SHA hashes: one for the documentation, one for the code section it describes. If either changes without the other being deliberately re-paired, the editor flags drift.

This is cheap, mechanical, and solves a problem that has plagued every codebase I've ever worked on. Documentation rots silently. Cryptographic pairing makes the rot clearly audible.

Second, the editor gains a side-by-side mode that shows one section at a time, code on one side, its documentation on the other. The reviewer sees a small, focused unit and can ask the only question that matters: does the code do what the prose says it does?

That's a comparison task, not a comprehension task. Comparison is much easier than comprehension for non-experts — and that's the entire point.

Of course, all of this only becomes possible when AI is doing the coding, as is increasingly the case. Human coders, however professional, don't like to maintain comprehensive documentation for their code. Documentation gets in the way of coding and is usually regarded as an imposition, so the bare minimum is all that gets written. An agent, on the other hand, has endless patience and is more than willing to take on such a task.

Why this matters more for AllSpeak than for Python

Here's where the language choice does real work. If the code is dense Python with framework conventions a non-developer can't parse, asking "does the code match the prose?" is still a comprehension task in disguise. The reviewer has to understand the code first, then compare. The validation gap stays roughly where it was.

If the code is AllSpeak — close enough to English that a careful reader can follow it line by line — the gap narrows considerably. The reviewer reads two pieces of natural-ish text and checks whether they agree. They don't need to know what a decorator is, or how async resolves, or which way the data flows through a hook. They just need to read.

That's the leverage point. AllSpeak by itself simplifies syntax; the review tooling by itself simplifies workflow; together they change who can credibly validate generated code.

Files become packages, not text

A side effect of all this: a source file is no longer just a sequence of statements. It's a structured package containing code sections, documentation sections, and the cryptographic links between them. The raw form might look a bit ugly opened in vim — comment blocks dominate — but it's not really meant to be read raw any more than a minified JavaScript bundle is.

I want to be careful with this claim, though. There's a temptation to push it further than it deserves. "Humans don't need to read raw code any more" is not quite right. Sometimes the editor is unavailable. Sometimes you're debugging at 2am with grep and a terminal. Sometimes a future tool needs to interoperate with your files and the only sane interface is plain text. The defensible version of the claim is softer: humans should rarely need to read the raw form, but the format should remain legible in extremis. AllSpeak's plain-English nature preserves that floor even with the scaffolding around it.

What I'd encourage other tool-makers to think about

If the future of coding is mostly machine-written, the tooling we should be investing in is the tooling that helps humans check what the machines produced. That's underbuilt right now. The current generation of AI coding tools — the Lovables and v0s and Bolts of the world — focus almost entirely on generation. They produce React, Next.js, the standard opaque stack, and they assume the user will accept whatever comes out. For users who can't read the output, that assumption is shaky at best.

A few things I think are worth borrowing or stealing from what I'm building:

Treat documentation as a first-class artefact paired with code, not a comment that floats nearby
Use cryptographic pairing or some equivalent to make drift visible
Build review modes that show one unit at a time with context attached
Pick a source language whose readability matches the average reviewer's skill level

The last one is the hardest sell to the developer audience because it sounds like a step backwards. But if you accept the premise that AI is going to write most of the code and humans are going to review most of it, then optimising the source language for human reading — even at some cost to expressive density — starts to look like exactly the right trade.

A small invitation

I'm writing this as the AllSpeak editor work progresses. If you're building tools in this space, or if you're a vibe coder who's quietly worried about whether you can really vouch for what you're shipping, I'd be very interested in hearing from you.

The future where AI writes everything and humans rubber-stamp it is the bad version. The future where AI writes everything and humans actually read and approve it is the one worth building toward. The difference is mostly about tooling.

Postscript

The editor described here is written in the JS implementation of AllSpeak to run in a browser. It is served from http://localhost:8080 by a smaller AllSpeak module written in the Python implementation, which has access to all files and system resources.

At the time of writing, the editor (asedit.as) comprises 944 lines of AllSpeak code, 173 lines of comment and 44 blank lines. The block view addition was added in one day by Claude Code, using continuous prompt/review.

This document was proposed and argued by me, written by Claude and edited by me. I take full responsibility for the content.

Photo by Volodymyr Dobrovolskyy on Unsplash

Claude built me a high-level coding system in 4 European languages

Graham Trott — Wed, 29 Apr 2026 16:29:51 +0000

Years ago I wrote myself a high-level scripting language, mainly because I'm not a great programmer and I wanted something easier to handle all the jobs waiting to be done. It was pretty successful, in that the jobs got completed and they're easy to dive into years later to fix problems.

When I discovered agentic AI about a year ago I aimed it at one of those projects, to help me write a language extension needed for a new feature. To my surprise, after a while the AI started offering me code in my own scripting language, not just in the Python it was built with. The code was pretty awful but it gradually got better.

I moved the project over to Claude Code a couple of months ago, and with careful prompting Claude was soon able to do virtually all my coding for me in script rather than Python or JS. This made code verification simpler because English-like scripts are much easier to read than the traditional high-level language code needed to carry the same meaning.

Occasionally we come across something the script doesn't handle well, so we go back to Python/JS to extend or revise the compiler and runtime. For more complex, self-contained chunks of functionality we build plugins, also in Python or JS, that seamlessly extend the language and can be imported when needed rather than having to be present all the time. We drew in various bits and pieces from the original project, such as a reference manual, a tutorial and a programmers' playground, and built a website to describe what we were doing.

Bonjour / Guten Tag / Buongiorno

At some point I had the crazy idea of internationalizing the scripting language. All mainstream programming languages are based on English words, which gives native English speakers a distinct - and to my mind somewhat unfair - advantage. I consulted Claude, who explained that it wasn't necessary to rewrite the whole thing, just put a language pack - mostly just a large JSON script - in front of the compiler, to deal with different vocabulary, syntax, word order and so on. The 'intents' remain the same; addition is still addition and a subroutine call is still a subroutine call. The system comprises a single compiler and runtime, plus a set of language packs.

I picked Italian, the language I know best other than English, and told Claude to get on with it. This went way better than expected, so I added French and German and named the project AllSpeak*. For all three languages, the translations are a bit clunky in places and could do with being proofread by native speakers (any volunteers?), but there's little doubt the meaning is clear. At worst they come over a bit like Yoda, with mangled syntax and odd word order.

Take a very simple example:

  variable Greeting
  put `Hello, AllSpeak!` into Greeting
  log Greeting

in French is

  language fr

  variable Salutation
  mets `Bonjour, AllSpeak !` dans Salutation
  journalise Salutation

in German is

  language de

  variable Gruss
  lege `Hallo, AllSpeak!` in Gruss
  logge Gruss

in Italian is

  language it

  variabile Saluto
  metti `Ciao, AllSpeak!` in Saluto
  registra Saluto

So what use is a set of multilingual scripting languages? Well, with the right primer packs to describe the vocabulary and syntax, Claude Code and other agents can use them in place of mainstream computer languages to handle a wide range of software applications, including where those doing the prompting are not native English speakers. With AI doing all the coding, the choice of programming language is not important; the main thing is readability by those charged with validating the code. Unlike mainstream programming languages like Python or JS, the code produced by AllSpeak can be read and understood not just by professional coders but also by some of the people who will be using the finished software. And with the help of the language packs, the AI agent generates code in the same language as the prompts it was given; code that compiles and runs exactly the same way as the English version because it uses the same compiler and runtime.

But in the end, I don't know. This was mostly an intellectual exercise; an exploration of what's possible. I have a feeling it's an indication of one direction that coding could be heading, but only time will tell.

Anyone curious enough to try it out is welcome to visit the AllSpeak website.

Photo by Drew Beamer on Unsplash

*"Allspeak is the divine language of the Norse gods - anything that can communicate can understand it, and be understood in turn."

AI has reprogrammed me

Graham Trott — Fri, 24 Apr 2026 07:52:22 +0000

It's quite scary how reluctant I feel to dive into JS or Python coding since I started watching Claude Code do it. I'm happy enough to guide the process and examine changes made to the code, but actually spending hours writing the stuff - meh. All this in a couple of short months. Years of practice are as nothing. I've been reprogrammed.

I wonder how many others feel the same way once they too have been utterly outclassed by AI. Some still carry on wanting to do it but I suspect they're in a minority that's shrinking daily.

It's a bit like crafts such as woodworking or embroidery. Some do them as a hobby, for fun or for relaxation, but as soon as productivity becomes an issue there's no way you're ever going to compete. Better to develop the ability to guide the process, spot errors and help fix them. Your experience is not lost - it transforms into new skills.

For example, one of the new must-have skills is the ability to speed-read. There's no way you can follow Claude's thinking without it, as it's almost impossible to study each sentence as the screen scrolls past. You need to use pattern-recognition that works on large blocks of moving text. Some are better than others at this but we're all able to do it - we just need to practice.

The fact is, few of us are the coding gods we long believed ourselves to be. Programming is something that has always made us stand out from the crowd. If we're going to maintain that distinction we have to adapt. Fast.

A good friend of mine is a proofreader by profession. He can spot swapped letters or a misplaced apostrophe in a full page of text at a glance. Musicians can hear a duff note from a single instrument in an orchestra. Likewise, most good programmers can home in on poor code instinctively and without even thinking about it. Our coding skills need not be wasted but they do need to adapt to a rapidly changing world.

One thing we must do is resist the temptation to take AI engines on trust. Be picky; make them work hard to please you, whether it's style factors like your preference for open text with lots of whitespace, or choice of variable names, or replacing deep indenting with functions... make them do it. Keep nagging them till it's just right for you. That way at least you'll preserve your self-respect. For you are superior; you may not be able to churn out code at factory speed but you sure as hell can tell when it ain't right.

AI is here to stay. Don't be intimidated and don't pretend you can carry on without it. Embrace it and prove that things go better when you are at the helm. Accept the inevitable reprogramming of yourself and take control of it.

AI Doesn't Need Your Programming Language

Graham Trott — Thu, 09 Apr 2026 15:05:57 +0000

Why the future of code is simpler than you think — and why that matters for everyone.

The Question Nobody's Asking

Here's something odd about the current AI coding revolution: we're using AI to generate JavaScript, Python, TypeScript — languages that were designed for humans to write. But humans aren't writing the code any more. The AI is.

So why are we still optimising for human writability?

The answer, of course, is that humans still need to read the code — to verify it, debug it, and maintain it. But here's the thing: the languages we use make that harder than it needs to be. A hundred lines of React with hooks, closures, and async/await is not easy for a human to verify. It wasn't easy when a human wrote it. It's certainly not easy when an AI wrote it and you're trying to decide whether to trust it.

What if the AI wrote in something simpler?

The Case for Simpler Languages

This isn't about dumbing things down. It's about recognising that the economics of code have changed.

AI makes fewer mistakes in constrained grammars. Give an LLM a language with a small, consistent vocabulary and no syntactic ambiguity, and its error rate drops dramatically compared to JavaScript or Python. Fewer mistakes means less debugging, less rework, less cost.

AI uses fewer resources with simpler output. Generating 30 lines of readable script costs less in tokens than generating 200 lines of framework code that does the same thing. At scale, this is a real cost difference.

Humans can actually verify simple code. This is the critical point. The value of AI-generated code is zero if you can't tell whether it's correct. A non-specialist can look at:

on click SaveButton
begin
    put the content of NameField into Name
    rest post Name to `/api/save`
    set the content of Status to `Saved`
end

...and know exactly what it does. Try that with the equivalent React component.

Simple languages can be made fast. A high-level scripting language written in WebAssembly or C would be indistinguishable in performance from today's mainstream languages for most applications. The simplicity is in the surface syntax, not the execution model.

Where This Is Heading

Let me make a prediction that might be uncomfortable:

Before long, most code will be written by AI and validated — if at all — by humans. The role of the human shifts from author to reviewer. And reviewers need readable code far more than authors do.

When that happens, the value proposition of complex languages changes. JavaScript's flexibility, Python's ecosystem depth, TypeScript's type system — these are advantages for human authors. For AI authors with human reviewers, they're liabilities. They increase the surface area for errors and make verification harder.

What you want instead is a lingua franca — something simple enough that AI rarely gets it wrong, readable enough that humans can verify it at a glance, and powerful enough to build real applications. The complex languages don't disappear, but they move to the edges: systems programming, performance-critical code, specialised domains. The broad middle — the apps, the tools, the dashboards, the automations — gets written in something more like natural language.

This isn't science fiction. It's already starting.

AllSpeak: A Working Example

AllSpeak is a scripting language built around this idea. Instead of:

document.getElementById('myButton').addEventListener('click', function() {
    document.getElementById('output').style.backgroundColor = 'pink';
});

you write:

button MyButton
div Output
attach MyButton to `mybutton`
attach Output to `output`
...
on click MyButton
begin
    set style `background` of Output to `pink`
end

AllSpeak runs in two environments:

In the browser — load a single JavaScript file, write scripts in your HTML
As a command-line tool — pip install allspeak-ai, run .as files directly

No build step. No package manager. No framework. One file in, working application out.

Why AI loves it

Claude Code generates correct AllSpeak on the first attempt almost every time. The grammar is constrained and consistent — no semicolons, no curly braces, no type declarations, no ambiguous syntax. When it does make a mistake, the error is obvious and easy to fix.

And because AllSpeak scripts are short and readable, Claude Code can re-read its own output and make targeted changes. This is fundamentally different from asking an AI to modify 500 lines of opaque JavaScript.

Working with AI changes how you think

There's something deeper here too. Traditional development is bottom-up: define your data structures, write your utilities, build your components, assemble them into a system. You start with what you can hold in your head.

AI-assisted development inverts this. You start at the top — describe the whole application, sketch out the flow, name the pieces — and drill down into the details. The AI generates a working skeleton from your high-level description, and you refine from there. With AllSpeak, this feels natural: you're describing what you want in something close to plain language, and the AI fills in the structure underneath.

This isn't a minor productivity gain. It changes how you think about the problem.

And Then It Gets Interesting: Any Language

Once you have a simple, readable scripting language, something unexpected becomes possible. If the surface syntax is just a mapping from human words to internal opcodes, why does it have to be English?

AllSpeak uses language packs — JSON files that map keywords, grammar patterns, and connector words to a shared set of internal commands. The English pack maps put to the PUT opcode. The Italian pack maps metti. Both compile to identical bytecode.

Last week, with Claude Code doing the heavy lifting and me providing Italian knowledge, I built a fully working Italian variant — complete with documentation — in a single day.

Here's what the same program looks like in both languages:

English:

variable Message
put `Hello from the world!` into Message
log Message

Italian:

language it

variabile Messaggio
metti `Ciao dal mondo!` in Messaggio
registra Messaggio

Same engine. Same bytecode. An Italian speaker reads the second version and understands it immediately — no English required.

There are roughly 1.5 billion English speakers in the world. There are roughly 6.5 billion who aren't. Every mainstream programming language uses English keywords. AllSpeak removes that barrier.

But here's what matters for English-speaking developers too: the architecture that makes multilingual programming possible is the same architecture that makes AI-friendly programming possible. The constraint, the simplicity, the clean mapping from intent to behaviour — those properties serve both goals simultaneously.

Adding a New Language

This is the part that surprised me.

Creating the Italian variant required:

A language pack JSON file — mapping ~150 opcodes and ~80 connector words
Compiler adjustments — making the parser read the active language pack instead of hardcoded English
Runtime adjustments — localised error messages and status output
Documentation — translating the primer and editor UI

The process for adding further languages is now well-understood:

A native speaker with basic programming familiarity can create a new variant in a few days
No deep expertise required — understand variables, loops, and conditions, not the engine internals
The engine doesn't change — only the language pack and docs

What AllSpeak Is Best Suited For

AllSpeak is not trying to replace Python or JavaScript. It occupies the broad middle:

Internal tools and dashboards — forms, data viewers, admin panels
Personal productivity apps — task lists, habit trackers, timers
Prototyping — working demos before committing to a full stack
Education — where tooling complexity distracts from learning
Automation scripts — file processing, report generation, data transformation
IoT and kiosk applications — single-purpose apps with predictable state

For deep OS integration or complex UI component trees, use a mainstream language. AllSpeak handles the human-level logic — flow, decisions, user interaction — while plugins handle the heavy lifting in native code.

The Workflow

The recommended setup uses three tools:

Claude Code — Anthropic's agentic CLI, for writing and modifying AllSpeak scripts
AllSpeak Editor — browser-based editor with syntax highlighting, auto-save, and file browsing
AllSpeak runtime — pip install allspeak-ai for CLI, or a single <script> tag for browser apps

Getting started:

mkdir myproject && cd myproject
pip install -U allspeak-ai
# Download the starter pack for your language from allspeak.ai
unzip allspeak-xx.zip # where xx is your language code

Then launch Claude Code and say: "I want to build a weather dashboard."

What's Next

AllSpeak is actively looking for contributors — particularly native speakers who want to bring programming to their language community. But also developers who are interested in the broader question: what does programming look like when AI writes most of the code and humans are primarily reviewers?

The answer might be simpler than any of us expected.

Get started:

AllSpeak website — overview, primer, and AI manual
Claude Code — the AI assistant that makes it practical
Email: info@allspeak.ai

AllSpeak is named after the Asgardian ability to communicate in any language. It started as an English-only scripting language called EasyCoder. The multilingual architecture was added in April 2026 with AI assistance.

The Catch-22 of programming

Graham Trott — Sat, 29 Nov 2025 21:06:33 +0000

The Catch-22:

Only skilled programmers can guide AI to create good software.
It takes a long time to gain the skills to become a skilled programmer, starting with a long period of simple coding at the entry level.
AI is taking away the jobs of entry-level programmers.

Becoming a programmer

In the early days of computing, the route to becoming a programmer was straightforward. You just did it. Training courses were initially nonexistent, so we had to learn from textbooks and data sheets. The ones who had the motivation to stick with it were the ones who became professional programmers.

After that, in some ways it got a lot easier. Information became more plentiful, and with the arrival of first email then the World Wide Web, there were people you could ask and articles you could read without having to order a book and wait for it to arrive. Courses became available for pretty much anything.

In other ways, though, it didn’t get easier. Software became more complex, and a myriad of tools and libraries became regarded as essential things to know. Job listings started to fill up with acronyms and left many applicants feeling their efforts had all been for nothing, as the prize continued to remain just out of reach.

Programming with an LLM

Then along came AI, and suddenly it seemed a programmer's life became simpler again. No more need to remember every function in a library; just ask AI to find the one you need. But just as we started to get used to this new way of working, these upstart AI systems started to go for our jobs. And now we’re told that pretty much all programming will soon be done entirely by AI engines.

Or so it seems. However, if you actually ask AI to write software, you’ll soon discover that what comes back might be classifiable as a prototype but is likely to be totally unfit for delivery as a finished product. The only way to ensure a good product is to create a bullet-proof prompt to describe what you want, then closely monitor the entire process from start to finish, enforce good working practices and test everything as it gets written. The only person who can do that is a competent programmer.

So we have a Catch-22 situation. To get a good product you need to be an expert to drive AI in the right way. But because AI is taking over all the mundane programming work, few will ever spend the time and effort to become expert. Who in their right mind spends hours churning out boilerplate code when AI will spit it out in seconds? But if you don’t do it yourself you’ll never really learn how to, and you won’t be able to spot the mistakes made by AI. Likewise, you’ll never really know what any given programming language is capable of, and whether AI is making best use of it.

Or to put it more concisely: To get a job you need skills, but to get skills you need a job.

The crux of the matter

This is a situation that is only just developing but is set to get pretty serious quite quickly as the supply of top-level programmers dries up. The risk is that AI-generated products will frequently never develop past the prototype stage, while many will remain incomplete and generally unfit for purpose.

What are our options?

At the heart of the problem is the way we communicate with computers. There are basically 2 ways:

Using traditional high-level languages. This means code written in C++, Java, Python or any other mainstream programming language. As explained above, fewer people will become skilled at this work as AI takes over the lower levels of coding.
Using natural language, e.g. English. This is the new way that has come into its own with the arrival of AI. However, program code must be unambiguous and human language is usually anything but. This is the enemy of AI, as it will usually work with what it thinks you mean rather than question a possible ambiguity, so the result may be subtly or even grossly different to that which you wanted.

Software can be categorised in several ways, but one that I find useful is to distinguish between tools and products. Tools include operating systems and code libraries, and products are the things that are built with the tools. The thing that for me stands out like a lighthouse beacon is that coders use the same language for both, when in fact they often require very different forms of language. A computer algorithm expressed in English is clumsy and hard to follow, and a set of business rules that makes perfect sense in English becomes impenetrable when converted to Python or Java. Real-world requirements are often long chains of ‘if-then-else’ logic, with a frequent need for ‘goto’ to jump from one place to another, which is of course a complete no-no in the world of structured programming. Maybe what we need is a different form of language.

However much automation is provided, there will always be skilled toolmakers. Although it has limited storage capacity, the human brain is capable of insights no machine can match. So why waste such talent by asking such people to simply mind AI while it does all the hard work? Right now, the answer is that there is no separate class of coder with the ability to express clearly what is needed and guide the AI to create it, without having taken the long route to becoming a professional user of conventional languages and tools.

Some people are better than others at expressing clear logic. Many become lawyers, and they use a highly constrained form of English that most of us find difficult to understand, but which has that vital property of being unambiguous. Maybe we need something akin to this when we want to guide AI?

An example

To help clarify where I'm heading, here's an example. Let's suppose the task is to create a new app with a windowing user interface. The first thing is to decide where it will run, so I'll say on any desktop OS. This probably suggests Python should be the language to code for, and I'll constrain it a bit further by specifying PySide to handle the graphics.

The app will mimic a traditional web page, with a central data area, left and right side bars, a title bar and a footer. There's a menu bar with a single menu having 2 items, About and Exit, each with simple behaviours. It looks like this:

Here's an AI prompt to create the app as shown above:

Using PySide6, create a main window with the following attributes:
Location: 100,100
Size: 640,480
Title: My New App
The window contains 3 rows.
The first row is a panel taking 20% of the window height, containing a label with the text ‘Header’.
The second row has a height that is what is left after the other 2 rows are created. It has 3 elements: 1 - a panel taking 20% of the window width, with a label having the text ‘Left’. 2 - a panel taking whatever width is left after the other 2 items are created, with a label having the text ‘Center’. 3 - a panel taking 15% of the window width with a label having the text ‘Right’.
The third row is a panel taking 15% of the window height, containing a label with the text ‘Footer’.
The window has a menu bar with a single ‘File’menu having 2 items:
An ‘About’ item that when clicked shows a simple dialog.
An ‘Exit’ item that terminates the app when clicked.

This is a fairly clumsy way to program. It's largely unstructured, and when changes are needed whole sections may have to be rewritten. Most importantly, to avoid ambiguity it requires discipline in the choice of wording; the kind of discipline that only comes with experience. Since there’s no “compiler” to parse the text and spot problems with language or syntax, errors can easily slip through unnoticed.

So let’s see if we can use a simplified form of English to describe this window. The vocabulary I’ve chosen is arbitrary and many syntax variations can be accommodated to provde alternative ways of expressing the same thing, as in English. To be clear, when I refer to this as English I mean it's text that is mostly if not completely confined to English words, not mathematical symbols. And it’s terse; this is a recipe, not a poem. Let’s call this the pseudocode version.

! Variables used in the script
window Window
layout Content
panel Panel
label Header
panel Panel2
label Left
label Center
label Right
label Footer
menu Menu
menuitem Item

! Create a window
create Window
   at 100 100
   size 640 480
   title `My New App`

! Add the main content; a series of nested panels and labels
create in Window Content type rows

! The first row
create in Content Panel height 20%
create in Panel Header text `Header`

! The second row
create in Content Panel type columns
create in Panel Panel2
create in Panel2 Left width 20% text `Left`
create in Panel Panel2
create in Panel2 Center text `Center`
create in Panel Panel2
create in Panel2 Right width 15% text `Right`

! The third row
create in Content Panel height 15%
create in Panel Footer text `Footer`

! The menu
create in Window Menu text `File`
add to Menu Item text `About`
on click Item show dialog type info text `A sample application`
add to Menu Item text `Exit`
on click Item exit

show Window

This is 47 lines, compared to roughly 100 for the Python code that resulted from the AI query.

This version has a big advantage over the natural language version. It’s compilable to a form that will run directly from the command line. This means it can be used as a prototype product, rather than being just a specification of how to build the product. That’s demonstrated by the last line, show Window, which will display the window on a suitably-equipped system. Compilers and runtimes to handle this kind of script are not hard to write; in fact, something very close to this already exists in the Python world. See EasyCoder. (Disclaimer: This is my own product.)

How does this work with AI?

Can AI use pseudocode instead of natural language to generate a fully native application in whatever underlying language you prefer? To answer this question, I did the following:

First, I submitted the original natural-language request to DeepSeek, which generated Python code. The image above is a screenshot of the running code.

I then asked DeepSeek if it could recognise the pseudocode version. It came back with the confirmation that the two versions were in fact identical, and that if a suitable dictionary were built it could easily handle pseudocode instead of natural language. It described the approach as

a declarative UI specification system where:
Pseudocode = Human-readable UI description
Keyword dictionary = Mapping to actual UI components and properties
Generator = Interprets pseudocode → creates actual UI code

then went on to comment that

This is similar to how many modern UI frameworks work (React, Vue components) but with an even more abstracted, human-readable syntax.

and offered the following:

Benefits of This Approach:
Rapid Prototyping - Write UI structure in simple English-like syntax
Consistency - Enforced patterns through keyword definitions
Platform Independence - Same pseudocode could generate PySide6, Tkinter, web UI, etc.
Non-technical Friendly - Designers can specify layouts without coding
Version Control Friendly - Pseudocode is clean and diff-able

Compilable pseudocode reduces complexity

In the example above, many assumptions have been made. The way items are positioned and sized in their parent containers, the foreground and background colors, the fonts used for text, border widths and so on. In the browser world these are all handled by stylesheets, and in fact PySide handles most common stylesheet definitions. In any practical application, some form of stylesheet will have to be defined, holding global values and values that are specific to a class of on-screen widget. Doing all of this using natural language is painful to say the least, but a variant of the same pseudocode can be used to create JSON stylesheet files that can be read by the compiler. The language will need a vocabulary that allows the user to define which styles belong where, but this is not a hard task. DeepSeek offered to design such a system for me, but I’m not yet ready quite yet to dive further into this.

By scripting with compilable pseudocode, products can be developed quickly with or without AI, or by combining both. If people start to use pseudocode, AI will gradually be able to provide more assistance in creating applications by examining examples of those already created.

How does this change the way we work?

Unlike natural language, pseudocode scripts can be compiled on any computer and then run; hence the last line in the script shown above - show Window. The entire script can be run from the command line, directly from the source text. The performance may not be sparkling, but as a means of catching errors it's unbeatable as corrections can be made instantly and the run started again. Typical compilation times are in the tens of milliseconds, even for quite large scripts. The runtime even includes a visual debugger that allows breakpoints to be added and variables examined with the application halted.
The script uses a lot of variables to represent screen elements. Some of these are reused but others hold values that are of interest for the lifetime of the application. The natural language version might name such elements, but the syntax to refer to them will be clumsy and impede understanding. Having them available as code elements allows them to be accessed at any time simply by name.
Since performance is rarely an issue with prototypes, the compiler and runtime for these scripts can check very aggressively for potential coding errors during the development phase. Typical examples are the wrong type of variable being used, or an attempt to use a variable that has no value assigned to it. Once the prototype is seen to run without errors the script can be submitted to AI for recoding in Python, JavaScript, C++ or whatever is best for the target environment. This maximises performance.

New opportunities

This takes us back to the title of this article - the catch-22. Pseudocode allows very large chunks of functionality to be represented by a fairly concise English syntax. New functionality, created by experts in their fields, gets added as extra pseudocode vocabulary, which is easily understood by AI and by people familiar with the domain in which they are working. It is fairly easy to take a given piece of functionality and create a new language feature for it, and it does not usually require any great knowledge of how that functionality is coded. Take Google Maps, for example, which has a remarkably simple API for such a complex and comprehensive product. We will still need highly skilled programmers to create new core functionality, but pseudocode unlocks the door to making it accessible to those with more limited skills, to build the products that depend on this functionality. This could well be where most human programmers will be employed; managing AI efficiently to create the applications needed by the world.

And let’s not forget the problem of maintenance. Having advanced applications coded in pseudocode that can be understood both by AI and by humans makes future maintenance far simpler than requiring every maintenance engineer to know the details of every programming language and its libraries.

Summary

As AI takes over the jobs of those doing simpler forms of coding, fewer people will come up through the system and progress to the higher skill levels. The adoption of a suitable pseudocode for describing a wide range of applications will reduce the need for highly skilled coders and create a demand instead for logical thinkers who understand problem domains and can translate requirements into a form that can run as a prototype. Once this has been tested thoroughly it can then be handed to AI to generate the final code for the target environment.

OTA Python updates with ESP-Now

Graham Trott — Sat, 27 Sep 2025 14:33:42 +0000

This is the third article in a series about using ESP-Now to implement an ESP32-based master-slave network. Part one describes the main network comms class and part two describes how to follow the system router when it channel-hops. In this final article I'll describe an implementation of over-the-air (OTA) updates to the Python and other files held on the devices.

In part one of this series, when a message is received it is handed to a message handler, which carries out the needed action(s) and returns a result. The following is that message handler. Most of it is directly applicable to any similar application, since there are only so many things a network slave is able to do.

import asyncio,machine,os
from binascii import unhexlify
from files import readFile,writeFile,renameFile,deleteFile,createDirectory

class Handler():

    def __init__(self,config):
        self.config=config
        config.setHandler(self)
        self.relay=config.getRelay()
        self.saveError=False

    def handleMessage(self,msg):
#        print('Handler:',msg)
        bleValues=self.config.getBLEValues()
        response=f'OK {self.config.getUptime()} :{bleValues}'
        if msg=='uptime':
            pass
        elif msg == 'on':
            response=f'{response} ON' if self.relay.on() else 'No relay'
        elif msg == 'off':
            response=f'{response} OFF' if self.relay.off() else 'No relay'
        elif msg == 'relay':
            try:
                response=f'OK {self.relay.getState()}'
            except:
                response='No relay'
        elif msg=='reset':
            self.config.reset()
            response='OK'
        elif msg == 'ipaddr':
            response=f'OK {self.config.getIPAddr()}'
        elif msg=='channel':
            response=f'OK {self.config.getChannel()}'
        elif msg[0:8]=='channel=':
            channel=msg[8:]
            self.config.setChannel(channel)
            response=f'OK {channel}'
        elif msg[0:7]=='environ':
            environ=msg[8:]
            self.config.setEnviron(environ)
            response=f'OK {environ}'
        elif msg=='temp':
            response=f'OK {self.config.getTemperature()}'
        elif msg=='pause':
            self.config.pause()
            response=f'OK paused'
        elif msg=='resume':
            self.config.resume()
            response=f'OK resumed'
        elif msg[0:6]=='delete':
            file=msg[7:]
            response='OK' if deleteFile(file) else 'Fail'
        elif msg[0:4]=='part':
        # Format is part:{n},text:{text}
            part=None
            text=None
            items=msg.split(',')
            for item in items:
                item=item.split(':')
                label=item[0]
                value=item[1]
                if label=='part': part=int(value)
                elif label=='text': text=value
            if part!=None and text!=None:
                text=text.encode('utf-8')
                text=unhexlify(text)
                text=text.decode('utf-8')
                if part==0:
                    self.buffer=[]
                    self.pp=0
                    self.saveError=False
                else:
                    if self.saveError:
                        return 'Save error'
                    else:
                        if part==self.pp+1:
                            self.pp=part
                        else:
                            self.saveError=True
                            return f'Sequence error: {part} {self.pp+1}'
                self.buffer.append(text)
                response=f'{part} {str(len(text))}'
        elif msg[0:4]=='save':
            if len(self.buffer[0])>0:
                fname=msg[5:]
                tname=f't-{fname}'
                print(f'Save {tname}')
                size=0
                f = open(tname,'w')
                for n in range(0, len(self.buffer)):
                    f.write(self.buffer[n])
                    size+= len(self.buffer[n])
                f.close()
                # Check the file against the buffer
                if self.checkFile(self.buffer, tname):
                    response=str(size)
                    print('File saved')
                else: response='Bad save'
            else: response='No data'
            text=None
        elif msg=='update':
            for tname in os.listdir('.'):
                if tname[0:2]=='t-':
                    fname=tname[2:]
                    print(f'Update {fname}')
                    deleteFile(fname)
                    renameFile(tname,fname)
            response='OK'
        elif msg[0:5]=='mkdir':
            path=msg[6:]
            print(f'mkdir {path}')
            response='OK' if createDirectory(path) else 'Fail'
        else: response=f'Unknown message: {msg}'
#        print('Handler response:',response)
        return response

    def checkFile(self, buf, file):
        try:
            with open(file, 'r') as f:
                i = 0  # index in lst
                pos = 0  # position in current list item
                while True:
                    c = f.read(1)
                    if not c:
                        # End of file: check if we've also finished the list
                        while i < len(buf) and pos == len(buf[i]):
                            i += 1
                            pos = 0
                        return i == len(buf)
                    if i >= len(buf) or pos >= len(buf[i]) or c != buf[i][pos]:
                        return False
                    pos += 1
                    if pos == len(buf[i]):
                        i += 1
                        pos = 0
        except OSError:
            return False

`init()`

The system makes extensive use of a Config class, which holds all the system-specific configuration data such as which I/O pins do what. It also acts as a central message interchange, with functions that either return an object that has the required functionality or call the objects themselves, avoiding the need for every class to know about all the others. So in this Handler class, the relay object supplied by Config is a class that has the ability to turn the relay on and off and to return the current relay state.

`handleMessage()`

This is where most of the work is done. The function handles a set of commands, most of which should be fairly obvious, though some will be more relevant than others. For example, elsewhere in the code there's a Bluetooth (BLE) module that collects occasional transmissions from specific devices and for some message types appends these values to the string that is returned to the caller. In my system these are temperature values, but not everyone will want this feature.

The most interesting part of this is the OTA file updater, which works like this. The maximum size of an ESP-Now data packet is something over 200 bytes, so few Python scripts can be transferred in a single message. I chose to send 100 bytes at a time, with the text data encoded as hex values. The file is sent as a series of messages, each containing 100 bytes, and the messages are prefixed by the command part and a part number starting with zero. The function splits up the packet to extract the part number and the data itself. If the part number matches what was expected, the text is added to a list, otherwise the function returns an error. For a successfully received part, the function returns the part number and the size of the data, which the sender can use to verify that it has been received successfully.

When all the parts have been sent, the list can be saved to a temporary file. This is done by the save command.

`checkFile(()`

Now we need to check the data has not been corrupted. This function reads the file back, one character at a time, and compares it with the contents of the list. If no errors are found, the new file can be assumed to be good.

However, a problem comes when several Python files all need to be updated together. If only some of the files are updated and then an error occurs or for some other reason the update stops, there could be a mismatch between the various parts and the program will not run after the next reboot. So rather than update files one by one they should instead be done as a batch. Only when all of the files have been saved and checked is it then safe to rename the entire batch. This is done by the update command.

In a practical implementation, when an error is discovered and reported back to the sender, the entire save can be retried. Although for the most part OTA updates proceed without a hitch, in some cases, particularly where the signal strength isn't great or suffers from interference, it can take several attempts to transfer a large file. I allow up to 10 retries before abandoning the save.

Channel-hopping on the ESP32-C3 with ESP-Now

Graham Trott — Sat, 27 Sep 2025 14:30:21 +0000

This is the second article in a series about using ESP-Now in Micropython to implement an ESP32-based master-slave network. Part one describes the main network comms class and part three describes how to do reliable OTA file updates.

The 2.4GHz wifi band is getting crowded. Much of the heaviest traffic now goes on 5GHz, but that leaves a lot of devices competing for bandwidth; in particular those in the world of IOT. Modern domestic routers deal with this by channel-hopping; they periodically monitor the network to see which channel is the least busy and switch to that channel. This can happen as frequently as every hour or two, but I would hope that routers are intelligent enough to realise that constantly ping-ponging back and forth would be mostly ineffective as well as annoying. For although computer operating systems can deal pretty seamlessly with channel-hopping, simpler devices don't have the firmware to do this, leaving you and me to do it in our applications.

The simplest and most recommended approach is of course to restrict the router to a single channel, but this is only feasible if you have control of the router. For my master-slave system I made no such assumption; I decided to grab the bull by the horns and work out a solution.

Before continuing, I should mention that this code has been developed for the ESP32-C3, which is a cut-down device with only a single radio subsystem. This means it can only handle a single wifi channel. Other variants have two subsystems and can operate two channels independently. The code here and in the rest of the series is built to handle the more constrained environment. During development I found that many published articles about ESP-Now on the ESP32 don't work on the C3 variant as they rely on having the dual-radio.

In fact, with dual radio devices there may well be no need to channel-hop at all. The entire ESP-Now subsystem can operate independently of the AP and STA interfaces. However, the C3 variant occupies a niche that was previously filled by the ESP8266; low cost and very small size, as exhibited by devices such as the ESP32-C3 Super Mini and the ESP01-C3, allowing a full implementation of Micropython to run many cost and space-critical applications. Here's a ESP32-C3 Super Mini (with antenna) and an ESP01-C3.

So if you're still with me, here's the code:

import asyncio,machine,time

class Channels():
    def __init__(self,espComms):
        print('Starting Channels')
        self.espComms=espComms
        self.config=espComms.config
        self.channels=[1,6,11]
        self.myMaster=self.config.getMyMaster()
        if self.config.isMaster():
            self.ssid=self.config.getSSID()
            self.password=self.config.getPassword()
            asyncio.create_task(self.checkRouterChannel())
        self.resetCounter()

    def setupSlaveTasks(self):
        print('Set up slave tasks')
        asyncio.create_task(self.findMyMaster())
        asyncio.create_task(self.countMissingMessages())

    def resetCounter(self):
        self.idleCount=0

    async def findMyMaster(self):
        if await self.ping(): return
        self.hopToNextChannel()
        asyncio.get_event_loop().stop()
        machine.reset()

    async def ping(self):
        peer=bytes.fromhex(self.myMaster)
        self.espComms.espSend(peer,'ping')
        _,msg=self.espComms.e.recv(1000)
        print('Ping response from',self.myMaster,':',msg)
        if msg:
            print('Found master on channel',self.espComms.channel)
            return True
        return False

    async def countMissingMessages(self):
        print('Count missing messages')
        espComms=self.espComms
        ap=espComms.ap
        e=espComms.e
        self.idleCount=0
        while True:
            await asyncio.sleep(1)
            self.idleCount+=1
            limit=30
            if self.idleCount>limit:
                print('No messages for 30 seconds')
                # Retry the current channel
                if await self.ping():
                    self.idleCount=0
                    continue
                print(f'Master not found on channel {self.espComms.channel}\n')
                self.hopToNextChannel()
                asyncio.get_event_loop().stop()
                machine.reset()

    def hopToNextChannel(self):
        index=-1
        for n,value in enumerate(self.channels):
            if value==self.espComms.channel:
                self.espComms.channel=self.channels[(n+1)%len(self.channels)]
                index=n
                break
        if index==-1: self.espComms.channel=self.channels[0]
        self.config.setChannel(self.espComms.channel)

    async def checkRouterChannel(self):
        print('Check the router channel')
        while True:
            await asyncio.sleep(300)
            sta=self.espComms.sta
            sta.disconnect()
            time.sleep(1)
            print('Reconnecting...',end='')
            sta.connect(self.ssid,self.password)
            while not sta.isconnected():
                time.sleep(1)
                print('.',end='')
            channel=sta.config('channel')
            if channel!=self.espComms.channel:
                print(' router changed channel from',self.espComms.channel,'to',channel)
                asyncio.get_event_loop().stop()
                machine.reset()
            print(' no channel change')
            self.espComms.restartESPNow()

In this system, the ESPComms class described previously manages all network functions except for the channel hopping, which is done by this Channels class. The system also makes heavy use of a Config class, which manages system data such as SSIDs and passwords, I/O pin usage and so on. It also acts as a central routing point for most communications between other modules, having getter and setter functions that just pass on calls to the appropriate class. Channels is something of an exception as it's tied quite closely to ESPComms, so most of the function calls in this class go there directly.

`init()`

This defines the channels to be used. Although there are about 14 distinct channels in the 2.4GHz band, they are close enough together that adjacent ones overlap quite seriously. In fact, there are only three completely non-overlapping channels: 1, 6 and 11, so it will come as no surprise that most routers hop between these three. The function defines these channels. Its other job is to start up an asynchronous job (checkRouterChannel(), see below) to monitor the system and detect when the channel has changed. This is needed when the system acts as the master device, as otherwise the change of channel might go undetected.

`setupSlaveTasks()`

This is typically called later during initialization, after other things have settled down.

`resetCounter()`

The class constantly increments a counter, and when it reaches a predefined limit, action must be taken. This function is called from ESPComms whenever a message is received, to prevent the action from being triggered.

`findMyMaster()`

When a slave starts up it has no way of knowing which channel its master device is using. So it calls this function, which issues a 'ping' message on the channel that was saved during the last run. If it gets a reply it knows it's picked the right channel. Otherwise, it hops to the next channel, thereby saving the new channel number, and resets itself. Only once it gets a reply to the ping can it break out of this endless cycle and start normal operations.

`countMissingMessages()`

This function runs continuously, incrementing the counter and checking if it has exceeded its set limit. If so, it first pings the master to see if this is still awake and on the same channel. There may be a perfectly valid reason for missing messages, such as the system being in maintenance mode where normal operations are suspended. If the ping fails, the device will reboot and re-enter the findMyMaster() cycle above.

`ping()`

This sends a 'ping' message to the master device and waits for a reply, returning True if it gets one within a second. To save you having to look it up, the function espSend() in ESPComms is:

    def espSend(self,peer,msg):
        if self.addPeer(peer):
            try: self.e.send(peer,msg)
            except Exception as ex: print('espSend:',ex)

`countMissingMessages()`

This continually increments idleCount and checks if it has reached its predefined limit. If so, messages have gone missing, so it hops to the next channel and resets.

`checkRouterChannel()`

This is called periodically - say every 5 minutes - by the system master to ensure it is still on the same channel as the router. To do this, the STA interface must be deactivated and reconnected. If the channel has changed, a reboot is needed, otherwise ESP-Now can be restarted.

ESP-Now master-slave in Micropython

Graham Trott — Sat, 27 Sep 2025 14:25:23 +0000

This article describes how to build a master-slave network of ESP32 devices using Micropython and ESP-Now.

ESP-Now is a simple low-level protocol for communicating between ESP32-based devices independently of HTTP. Many articles have been written on the subject, but the great majority cover simple scenarios, and once things get more complex these simple techniques start to reveal their limitations. This article is the result of several weeks of trial and error, with extensive help from DeepSeek, which patiently sought out the answers to a seemingly endless series of baffling questions.

[Note: When I asked DeepSeek how best to make code available to a wider audience, it encouraged me to write this article. Forgive me for anthropomorphising slightly, but AI engines appear to enoy reading articles that describe working code. They also examine code repositories, but it seems they give greater weight to those that are supported by articles aimed at a technical readership.]

The system in question comprises a single master (hub) device that acts as a gateway to an indefinite number of slaves arranged as a star network. In a previous article, I described how to extend such a network by arranging for slaves to run their own local networks, which overcomes the problem of wifi range and also of the number of peers that any one node can support. The code I presented was somewhat simplistic and proved to have a number of limitations, so here I describe a revised class that deals with the problems unearthed during the development process.

I'll start by presenting the code, then I'll describe its most important features:

import asyncio,network,time,random,machine
from espnow import ESPNow

class ESPComms():
    e=ESPNow()

    def __init__(self,config):
        self.config=config

        if config.isMaster():
            print('Starting as master')
            try:
                self.sta=network.WLAN(network.WLAN.IF_STA)
                self.sta.active(True)
                ssid=self.config.getSSID()
                password=self.config.getPassword()
                print(ssid,password)
                t=0
                print('Connecting...',end='')
                self.sta.connect(ssid,password)
                while not self.sta.isconnected():
                    time.sleep(1)
                    t+=1
                    if t>30:
                        print('Timeout')
                        config.clearAndReset()
                    print('.',end='')
                ipaddr=self.sta.ifconfig()[0]
                self.channel=self.sta.config('channel')
                self.config.setIPAddr(ipaddr)
                print(f'{ipaddr} ch {self.channel}')
            except: machine.reset()
        else:
            self.channel=config.getChannel()
            print('Starting as slave on channel',self.channel)
        ap=network.WLAN(network.AP_IF)
        ap.active(True)
        ap.config(channel=self.channel)
        mac=ap.config('mac').hex()
        config.setMAC(mac)
        self.ssid=f'RBR-Now-{mac}'
        ap.config(essid=self.ssid,password='00000000')
        ap.ifconfig(('192.168.9.1','255.255.255.0','192.168.9.1','8.8.8.8'))
        self.ap=ap
        config.setAP(ap)
        print(config.getName(),mac)
        if not config.isMaster():
            self.sta=network.WLAN(network.WLAN.IF_STA)
            self.sta.active(True)

        self.e.active(True)
        print('ESP-Now initialised')

        self.requestToSend=False
        self.sending=False

    def closeAP(self):
        password=str(random.randrange(100000,999999))
        print('Password:',password)
        self.ap.config(essid='-',password=password)

    def addPeer(self,peer):
        h=peer.hex()
        if not hasattr(self,'peers'):
            self.peers=[]
        if h in self.peers:
            return True
        try:
            self.e.add_peer(peer,channel=self.channel)
        except OSError as ex:
            print(f'Failed to add peer {h} to ESP-NOW: {ex}')
            return False
        self.peers.append(h)
        print('Added',h,'to peers on channel',self.channel)
        return True

    def espSend(self,peer,msg):
        if self.addPeer(peer):
            try: self.e.send(peer,msg)
            except Exception as ex: print('espSend:',ex)

    def send(self,mac,msg):
#        print(f'Send {msg[0:20]}... to {mac} on channel {self.channel}')
        self.requestToSend=True
        while not self.sending: await asyncio.sleep(.1)
        self.requestToSend=False
        peer=bytes.fromhex(mac)
        if self.addPeer(peer):
            try:
                result=self.e.send(peer,msg)
                if result:
                    result=None
                    counter=100
                    while counter>0:
                        while self.e.any():
                            _,reply=self.e.irecv()
                            if reply:
                                reply=reply.decode()
                                if reply=='ping': continue
#                                print(f"Received reply: {reply}")
                                result=reply
                                break
                        if result: break
                        await asyncio.sleep(.1)
                        counter-=1
                    if counter==0: result='Fail (no reply)'
                    else:
                        print(f'{msg[0:20]} to {mac}: {result}')
                        self.config.resetCounter()
                else: result='Fail (no result)'
            except Exception as ex:
                result=f'Fail ({ex})'
                print(result)
        else: result='Fail (adding peer)'
        self.sending=False
        return result

    async def receive(self):
        print('Starting ESPNow receiver')
        while True:
            if self.e.active():
                while self.e.any():
                    mac,msg=self.e.recv()
                    msg=msg.decode()
                    print('Received',msg)
                    if msg=='ping':
                        try:
                            self.addPeer(mac)
                            self.e.send(mac,'pong')
                        except Exception as ex: print('ping:',ex)
                    else:
                        if msg[0]=='!':
                            # It's a message to be relayed
                            comma=msg.index(',')
                            slave=msg[1:comma]
                            msg=msg[comma+1:]
#                            print(f'Slave: {slave}, msg: {msg}')
                            response=await self.send(slave,msg)
                        else:
                            # It's a message for me
                            response=self.config.getHandler().handleMessage(msg)
                            response=f'{response} {self.getRSS(mac)}'
                        self.addPeer(mac)
                        try:
                            self.addPeer(mac)
                            self.e.send(mac,response)
                            print(response)
                            self.config.resetCounter()
                            if not self.config.getMyMaster() and not self.config.isMaster():
                                self.config.setMyMaster(mac.hex())
                        except Exception as ex: print('Can\'t respond',ex)
                if self.requestToSend:
                    self.sending=True
                    while self.sending: await asyncio.sleep(.1)
            else: print('Not active')
            self.config.kickWatchdog()
            await asyncio.sleep(.1)

    def getRSS(self,mac):
        try: return self.e.peers_table[mac][0]
        except: return 0

    def restartESPNow(self):
        self.e=ESPNow()
        self.e.active(True)

The job of this class is to deliver small packets of data to specified MAC addresses and to return results back to the caller. As ESP-Now is a low-level protocol it does not deal with IP addresses, access point names or any of the other higher layers of the OSI model.

ESP-Now requires the device to be already set up in either Access Point or Station mode. Its communications go unnoticed by higher-level functions such as HTTP, so it can run concurrently with them.

In this class, the master (hub) device connects to the house router with its station (STA) interface but the slaves do not (they still however require STA to be active for ESP-Now to work). Both master and slaves use the same code modules but in different ways. In both cases, an access point (AP) is set up for the first 2 minutes following a reboot, so that an administrator can talk directly to the device over-the-air from a local browser. This feature is used for configuration, mostly avoiding the need for ESP32 modules to be physically extracted for code alterations.

In this implementation, all messages, commands and requests are initiated outside of the ESP-Now network and handed to an HTTP server maintained by the master for onward transmission. Slave devices do not initiate messages other than the occasional 'ping' (see below). Adding full two-way messaging would result in considerable extra complexity, and all the necessary features can usually be provided without it.

The code here was developed with a lot of trial-and-error and the assistance of AI to find relevant examples. There turned out to be none that directly considered the complexities of the scenario; most are far simpler. If anyone else has solved the same problem, they hadn't told the world about it at the time this code development was underway.

`init()`

The class makes use of a second module, Config, which handles system parameters such as router SSID/password and identifies which I/O pins are used by the device. This data is typically held in a JSON file that can be read and written as necessary. Wherever you see config.xxxxx(), a function in the config module is being called.

ESP-Now is extremely fussy about configuration. There may be differences between the variants of ESP32; this code is known to work on ESP32-C3, which is a fairly basic model, so it should be fine on most other variants. There is a strict sequence to follow, which differs between master and slave.

The master first requires STA to be active. Here it is connected to the house router, which governs the wifi channel the system will use. Then the AP is set up, and finally ESP-Now is activated. This ordering guarantees that ESP-Now will use the STA wifi channel.

The slave does things the other way round, first setting up AP and following that with a stub STA. This ensures that the AP channel will be used for ESP-Now communications. If you don't get this order right, some things will probably not work and strange errors will arise.

`closeAP()`

During the first 2 minutes following boot, the AP can be connected from a browser and will accept requests and commands. These include rewriting the JSON config file and rebooting the device. After this period, the SSID of the AP is changed to - and a random password is applied, making it almost impossible to discover and connect to. This is a security feature that prevents malicious interference unless the attacker can physically repower the device.

`addPeer()`

It's very easy to get ESP-Now peer management wrong. The published documentation gives few hints as to how fussy the protocol is about handling peers. For example, it fails to mention that a channel change not only invalidates the peers table but makes it impossible to recreate. Only a reset will do that.

Although ESP-Now will happily receive messages from anywhere, sending can only be done to a peer whose MAC address has been registered with e.add_peer(). This must be done just once for any given peer or an error will be thrown. So this function manages its own peers list to track what has already been added. Note that the device is likely to have 2 MAC addresses; one for each of its 2 interfaces. When you initiate a send it will usually be to one of these, but when replying to a message it will be the other. Both must be added to the peers table.

`send()` and `receive()`

The receive() function runs asynchronously in a loop, waiting for messages and replying to them. The original version of this class allowed messages to be sent without any consideration of what might happen if both activities try to take place at the same time. In a simple situation this will often work, but it's extremely vulnerable. One solution that appeared in the AI searches was to use a lock, so that send and receive can be exclusive, but this gives rise to some horrible issues that are hard to track down. The strategy here is one that avoids such issues and is much easier to debug.

In the receive loop, when a message arrives it is passed to the handleMessage() function in a companion Handler class, which returns a reply to send back to the caller. While this is happening, a sending flag is set False. Any request to send will cause the sender to raise requestToSend and block until sending goes True, which is done at the bottom of the receive loop. The receive function can tell from requestToSend that the sender is waiting. The function can now release sending to allow the message to be sent, and it then waits for that process to finish.

However, a received message might not have come from the device we just sent to. This system is designed to handle router channel changes, and when this happens the master quickly changes to the new channel, but all the slaves know is that messages have stopped arriving (because they're all on the wrong channel). So after a while they issue a 'ping' message to the master. If it replies they're on the right channel, otherwise they change channels and try the ping again.

The result is that one or more 'ping' messages can arrive while the sender is waiting for a reply to its own message, so the code watches out for them and discards them. Eventually it sees its own reply message and returns it to the caller, but before doing so it clears sending, which releases the receiver to look out for more incoming messages.

Note that this code cannot deal with anything but 'ping' messages from its slaves. Any scenario requiring a more general 2-way send and receive will probably need to use some form of addressing to identify message senders.

The code in receive() has one more feature. If the received message starts with ! it's not for this device, but instead is a request to forward a message to another device. The MAC address of the intended recipient follows the ! and is terminated by a comma. The code strips these away and is left with a MAC address and a (shorter) message, which it forwards, returning whatever returns back up to its own caller.

Channel changes

Because the 2.4Ghz wifi band is often quite crowded, most modern wifi routers run a background task that looks out for the least busy channel. Every so often, typically at intervals of several hours, the router will then change to this quieter channel. PC operating systems are aware of this behaviour and engage in a dialog with the router to get advance notice of an upcoming change, so the effect is barely noticeable by the users of these machines. However, simple IOT devices are not generally equipped to deal with channel changes; all they know is that messages stop arriving. To avoid the need to restrict a router to a single channel, the Channels class works with the code above to deal with this and other related issues, and this is described in part two of this series. Part three describes the message handler, which includes a strategy for reliably updating Python modules over the air.

Full code and documentation for the project can be found at https://github.com/easycoder/rbr. The Micropython code is in the RBRNow folder. I may be able to keep the code above in step with changes as they happen, but it would be better to use the repository version.

An AI virtual keyboard

Graham Trott — Mon, 12 May 2025 15:30:49 +0000

I only recently overcame my usual inertia and responded to the invitations by VSCode to start using Copilot. Since then I've spent quite some time refining a fairly complex prompt, so I've decided to share my experience with the community.

I operate in the world of Python. In this world there really is no excuse for not using a graphical interface wherever one is appropriate. It's really easy to get Copilot to create a UI to accept input and present output, though a little harder to produce something that's also aesthetically pleasing. But there's a point at which a prompt takes longer to write than does coding the entire job manually.

The project I'm working on is a home heating control system, the control code and the user interface for which are both written in Python, the latter with some help from Copilot. The controller hardware is a 7-inch industrial computer from Ali Express, which arrived with a dreadful Android implementation but which I successfully reflashed to Debian Linux. Now it's a proper computer, but it lacks an essential feature; there's no virtual keyboard. (There seem to be a couple of truly appalling ones out there, but I wouldn't inflict them on a customer.)

So the need was for a Python virtual keyboard. Quite a tedious manual programming task, but I figured it would be ideal for Copilot to get its teeth into. I decided to emulate an Android keyboard, which has 4 views that switch when shift or mode keys are tapped, and above the keys there's a text field for the characters being typed. Here's the first view of the keyboard:

'Prompt engineering' is the term that refers to the skill needed to get effective results from an AI tool. As with most things in life, the GIGO principle applies; Garbage In, Garbage Out. I found it necessary to apply a good deal of guidance or the results had severe limitations and were a poor starting point for further manual embellishment. But if you're careful with your prompts you can get quite decent Python code from an AI engine.

I say "can" because there's a massive caveat coming. A keyboard is not an exceptionally complex item, but without a lot of guidance all the AI engines I tried produced poorly structured code that didn't behave properly. So I tried again, this time leveraging my existing knowledge of Python and PySide (the Qt graphics library module) to structure my prompt. I requested a series of classes - a keyboard button, a row of buttons, a keyboard view comprising several rows, and finally the keyboard itself - giving for each class a set of function definitions and letting Copilot fill in the details. It turned out to be quite a substantial task. In fact, the prompt - even though it's incomplete - is far longer than the final working Python code - somewhere around 500 lines versus 320 lines of Python.

One problem is that human-computer interfaces are a lot more complex that might be imagined, and a lot of details have to be spelled out in, well, excruciating detail. That's a job for a computer program, of course, which begs the question of what kind of language we should be using to write AI prompts. It's early days for this technology, but I feel there's a Eureka! moment waiting to be unearthed.

Sadly, the rather long prompt below will not create a complete keyboard. For example, there's no text box to receive the typed characters. And if your experience is anything like mine, you won't get a complete set of keyboard views; Copilot just generates a comment that views 1, 2 and 3 are similar to view 0 and invites you to do the rest yourself. It seems to be influenced by previous versions of your prompt and decides to ignore bits of the new one. However, what you do get is probably enough to make completing the job by hand relatively easy.

And that's my main take-away from this exercise. There are a lot of details that are simply too tedious to cover in an all-encompassing prompt script. You're far better off generating the main outline then using smaller prompts to fill in the nit-picky little details.

The bottom line is, AI isn't going to take away your job and do it better. Not yet, anyway. But it can be a most valuable assistant, so please start using it. And your comments are welcome - I'm still at the start of the learning curve.

(Cover image by Gemini)

This prompt describes a virtual keyboard,
to be written in Python using Pyside6 graphics.
I provide Python-style class definitions,
with constructor and function prototypes.
Python comments are general notes and instructions
to help build the classes.

#---------------------------------------------------------------

class KeyboardButton(QPushButton):
    def __init__(self, width, height, callback, text, icon):

# The text to be shown on the button can be any string or None
# The icon to be shown on the button can be any graphic, or None
# The button has rounded corners of radius 20% of its height
# The font size is half the button height
# The background of the button is white
# Apply a light shadow to the right and bottom of the button
# When the button is clicked it moves 2 pixels down and right,
# waits 200ms then moves back to its original position.
# On click, call function 'callback' with the value of 'text'.

#---------------------------------------------------------------

class KeyboardRow(QHBoxLayout):
    def __init__(self, list):  # add the items in 'list'

#---------------------------------------------------------------

class KeyboardView(QVBoxLayout):
    def __init__(self, list):  # add the items in 'list'

#---------------------------------------------------------------
This class is a complete keyboard with 4 views,
which are added one by one and only one of which can be visible.

class VirtualKeyboard(QStackedWidget):
    def __init__(self, buttonHeight):
        super().__init__()
        self.buttonHeight = buttonHeight
    def addView(self, view): # Add 'view' to the VirtualKeyboard
    def getCurrentView(self): # return the current index
    def onClickChar(self, keycode): # Print the key code
    def onClickShift(self, keycode): # Print 'Shift'.
        # if currentView is 0 call AbstractKeyboard.setCurrentIndex(1)
        # elif currentView is 1 call AbstractKeyboard.setCurrentIndex(0)
    def onClickNumbers(self, keycode):  # Print `Numbers`
        # call AbstractKeyboard.setCurrentIndex(2)
    def onClickLetters(self, keycode):  # Print `Letters`
        # call AbstractKeyboard.setCurrentIndex(3)
    def onClickBack(self, keycode):  # Print 'Back'
    def onClickSpace(self, keycode):  # Print `Space`
    def onClickEnter(self, keycode):  # Print 'Enter'

# This class sets up a keyboard

# __init__() calls each of the addKeyboardLayout() functions

The 4 keyboard views are as follows.
All buttons have the height given by buttonHeight.
All buttons have the same width as their height
unless specified otherwise.

#---------------------------------------------------------------
# View 0

Create an empty row list

Create a list of KeyboardButton with the characters in 'qwertyuiop'
The 'callback' function is onClickChar
Create a KeyboardRow with this list
Add the KeyboardRow to the row list

Create an empty list of widgets
Add a horizontal stretch to the widget list
Create a list of KeyboardButton with the characters into 'asdfghjkl'
The 'callback' function is onClickChar
Append this list to the widget list
Add a horizontal stretch to the widget list
Create a KeyboardRow with the widget list
Add the KeyboardRow to the row list

Create an empty list of widgets
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'up.png'
    the 'callback' function is onClickShift
Append the KeyboardButton to the widget list
Append a spacer whose width is 5% of the standard height
Create a list of KeyboardButton with the characters in 'zxcvbnm'
The 'callback' function is onClickChar
Append this list to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'back.png'
    the 'callback' function is onClickBack
Append the KeyboardButton to the widget list
Create a KeyboardRow with the widget list
Add the KeyboardRow to the row list

Create an empty list of widgets
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'numbers.png'
    the 'callback' function is onClickNumbers
Append the KeyboardButton to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with the character ','
The 'callback' function is onClickChar
Append this button to the widget list
Create a KeyboardButton with
    a width 500% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'space.png'
    the 'callback' function is onClickSpace
Create a KeyboardButton with the character '.'
The 'callback' function is onClickChar
Append this button to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'enter.png'
    the 'callback' function is onClickEnter
Append the KeyboardButton to the widget list
Create a KeyboardRow with the widget list
Add the KeyboardRow to the row list

Create a KeyboardView with the row list
Add the KeyboardView to this VirtualKeyboard

#---------------------------------------------------------------
# View 1

Create an empty row list

Create a list of KeyboardButton  with the characters in 'QWERTYUIOP'
The 'callback' function is onClickChar
Create a KeyboardRow with this list
Add the KeyboardRow to the row list

Create an empty list of widgets
Add a horizontal stretch to the widget list
Create a list of KeyboardButton  with the characters in 'ASDFGHJKL'
The 'callback' function is onClickChar
Append this list to the widget list
Add a horizontal stretch to the widget list
Create a KeyboardRow with the widget list
Add the KeyboardRow to the row list

Create an empty list of widgets
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'up.png'
    the 'callback' function is onClickShift
Append the KeyboardButton to the widgt list
Append a spacer whose width is 5% of the standard height
Create a list of KeyboardButton with the characters in 'ZXCVBNM'
The 'callback' function is onClickChar
Append this list to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'back.png'
    the 'callback' function is onClickBack
Append the KeyboardButton to the widget list
Create a KeyboardRow with the widget list
Add the KeyboardRow to the row list

Create an empty list of widgets
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'numbers.png'
    the 'callback' function is onClickNumbers
Append the KeyboardButton to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with the character ','
The 'callback' function is onClickChar
Append this button to the widget list
Create a KeyboardButton with
    a width 500% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'space.png'
    the 'callback' function is onClickSpace
Create a KeyboardButton with the character '.'
The 'callback' function is onClickChar
Append this button to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'enter.png'
    the 'callback' function is onClickEnter
Append the KeyboardButton to the widget list
Create a KeyboardRow with the widget list
Add the KeyboardRow to the row list

Create a KeyboardView with the row list
Add the KeyboardView to this VirtualKeyboard

#---------------------------------------------------------------
# View 2

Create an empty row list

Create a list of KeyboardButton  with the characters in '1234567890'
The 'callback' function is onClickChar
Create a KeyboardRow with this list
Add the KeyboardRow to the row list

Create a list of KeyboardButton  with the characters in '@#£&_-()=%'
The 'callback' function is onClickChar
Create a KeyboardRow with this list
Add the KeyboardRow to the row list

Create an empty list of widgets
Create a KeyboardButton with
    the standard height
    a text value None
    an icon taken from the graphic 'symbols.png'
    the 'callback' function is onClickSymbols
Append the KeyboardButton to the widgt list
Append a spacer whose width is 5% of the standard height
Create a list of KeyboardButton with the characters in '"*'
Add "'" to the list
Add the characters in ':/!?+' to the list
The 'callback' function for everything in this list is onClickChar
Append this list to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with
    the standard height
    a text value None
    an icon taken from the graphic 'back.png'
    the 'callback' function is onClickBack
Append the KeyboardButton to the widget list
Create a KeyboardRow with the widget list
Add the KeyboardRow to the row list

Create an empty list of widgets
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'letters.png'
    the 'callback' function is onClickLetters
Append the KeyboardButton to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with
    a width 500% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'space.png'
    the 'callback' function is onClickSpace
Create a KeyboardButton with the character '.'
The 'callback' function is onClickChar
Append this button to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'enter.png'
    the 'callback' function is onClickEnter
Append the KeyboardButton to the widget list
Create a KeyboardRow with the widget list
Add the KeyboardRow to the row list

Create a KeyboardView with the row list
Add the KeyboardView to this VirtualKeyboard

#---------------------------------------------------------------
# View 3

Create an empty row list

Create a list of KeyboardButton  with the characters in '$€¥¢©®µ~¿¡'
The 'callback' function is onClickChar
Create a KeyboardRow with this list
Add the KeyboardRow to the row list

Create a list of KeyboardButton  with the characters in '¼½¾[]{}<>^'
The 'callback' function is onClickChar
Create a KeyboardRow with this list
Add the KeyboardRow to the row list

Create an empty list of widgets
Create a KeyboardButton with
    the standard height
    a text value None
    an icon taken from the graphic 'numbers.png'
    the 'callback' function is onClickNumbers
Append the KeyboardButton to the widget list
Append a spacer whose width is 5% of the standard height
Create a list of KeyboardButton with the characters in '`;÷\∣|¬±'
The 'callback' function is onClickChar
Append this list to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with
    the standard height
    a text value None
    an icon taken from the graphic 'back.png'
    the 'callback' function is onClickBack
Append the KeyboardButton to the widget list
Create a KeyboardRow with the widget list
Add the KeyboardRow to the row list

Create an empty list of widgets
Create a KeyboardButton with
    the standard height
    a text value None
    an icon taken from the graphic 'symbols.png'
    the 'callback' function is onClickSymbols
Append the KeyboardButton to the widgt list
Append a spacer whose width is 5% of the standard height
Create a list of KeyboardButton with the characters in '"*'
Add "'" to the list
Add the characters in ':/!?+' to the list
The 'callback' function for everything in this list is onClickChar
Append this list to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with
    the standard height
    a text value None
    an icon taken from the graphic 'back.png'
    the 'callback' function is onClickBack
Append the KeyboardButton to the widget list
Create a KeyboardRow with the widget list
Add the KeyboardRow to the row list

Create an empty list of widgets
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'letters.png'
    the 'callback' function is onClickLetters
Append the KeyboardButton to the widget list
Append a spacer whose width is 5% of the standard height
Create a KeyboardButton with the character ','
The 'callback' function is onClickChar
Append this button to the widget list
Create a KeyboardButton with
    a width 300% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'space.png'
    the 'callback' function is onClickSpace
Create a KeyboardButton with the character '.'
The 'callback' function is onClickChar
Append this button to the widget list
Append a spacer whose width is 5% of the standard height
Create a list of KeyboardButton with the characters in '✕§¶°'
The 'callback' function is onClickChar
Append this list to the widget list
Create a KeyboardButton with
    a width 150% of the standard height
    the standard height
    a text value None
    an icon taken from the graphic 'enter.png'
    the 'callback' function is onClickEnter
Append the KeyboardButton to the widget list
Create a KeyboardRow with the widget list
Add the KeyboardRow to the row list

Create a KeyboardView with the row list
Add the KeyboardView to this VirtualKeyboard

#---------------------------------------------------------------

This is a test program:

Create a window 600 pixels wide and 350 high with background #ccc.
Compute a standard button height value, as 15% of the window height. 
Create a VirtualKeyboard, giving it the computed height
Add the VirtualKeyboard to the window
Show the window

Note: QGraphicsDropShadowEffect is part of QtWidgets, not QtCore

And here are the control key graphics:

Using subnets to extend ESP-Now

Graham Trott — Sat, 19 Apr 2025 16:03:45 +0000

ESP-Now is a lightweight networking protocol that uses only two layers (Physical and Data Link) of the OSI model. By doing so it offers high performance and simple programming.

In a typical configuration, a single hub device maintains an HTTP connection to the system controller, either as a client or a server, and uses ESP-Now to communicate directly with up to 20 other devices. Commands and queries arrive at the hub on the HTTP interface and are routed to the appropriate device. These messages are sent using a call to a library function that takes 2 arguments:

The MAC address of the intended recipient
The payload, which can be up to 200 bytes. (A new version increases this limit but I'll ignore that for the purposes of this article.)

For a small network, the system offers great performance, impressive reliability and easy programming, but it has two fundamental limitations, being the 20 devices as stated above, and the distance from the hub to the furthest device. As with all things wifi, range is an issue. It can be very hard to find a location for a wifi hub where all of the devices to be controlled can see it reliably. Here's view of a hub with 4 connected devices:

The red hatched area is outside the wifi range of the hub, so if new devices are added here they will suffer from poor connections and will consequently be unreliable:

One well-known solution to this is to implement a mesh, but this functionality is not offered as part of the ESP-Now spec. In any case, a mesh is often overkill, since what is usually needed is for the hub to drive more devices over a greater range, not for all the devices to talk to each other in arbitrary ways.

Fortunately, there's a quite simple solution to this problem, which is to allow any device to handle devices on a subnet of its own. The device count and the range of the network both immediately increase dramatically, albeit with a performance hit, but one that is likely to be insignificant for most small control systems:

The way it works is like this. Every device in the system is described by a packet of information, typically a JSON structure, with fields such as the following:

"name" - the unique name of the device in the system
"mac" - the MAC address of the device
"channel" - the wifi channel used
"led" - the pin that drives the device LED
"led-invert" - a Boolean that governs the ON and OFF polarity
"relay" - the pin that drives the device's primary relay
"relay-invert" - a Boolean that governs the ON and OFF polarity
... (etc for other hardware and software features of this device)
"path" - the path to this device

Each device has a JSON file containing its own information, and the central controller holds a file containing all the device structures, indexed by the device names.

The last item in the list is the key to the extended networking. For devices close to the hub, nothing is needed here as messages are sent using the MAC address of the device and the payload. But by placing the MAC address of an intermediate device into the field, that device then becomes the parent of the target device (the one the message is intended for). The message is now sent to the parent (the "path" as above), to be forwarded to our required target device. We prefix the payload with the MAC address of the actual target device and structure it so as to make it easy to decode.

As an example, let's suppose we want to send a command to turn on the device relay. Let's suppose the MAC address of the device is aa:aa:aa:aa:aa:aa and the payload to turn on the relay is the single word ON. If the network is small and the device is close to the hub we can just send it as is, using a function call such as

send(mac, payload)

but if the network is full or the device is physically remote we need to relay the message through another device already in the system, one that is closer to our new device. Let's say the MAC address of this parent device is bb:bb:bb:bb:bb:bb. So we send a message to that device, and we adjust the payload to be

!aa:aa:aa:aa:aa:aa,ON

The function call then becomes (micropython version)

send(parent, f'!{mac},{payload}')

The exclamation mark is there to signal that the payload is to be routed to the device whose MAC address is given, and the comma is just a separator. Needless to say, this strategy does not allow payloads to begin with an exclamation mark, so you might wish to use a different marker.

The code to handle this new message type is remarkably simple. You have to check for the marker, then extract the embedded MAC address and use it to construct a new message to send to the target device. The payload is everything that follows the comma - in this case the original ON - and the reply from the target is simply passed back to your caller. You can see this done in the receive function below.

This technique adds no extra devices to the list of "peers" that are held by any given device, and it can be extended almost indefinitely, by concatenating MAC addresses in the "path" field, such as

bb:bb:bb:bb:bb:bb,cc:cc:cc:cc:cc:cc

which causes the message to be routed through 2 intermediate devices.

I reproduce below the ESP comms class from a Micropython implementation of the above. It relies on a config parameter being supplied during initialization, to provide access to other functions in the system, but mostly it just deals with sending and receiving ESP-Now messages. You will notice that the system holds MAC addresses as human-readable strings, whereas ESP-Now requires formatted binaries, so there's a degree of back-and-forth between the two formats.

import asyncio
from binascii import hexlify,unhexlify
from espnow import ESPNow as E

class ESPComms():

    # Default initializer
    def __init__(self,config):
        self.config=config
        config.setESPComms(self)
        E().active(True)
        self.peers=[]
        print('ESP-Now initialised')

    # Check if a peer is already known
    def checkPeer(self,peer):
        if not peer in self.peers:
            self.peers.append(peer)
            E().add_peer(peer)

    # Send a message to a given MAC address
    async def send(self,mac,espmsg):
        peer=unhexlify(mac.encode())
        self.checkPeer(peer)
        try:
            print(f'Send {espmsg[0:20]}... to {mac}')
            result=E().send(peer,espmsg)
            print(f'Result: {result}')
            if result:
                counter=50
                while counter>0:
                    if E().any():
                        sender,response = E().irecv()
                        if response:
                            print(f'Received response: {response.decode()}')
                            result=response.decode()
                            break
                    await asyncio.sleep(.1)
                    counter-=1
                if counter==0:
                    result='Response timeout'
            else: result='Fail'
        except Exception as e:
            print(e)
            result='Fail'
        return result

    # Handle received messages as they arrive
    # Either deal with them or pass them on
    async def receive(self):
        print('Starting ESPNow receiver on channel',self.config.getChannel())
        while True:
            if E().any():
                peer,msg=E().recv()
                sender=hexlify(peer).decode()
                msg=msg.decode()
                print(f'Message from {sender}: {msg[0:20]}...')
                if msg[0]=='!':
                    comma=msg.index(',')
                    slave=msg[1:comma]
                    msg=msg[comma+1:]
#                    print('Forward to',slave,', msg:',msg)
                    response=await self.send(slave,msg)
                else:
                    response=self.config.getHandler().handleMessage(msg)
                    response=f'{response} {self.getRSS(sender)}'
#                print('Response',response)
                self.checkPeer(peer)
                E().send(peer,response)
            await asyncio.sleep(.1)
            self.config.kickWatchdog()

    # Return the RSS (signal strength) of the received message
    def getRSS(self,mac):
        peer=unhexlify(mac.encode())
        return E().peers_table[peer][0]

DEV Community: Graham Trott

AI writes the code, humans review it — review is the coming skill

Recognition is easier than writing

Why programmers resist

Review is the coming skill

AllSpeak is a first step, not a destination

A working example: Doclets

Why it is easy to customise

Ask your agent

How to enjoy programming in a world of AI

When AI writes the code, what should humans actually read?

The problem with normal code in an AI-first workflow

Two things to fix

Why this matters more for AllSpeak than for Python

Files become packages, not text

What I'd encourage other tool-makers to think about

A small invitation

Postscript

Claude built me a high-level coding system in 4 European languages

Bonjour / Guten Tag / Buongiorno

AI has reprogrammed me

AI Doesn't Need Your Programming Language

The Question Nobody's Asking

The Case for Simpler Languages

Where This Is Heading

AllSpeak: A Working Example

Why AI loves it

Working with AI changes how you think

And Then It Gets Interesting: Any Language

Adding a New Language

What AllSpeak Is Best Suited For

The Workflow

What's Next

The Catch-22 of programming

Becoming a programmer

Programming with an LLM

The crux of the matter

What are our options?

An example

How does this work with AI?

Compilable pseudocode reduces complexity

How does this change the way we work?

New opportunities

Summary

OTA Python updates with ESP-Now

__init__()

handleMessage()

checkFile(()

Channel-hopping on the ESP32-C3 with ESP-Now

__init__()

setupSlaveTasks()

resetCounter()

findMyMaster()

countMissingMessages()

ping()

countMissingMessages()

checkRouterChannel()

ESP-Now master-slave in Micropython

__init__()

closeAP()

addPeer()

send() and receive()

Channel changes

An AI virtual keyboard

Using subnets to extend ESP-Now

`init()`

`handleMessage()`

`checkFile(()`

`init()`

`setupSlaveTasks()`

`resetCounter()`

`findMyMaster()`

`countMissingMessages()`

`ping()`

`countMissingMessages()`

`checkRouterChannel()`

`init()`

`closeAP()`

`addPeer()`

`send()` and `receive()`