DEV Community: Doby Baxter

I Am Not an Archivist: What Careless Automation Asks of Disabled People

Doby Baxter — Mon, 12 Oct 2026 21:39:22 +0000

I'm writing this in a studio that has had no heating since early July.

I have reported it by email, by phone, through a formal complaint form, and to the building's reception. This week, a phone call finally explained why nothing happened: my emails and calls had been going to a team in another city the whole time.

Nobody noticed. Nobody told me. I only found out because I kept chasing.

This piece isn't really about one cold studio. It's about the job that lands on you when a system fails and nobody owns the failure.

The job nobody hired me for

When an organization's software gets something wrong, the work of putting it right rarely stays with the organization. It moves to the person.

You become the archivist, keeping every email, screenshot, reference number and date, because one day you may need to prove what happened.

You become the advocate, writing the complaint, finding the escalation route, and quoting the organization's own policies back to it.

You become the detective, connecting the dots its systems never connect: why this charge, why this name, why this rejection.

And you become the project manager, tracking deadlines across a dozen institutions that never talk to each other.

I have ADHD and autism, and I live with memory difficulties and other health conditions. I cannot do this job reliably on my own. Most people couldn't keep it up for long, and nobody should have to.

Four failures, one shape

The heating that was "logged on the system"

Before that phone call, the most anyone had told me was that my issue was "logged on the system." No reference number, no name, no timeline.

When I tried the out-of-hours number on the wall, it belonged to a separate estates company that looks after the building but not the flats, so they sent me back. The building's own receptionist told me she gets no replies from the company either. The direct number I was finally given shows as invalid on my phone.

Every route pointed somewhere else. The only person who ever owned the problem was me.

The person who doesn't exist

When I moved in, about three years ago, I had already changed my name by deed poll. The company managing the building at the time would not accept it and registered me under my old name.

I complained in writing and in person. Staff at their local office told me to ignore the messages or block them.

Then the building changed hands, and the new company inherited the old record. One day, two property inspectors walked into my studio while I was at my computer in my pajamas. Their records said nobody lived there.

Once, when I was locked out of my flat, the agent on the phone wouldn't help me, because someone else was registered at my address under a different name.

A deposit replacement scheme was about to take its once-a-year fee from me twice. After I canceled the Direct Debit, an automated email warned that I might have to pay twice, because more than one person was on my tenancy.

I live alone. The "other person" is a record nobody corrected.

The emails I had to silence

For about a year and a half, the new company's system sent me automated emails asking me to set up a Direct Debit, often several times a week. I asked many times for them to stop. There was no unsubscribe link.

In the end, I blocked the sender so my main inbox could stay usable for the things that matter. Later, I learned that the same system also sends maintenance updates. To protect myself from the noise, I may have lost the signal.

That trade should never be the user's to make.

The rejection that arrived in a minute

My passport is due for renewal, so I applied online through my home country's service. I was rejected five times. Each rejection arrived about a minute after I submitted, with identical wording and no reason.

Staff on the phone said my biometric data needed updating. I made the long, expensive journey to the consulate in London, and the officer at the counter said my biometric data was valid. Nobody could explain the rejections.

My best guess is that the first rejection left a flag on my record, and that flag rejects every new attempt automatically until a human clears it. But that is only a guess, because no one has looked.

The pattern

Put those four stories side by side, and the same shape appears:

A system holds a record or makes a decision.
The record is wrong, or the decision comes with no reason.
Nobody inside the organization owns the error.
The person is left to notice it, prove it and chase it, often while being treated as the problem.

None of these failures is complicated to fix. Route a report to the right team. Update a name when a deed poll arrives. Add an unsubscribe link. Attach a reason to a rejection.

Each fix is small. What makes the failures heavy is that they never end, and they never stay inside one institution.

There's a name for this

Researchers call it administrative burden. Donald Moynihan, Pamela Herd and Hope Harvey describe it as three kinds of cost that people carry when they deal with institutions:

Learning costs: working out what is required of you.
Compliance costs: the forms, documents, calls and waiting.
Psychological costs: the stress, frustration and stigma.

Their work makes two points that match my life closely. These costs fall unevenly, and they land hardest on people with the least time, money and capacity to absorb them. And how much burden a person carries is often a matter of choice, not accident, even when nobody sits down and decides it.

Disability multiplies all three costs. If your memory is unreliable, keeping records is harder. If phone calls are difficult, every escalation costs more. If you are already exhausted, each new failure arrives when you have the least to give.

It isn't just me

At national scale, the same shape has caused enormous harm.

In the UK, the Post Office prosecuted more than 700 subpostmasters between 1999 and 2015, using figures from its Horizon accounting system that showed money missing. In 2019, the High Court found that Horizon contained bugs, errors and defects capable of causing those shortfalls. In 2024, new laws quashed the convictions. For years, people were told the computer was right and they were wrong.

In Australia, the Robodebt scheme ran from 2015 to 2019. It averaged people's annual income to calculate debts, and it raised about 1.73 billion Australian dollars in unlawful debts against more than 400,000 people. The job of proving whether a debt existed moved onto the people receiving the letters, often with income evidence from years before. The Royal Commission called it "a crude and cruel mechanism, neither fair nor legal."

In the Netherlands, the tax authority wrongly accused tens of thousands of parents of childcare benefit fraud and demanded repayments that drove families into hardship. Dual nationality was used as one of its risk indicators. The government resigned over it in January 2021, and more than 33,000 people have since been officially recognized as victims.

Each case has the same core. The system's record is treated as the truth, and the person has to prove otherwise, with documents nobody told them to keep.

What it costs

The cost I feel most is not the hours. It's the vigilance.

I find myself trying to predict where the next failure will come from, so I can keep the right records before I need them. When a failure does arrive, I often don't have the capacity to act on it, or the document I need is long gone.

It is humiliating to explain the same thing again and again to people who have the records in front of them. It is heartbreaking to be treated as an inconvenience for asking for something basic, like heat in October.

And it accumulates. Housing, banking, benefits, government, healthcare: every system I am registered with is another place where a wrong record can sit for years, waiting for me to find it.

The only reason I can keep up at all is that I use AI tools to hold the threads for me: drafting the complaint, tracking the deadlines, remembering what I told whom. That is an accessibility tool, the same as glasses. But it shouldn't be the price of being treated fairly.

I am not an archivist

I am not an archivist. I'm not a lawyer or a detective, either. I'm a person who needs heat, a correct name on a record, and an inbox I can use.

I need to be able to live my life without preparing a defense for every ordinary interaction.

When software fails, someone carries the cost. Right now, it is usually the person with the least capacity to carry it. The responsibility belongs with the people who build, buy and run these systems.

Software should never fail a person in silence. And it should never leave that person to clean up after it alone.

Sources

Moynihan, D., Herd, P. and Harvey, H. (2015). Administrative Burden: Learning, Psychological, and Compliance Costs in Citizen-State Interactions. Journal of Public Administration Research and Theory, 25(1).
Herd, P. and Moynihan, D. (2018). Administrative Burden: Policymaking by Other Means. Russell Sage Foundation.
Bates v Post Office Ltd (No 6: Horizon Issues) [2019] EWHC 3408 (QB).
Post Office (Horizon System) Offences Act 2024.
Royal Commission into the Robodebt Scheme (final report, July 2023).
Dutch childcare benefits scandal.
DutchNews (2024). Over 33,000 families acknowledged as benefit scandal victims.

A Label Is Not a Review: Following One Closed Merge Request

Doby Baxter — Tue, 06 Oct 2026 19:44:18 +0000

This is a follow-up to two earlier pieces: Why This Time Is Different: Following the Chain of Consequences and Learning to Build Without a Ladder.

In the first one, I listed the assumptions that let the tech industry recover from past downturns. The last one was the easiest to miss: there was a way in. Someone outside the industry could still reach a person who would let them in, and open source was one of the places where that still worked. I wrote about how automated gates on both sides are closing that door.

This week I found an example that shows the door can close without any automation at all. A person closed it, with a quick look and one word. Human judgment is still one of the biggest gates in front of people who already have the skills, and a quick human check can fail in exactly the same way an automated filter does.

So I want to follow this one the same way I followed the chain in that article: one link at a time, looking at what each step actually cost.

I'm not naming the project or the people involved. Its maintainers do real, careful work, much of it for the public good, and nothing here is meant as a pile-on. I'll call the project SkyRelay. It's an open-source network of volunteer satellite ground stations, the kind of project I love, and one I was seriously considering contributing to.

What happened

At the end of February 2026, a contributor opened a merge request to speed up one of SkyRelay's busiest pages. The page was slow to load, and the change went after the reasons why.

A maintainer marked it as a draft. The comment said that a quick check showed signs the merge request was AI-produced, and that it was being set aside "in order to avoid spending review time for AI nonsense."

To be fair to the maintainer, the comment didn't stop there. It apologized in case the guess was wrong, and asked for three things: describe the planned optimization on the related issue, make sure nothing that already works stops working, and run the pipeline checks locally first.

The next day, the contributor closed the merge request. They also closed a second, much smaller fix they had opened the same day, which nobody had raised any concern about. They haven't opened another merge request in the project since.

What was actually in the change

I wanted to know whether the label fit, so I went through the diff file by file with my AI assistant.

It was a real fix for a real problem. The page got its data from a list of satellites that made a separate database query for every single satellite, just to check one flag. The change replaced those thousands of queries with one. It also changed a large table so it loaded its rows on demand, instead of building every row into the page up front.

It also had noise around it, the kind that needs tidying before anything is merged:

A code style rule was switched off, instead of the new code being changed to follow it.
A few package lock entries appeared that had nothing to do with the change.
The pipeline failed.
It changed how the page loads without that approach being agreed on the issue first.

All of that deserves a review comment. None of it is unusual. It's what a merge request looks like when someone is working fast, on their own machine, without asking first. A reviewer could reasonably have said "this needs work before it can be merged." That is a very different sentence from "this is nonsense."

Then I found something I hadn't expected. This wasn't a newcomer at all. The same person had more than twenty merged contributions across the project's organization a few years earlier, including an earlier speed-up of this very page. A quick check didn't show that. Only a closer look did.

Mine had signs too

I recognized that merge request, because I've sent one like it.

That same week, I was finishing a documentation contribution to GitLab. I was teaching myself Git from the command line, and I was working on three issues at the same time. Changes from my other issues kept slipping into the merge request. I couldn't see it from the terminal. It only showed up in the merge request's diff, after I had already pushed. It happened three pushes in a row.

On top of that, my editor, Zed, quietly reformatted lines I had never touched whenever I saved a documentation file. I didn't see that coming at all, and I had to work out on my own where the extra changes were coming from.

From a quick check, my merge request had signs too: unrelated files, formatting churn, a messy history. My reviewer looked past them. He stayed kind and waited for my final version, even though I could tell his patience was wearing thin, and I don't blame him for that. In the end I closed the merge request myself and opened a brand-new one with only the change I meant to make. It was merged a few days later and shipped in GitLab 18.10.

The only real difference between my story and the SkyRelay contributor's is what the reviewer did with the signs. Mine read them as a person still learning. Theirs read them as a reason to stop reading.

When the door stays open

A few weeks later, I had the opposite experience, in a much harder spot.

I was adding Kroki support to the GitLab Terraform provider, so teams who manage GitLab as code could switch on diagram rendering in their configuration instead of by hand. The provider is written in Go, a language I was still finding my feet in, and it took me three merge requests to get it right.

The hardest part wasn't the code. My laptop at the time had 8 GB of RAM. Docker crashed it, WSL wouldn't start, and the project expects its documentation to be regenerated by a tool, not written by hand. I tried writing the docs manually anyway, and the pipeline kept failing, as it should.

So I said exactly that, in the merge request. I explained my machine's limits, said I believed the implementation itself was complete, and asked whether someone could run the generation step for me or suggest another way.

They did both. One maintainer explained that the docs step didn't need Docker at all, and pointed me to the command contributors are meant to run before opening a merge request. Another ran it for me, pushed the result, and suggested a remote development environment for next time. Later, when my diffs looked odd, they asked me to run Go's formatter, because my tabs and spaces were mixed up. Formatting again!

With that help, I fixed a state drift problem that the acceptance tests showed, added a small safety check I noticed along the way, and traced the last pipeline failure to a mismatched file name in the CI setup rather than my change. In April 2026 it went onto the merge train and was merged. The request for that feature had been open for more than two years.

I was so happy that I drew Kroki as a little crocodile riding the merge train, and shared it in the thread. Both of my Kroki drawings are in my writeup of the contribution. And someone who had been waiting for the feature thanked me for my persistence and said they were looking forward to the release. I still smile about that.

Nothing about that merge request was tidy. It took three attempts, it had a failing pipeline and mixed-up formatting, and I said openly that I couldn't run the project's own tooling. From a quick check, it had more signs than either of the other merge requests in this article. What it also had was transparency in both directions: I was honest about my limits, and the maintainers were honest about what I needed to do. That's all it took.

That is the nature of this work. Technology moves fast, tools change, environments fail, and troubleshooting takes time, whether you started last month or twenty years ago. Most of software engineering is exactly this: troubleshooting, debugging, and trying again. A messy merge request isn't evidence that someone doesn't belong. It's evidence that they're doing the job.

And a reviewer can't see who is on the other side of a merge request. It might be a newcomer, someone with years of history in the project, someone on an 8 GB laptop, or someone learning a new language or a new tool. That's exactly why the change is the right thing to look at. Nothing about what happened in SkyRelay was personal to the contributor. The label is what made it personal.

The same chain, in one merge request

Here is how I see the steps link together.

A quick check stands in for a review. Maintainers are flooded, and a fast filter feels like self-defense. But a quick check is a classifier, and like any classifier it has false positives. The signs it looks for (noise, unrelated files, a failing pipeline) are exactly the signs of someone learning, someone in a hurry, someone on limited hardware, or someone whose tools did something they didn't expect.

The label lands on the person, not the change. "This needs work" tells you what to fix. "AI nonsense" tells you what someone thinks of you. Only the first one gives you anything to act on.

The person leaves, quietly. Nobody argued and nobody complained. The merge request was simply closed, and nothing anywhere records that a working fix walked out the door. In the first article I called this Link 6: failure goes quiet. It's the same silence, just in a review thread instead of on a dashboard.

The problem stays, and costs more later. In October 2026, seven months on, another maintainer opened a new merge request for the same page's slow loading. It's careful, well-measured work, and I'm glad it's happening. One of the causes it names is that same per-satellite query, and the part it doesn't cover yet is listed as a follow-up, measured at over nine seconds on production-sized data. The closed merge request had already offered an answer to that query. A review would have been a chance to learn from it, or to explain why it didn't fit. That's Link 7: the correction comes late, and it costs more.

The way in narrows. Every newcomer who reads that thread learns something before they write a single line: the first response here might be a label. I know, because I read it, and I decided not to contribute. That's assumption F failing, one person at a time.

Notice that no step in this chain needed bad intentions. Each one makes sense on its own. That's exactly why it's worth writing down.

"No capacity" is a complete answer

I understand where maintainers are. Many of them work unpaid, or look after far more code than any one person should. Reviewing a large change properly takes real time, and nobody is owed that time.

So here is what I'd ask for instead, and it's small: if there isn't capacity to review, say that. It's honest, it's kind, and it's a complete answer. Something like:

We don't have review capacity for a change this size right now. Could you describe the plan on the issue first, so we can agree on the approach before you spend more time on it?

That reply takes the same few seconds as a label. It keeps the person, keeps the fix, and keeps the door open. And the second half of the SkyRelay comment was already most of the way there. If those three requests had been the whole comment, I don't think this article would exist.

Since then, SkyRelay has published an AI policy for contributors. It says plainly that the project can't police how a merge request was written, so it doesn't try. It allows AI-assisted contributions, as long as a person understands the change and takes full responsibility for it, and it's firm about repeated low-quality submissions, which is fair. I think that's the right answer. It moves the question from "how was this written?" to "do you understand it, and do you stand behind it?", and the second question is one a person can actually answer. A first response built on that question would have gone very differently.

What a review gives that a label can't

In Learning to Build Without a Ladder, I wrote that open source still works as an apprenticeship. You send something small, someone reviews it and tells you plainly what is wrong, and you improve. For a lot of us, that loop is how we became engineers after the junior roles disappeared.

A label skips the one step that makes the loop work. A review tells you the truth about your code. A label tells you someone's guess about you.

For people who learn the way I do, self-taught, neurodivergent, building our own apprenticeship in public, early merge requests are often noisy. That noise is what learning looks like from the outside. If the first response to it is a label, the people who most need that apprenticeship are the first ones it turns away.

I also wrote that judgment is the skill that matters now: can a person understand, test, and improve what a tool produced. I still believe that, and I've realized it applies to reviewers as much as to contributors. What a reviewer can answer is whether the change works, and whether the person behind it can explain it. Whether a tool was involved is something nobody can see from a diff, and it was never the most useful question to ask.

Closing

I build my work around one line: software should never fail a person in silence. A merge request closed under a label is a quiet failure of exactly that kind. Nobody sees an error message. A person just stops coming back, and the problem they solved waits seven months for someone else.

I've seen both sides of that door this year. When a maintainer reads the change and asks what the person needs, a feature people waited two years for gets merged. When a label comes first, a working fix walks away.

Reviewing the change instead of the person isn't glamorous, and it isn't free. But it's the cheapest way I know to keep the door open, for the next contributor, and for the people who will look after these projects once today's maintainers step back.

Built to Stop Bots, Built to Stop Me: How CAPTCHAs Fail the Humans They Claim to Protect

Doby Baxter — Mon, 05 Oct 2026 18:21:53 +0000

The gate I could not pass

I was invited to join a community. Between me and the people who invited me stood one question: are you human?

I am. I could not prove it. The images moved faster than I could track, and I failed again and again until I gave up and emailed the organizer instead.

I build validation systems for a living, so this stung twice. A validator built to stop software had rejected a real person. And it was far from the first time.

What failing looks like

As an autistic person with ADHD and sensory processing sensitivities, a challenge built on rapidly changing images is not a mild annoyance. It is a task designed around exactly the kind of processing I find hardest.

I have failed every kind of CAPTCHA, honestly and repeatedly:

Distorted text. Sometimes I simply cannot tell what the word is meant to be. No amount of staring helps.
Image grids. I select every traffic light I can see, and it is never what the system wants. Does a light cut off at the tile edge count? Sometimes yes, sometimes no, and nothing tells you the rule.
Rotating and moving puzzles. Hard to track, and sometimes rejected even when my answer is correct.
Invisible scoring. When it decides I look suspicious, it sends me straight back to the puzzles above.

CAPTCHAs have stopped me more times than I can count. They have never once stopped a bot on my behalf.

Machines now pass more easily than people

In 2023, UC Irvine researchers had 1,400 people solve 14,000 real CAPTCHAs (USENIX Security 2023). Bots beat humans on both speed and accuracy across many types. On distorted text, bots were close to 100% accurate in under a second, while humans managed 50% to 84% and took up to 15 seconds (coverage).

In 2024, ETH Zurich researchers solved 100% of Google's reCAPTCHAv2 image challenges with off-the-shelf object-detection models (Breaking reCAPTCHAv2). What really decided the outcome was cookies and browsing history, not the puzzle.

Attackers who do not want to build a solver can simply pay CAPTCHA farms, where low-paid workers solve challenges at scale. So the bot gets in. The paid stranger gets in. The person who just wants to join may not.

A validator with a broken oracle

Any validator makes two kinds of mistake: letting bad input through, and rejecting good input. A CAPTCHA now does both badly. It is weak against bots and strict against people who see, move, or process differently, including blind and low-vision users, people with motor disabilities, and neurodivergent people like me.

The W3C has warned about this since 2005 in Inaccessibility of CAPTCHA, and WCAG 2.2 criterion 3.3.8 says authentication should not depend on a puzzle without an alternative. A timed, moving puzzle is far from that spirit.

That is why it feels dehumanizing. The system is asked to recognize a human, fails to recognize a real one, and then tells them they are the problem.

Better gates

The fix is to stop asking humans to out-perform machines:

Rate limiting per IP, device, and time window, since most abuse is about volume.
Proof of work that asks the browser, not the person, to spend computation.
Email or magic-link verification instead of perception tests.
Honeypot fields that humans never see and naive bots fill in.
A human fallback path, a clear "I can't complete this" route to a real person.

Bolt-on fixes like hCaptcha's accessibility cookie help some people, but they push extra work onto the person already locked out.

Question the test

I did get through in the end, by emailing a person. That is the lesson. A bot can now prove it is human more easily than I can. That should not make anyone question my humanity. It should make us question the test.

Sources

Searles et al., An Empirical Study & Evaluation of Modern CAPTCHAs, USENIX Security 2023
Tech Xplore, Bots are better at CAPTCHA than humans, researchers find, August 2023
Plesner, Vontobel and Wattenhofer, Breaking reCAPTCHAv2, ETH Zurich, 2024
W3C, Inaccessibility of CAPTCHA
W3C, Understanding SC 3.3.8: Accessible Authentication (Minimum)
hCaptcha, Accessibility: Accommodation Options and Support Path

Thank You, Every Time: What the Pyxel Team at ESA Taught Me That No Employer Ever Did

Doby Baxter — Thu, 01 Oct 2026 23:24:22 +0000

Every time I sent the Pyxel team something, they said thank you.

Not once at the end, as a formality. Every time. A fix, a new version of the tool I was building, an answer to a question: thank you. I want to write about that, because in all my years of working and applying for work, no employer ever thanked me for my work, and I didn't know how much I needed it until it happened.

This isn't a technical post. I've written about what I built for Pyxel before. This one is about how it felt to build it, and what it taught me.

How it started

Pyxel is an open-source detector simulation framework developed by a team at the European Space Agency. It's used by ESA, the European Southern Observatory and institutes around the world. I started the way anyone can start on an open-source project: I contributed on GitLab, and then I emailed the maintainer.

I expected a short reply, maybe. What I got was an invitation to meet the whole team online. I introduced myself, and then each of them introduced themselves to me.

That detail matters to me more than almost anything else in this story. It wasn't an interview, where one side asks the questions and the other side performs. It was a team meeting a new person and treating that person as someone worth knowing.

They were grateful from the very first conversation. I hadn't proven anything yet. They were simply glad someone wanted to help.

What working together looked like

I was building Pyxel Config Lab, a tool that helps people write and check Pyxel configurations without fighting the file format. The team wrote me extensive feedback on it. Not a quick "looks good", and not a list of everything wrong handed down from above. Careful, detailed notes from people who had clearly sat down with the tool and used it.

Good feedback is a form of care. It says: I took your work seriously enough to spend my time on it.

So I kept working. I sent the next version, read the next round of notes, and improved it again. Nobody told me the iterations were a waste of time. Iteration was the point. That's how good software gets made, and they knew it.

And every time, they thanked me.

I was included. I was part of their work, not a ticket to be closed. They were respectful to me as a person and as an engineer, and open to ideas that didn't start with them.

The tool shipped alongside the official Pyxel 2.14 release. It was later named in the team's peer-reviewed Pyxel 3.0 paper (Proc. SPIE 14157), which records that I led the development of Pyxel's new GUI. The maintainer also wrote me a reference, with a line in it I treasure:

"Doby Baxter joined the Pyxel project on his own initiative and quickly became a key contributor."

Those are the achievements, and I'm proud of them. But they aren't what I treasure most. What I treasure is how it felt along the way. To this day, it's the best collaboration I've ever had.

The other side

Here is the comparison, as plainly as I can put it.

At Pyxel, I emailed one person and was invited to meet the whole team. In job applications, I mostly got automated rejections, or no reply at all, often before a person had read a word.
At Pyxel, the team introduced themselves to me. In hiring, I was the only one expected to explain myself.
At Pyxel, my work got detailed feedback and a thank you. From employers, it got silence.
At Pyxel, iteration was welcome. With employers, anything beyond exactly what I'd been told to do wasn't seen as care or initiative. It was a problem.
At Pyxel, I was included. Elsewhere, I was replaceable, and so was everyone around me.
At Pyxel, I was valued for what I brought. Elsewhere, some employers were interested in my skills right up until they reached the part-time hours and adjustments I need. One role ended because adjustments that had been agreed were never put in place.

I could bring the same passion I brought to Pyxel to an employer, and it would be dismissed.

Same person. Same passion. Same standard of work. Two completely different outcomes. The difference was never me. It was whether the people on the other side were open-minded or closed-minded.

The opposite of competition

Corporate work taught me that work is a competition: for roles, for credit, for being seen as the one who did it.

The Pyxel team taught me the opposite. Respect. Mutual care. Collaboration in the real sense of the word, where everyone's work makes everyone else's better, and people say so out loud.

None of that cost them anything. Saying thank you is free. Introducing yourself is free. Reading someone's work carefully costs an hour. And it changed everything for me.

Why it's the reason I kept going

I've stopped applying for jobs. That decision is made, and I'm at peace with it.

But giving up on employment and giving up on engineering are two very different things, and the Pyxel team is the difference between them. Without them, every signal I'd received would have said the same thing: your work doesn't matter to anyone. With them, I have proof of the opposite. Good people exist. Open-minded people exist. People who will appreciate careful work, say so, and treat the person who made it with respect.

I don't believe that because I hope it. I believe it because I've lived it.

What I carry into my own work

That belief is what my business is built on. I now work for myself, doing reliability reviews and engineering for small businesses, and the clients I hope to work with are people like the Pyxel team: open, respectful, and glad when something is done with care.

It goes both ways. I try to work the way they worked with me. Thank people for their time. Give feedback that shows I actually read the thing. Explain, and never talk down. Treat someone's system, and someone's work, as theirs.

Thank you

So, to the Pyxel team at ESA: thank you. For the welcome, the feedback, the patience, and every single thank you. You didn't just help me build a tool. You showed me what working together is supposed to feel like, and you gave me a reason to keep going. I hope everyone gets to work with people like you at least once.

Why This Time Is Different: Following the Chain of Consequences

Doby Baxter — Tue, 29 Sep 2026 23:49:34 +0000

I have been thinking a lot about where software engineering is heading, and I keep arriving at the same conclusion: this time is different.

I know how that sounds. Whenever people worry about the tech industry, the usual reassurance is that we have been here before. There was the dot-com crash, then the financial crisis, and both times the industry recovered and came back bigger.

I do not think that reassurance holds anymore, and I want to show why rather than just say it. When I want to rely on a system, I list what it depends on and check whether each dependency still holds. So that is how I approach this. First I describe how I see past recoveries working, then I follow what is happening now one link at a time, and look at which of those dependencies are still in place.

How the old recovery loop worked

The way I see it, past downturns followed a recognizable sequence:

Demand fell, or money got expensive.
Companies reduced staff to match.
The people who left kept their skills, and many stayed close to the industry.
Demand returned.
Companies rehired, and because the work still needed juniors, juniors were trained again.

It was painful, but it was a loop, and loops correct themselves. For this one to close, four things had to be true:

A. The cut was about demand, not about the work. The jobs were paused, not retired. When demand came back, the roles came back.
B. Knowledge survived the cut. It lived in people who could be rehired, or who could teach.
C. The training pipeline restarted. Seniors taught juniors on real work, because real work still had to be done by people.
D. Failure was loud. When a company cut too deep, something visibly stopped working, and that signal reached the people who make budget decisions.

Underneath all four sits a quieter fifth assumption:

E. Change moved at human speed. Systems changed about as fast as people could understand the changes.

And a sixth, about the people outside the loop, which is easy to miss because it held for so long:

F. There was a way in. Someone outside the industry could still reach a person who would let them in: an entry-level role, an education that led to one, a maintainer with time to mentor.

Now the chain. Each link below is a decision or a consequence, and each one touches at least one of these assumptions.

Link 1: The cut is framed as substitution, not demand

Some companies now explain workforce reductions with a new reason. Not "demand has fallen", but "this work will be done by AI."

That changes what the cut means. A demand cut carries an implicit plan to rehire when demand returns. A substitution cut carries the opposite plan: the role is considered finished. There is no condition under which it comes back, because the reasoning never depended on demand in the first place.

Consequence: the trigger that used to reopen roles is gone. Assumption A no longer holds.

Link 2: Substitution starts with the entry-level work

Which tasks are easiest to hand to an AI tool? Well-defined ones. Boilerplate, small fixes, writing tests, updating documentation, triaging tickets, first drafts of configuration.

Those are exactly the tasks juniors used to learn on. They were never only output. They were the training ground: small enough to be safe, real enough to teach how the whole system fits together.

Nobody has to decide to stop training people for training to stop. It is enough to automate the work that the training happened inside.

Consequence: the apprenticeship layer thins out as a side effect. Assumption C no longer holds.

Link 3: Knowledge leaves, and it was never written down

Every long-lived system carries knowledge that is not in the code. Someone knows that an odd-looking setting is deliberate. Someone remembers the incident that explains why a particular validation exists. Someone knows which customer workflow cannot tolerate a certain kind of change.

That knowledge is part of the system. It just is not stored anywhere a tool can read.

In a demand cut, that knowledge sat in people who could be hired back. In a substitution cut, fewer seniors remain, no juniors are absorbing what they know, and the tools that replaced them can only read what was written. What was never written is simply gone.

Consequence: the system now encodes more about itself, in behavior nobody can explain, than its operators know about it. Assumption B weakens sharply.

Link 4: The rate of change goes up

Automation is very good at producing change. An agent can open more pull requests, generate more configuration and apply more fixes in a day than a small team could in a week.

So at the same moment that understanding of the system is shrinking (Links 2 and 3), the amount of change flowing into it is growing. The ratio of changes to people who understand those changes moves in the wrong direction from both ends.

Consequence: systems start changing faster than anyone can follow. Assumption E no longer holds.

Link 5: Errors travel instead of stopping

This is the technical heart of the chain.

When traditional software fails, it usually fails in a recognizable way. It throws an exception, crashes, times out, or returns something malformed that a type check or a schema rejects. The failure stops at a boundary.

A language model fails differently. Its wrong answers are well-formed, confident and plausible. They have the right shape, so any check that only looks at shape lets them through.

Now put several automated steps in a row. Step one makes a small contextual mistake. Step two treats step one's output as fact, because it looks like fact. Step three builds on step two. By the end, a misunderstanding has become state: records written, decisions taken, configuration applied.

Distributed systems have always had cascading failures. What is new is a participant whose mistakes look exactly like its successes.

Consequence: a small error in context becomes a system-wide error in state, and nothing along the way objects.

Link 6: Failure goes quiet

Put Links 3, 4 and 5 together.

Fewer people know what correct looks like. Change arrives faster than they can review it. And the component producing the errors makes them look correct.

The result is not an outage. Outages are loud, and loud is useful: an outage is a signal that travels all the way up to whoever controls the budget. The result is drift. A record that is slightly wrong. A customer who is quietly mis-served and leaves without saying why. A report that is off by an amount nobody thinks to check.

From the outside, the organization looks fine. The dashboards are green. So the conclusion drawn is that the cuts worked.

Consequence: the signal that used to tell a company it had cut too deep never arrives. Assumption D no longer holds.

To me, this is the most important link. The old recovery loop never depended on companies being wise. It depended on failure being visible. Take away visibility and the loop has nothing to respond to.

Link 7: The correction comes late, and it costs more

Drift does surface eventually. A regulator asks a question, an audit finds numbers that do not reconcile, or a customer raises something that cannot be ignored.

At that point the organization needs people who understand the system. The ones who did have moved on. The juniors who would have become those people were never hired, and it takes years to grow an engineer who can reason about a system end to end. That capability cannot be bought back quickly, and what can be brought in from outside comes at a premium.

So the correction is delayed twice: once by the time it takes a silent failure to become visible, and again by the time it takes to rebuild the skills to fix it.

Consequence: the recovery, when it comes, is slower and more expensive than the savings that started the chain.

Link 8: Automation answers automation

Go back to Links 1 and 2, and look at them from outside the industry.

The roles people used to enter through are being retired. Graduates finish degrees that no longer lead anywhere in particular. People who were laid off are looking at the same shrinking list. The old promise, that a good education and real skills lead to a stable career, no longer holds for a great many people who did everything it asked.

And the advice they all hear is the same: apply widely, and build experience in open source.

Meanwhile, the gates themselves have been automated. Applications are filtered by software before a person sees them. Many public services decide by form logic, with nobody to explain a rejection. As a disabled person I have met many gates like that, from government forms to CAPTCHAs, and I know how much each attempt costs when there is no person to reach.

So people respond in the only way that scales: with automation of their own. Applications are generated and sent everywhere. Pull requests are generated and opened everywhere. Most of this is not malicious. It is a reasonable response to a gate nobody can talk to.

Then the other side responds in kind. One HR person, now doing the work of a whole department, cannot read a thousand generated applications, so the screening becomes more automated. A volunteer maintainer, often doing the work of ten people for free, cannot review a flood of generated pull requests by hand, so review gets AI help too.

Several open source projects now say outright that they cannot tell how a contribution was written. What they ask for instead is a person who understands the change and stands behind it.

pyOpenSci's write-up of PyCon US 2026 describes the same pressure from the maintainers' side: reviewer burden, burnout, and contributor pipelines under strain. Amanda Casari's closing keynote, citing Charity Majors, put it in one line: "Disposable code is here to stay, but durable code is what runs the world."

I agree with both halves. Disposable code is not the problem. The problem is that durable code needs people who understand it, and this loop wears out the people who do while making it harder for new ones to get in.

Each step makes sense on its own. Together they form a loop that nobody chose and nobody wins: the more each side automates, the less either side reaches a person.

What is new here is the timing. In earlier downturns, someone shut out of one industry usually had another way in: a different sector that was hiring, a qualification that still led to work, an entry-level role somewhere else. This time the same pressures are arriving in every sector and in every country at once, so there is nowhere obvious to wait it out.

Consequence: the doors that used to let new people in now sit behind automation on both sides, and the human contact that made them work is disappearing. Assumption F no longer holds.

The chain at a glance

Assumption the old loop relied on	Past downturns	Now
A. Cuts follow demand, so roles return	Largely held	Roles framed as retired
B. Knowledge survives in people	Largely held	Leaves, and tools cannot read what was never written
C. Training restarts	Held, after a dip	The training ground itself is automated
D. Failure is loud	Largely held	Plausible errors produce drift, not outages
E. Change moves at human speed	Held	Change outpaces understanding
F. There is a way in that reaches a person	Largely held	Gates automated on both sides

So when someone tells me "we have been here before," this is my answer. In earlier downturns, the thing that shrank was demand. The capability to do the work stayed intact, waiting for demand to return. This time the capability itself is being taken apart, and the mechanism that would normally tell us to rebuild it is going quiet at the same time. Even the way back in, for the people who could help rebuild it, now runs through automated gates.

What would prove me wrong

This is my opinion, and I would rather name where it could be wrong than pretend it is certain. Here is where I could be:

If organizations write down their implicit knowledge, Link 3 weakens considerably, and AI tools get the context they currently lack.
If companies deliberately keep hiring juniors and give them meaningful work, Link 2 no longer follows from Link 1.
If failures in AI-assisted systems are made visible by design, Link 6 does not happen, and the old feedback loop returns.
If automated gates explain themselves, with a reason a person can act on and a route to a human when the gate cannot help, Link 8 loses most of its pull. People mostly turn to automation when nothing answers them.

Notice something about that list. None of it depends on AI getting smarter. Every item is a decision about the system around the AI. That is the part I find genuinely hopeful.

Where engineers can repair the chain

Every link above is something engineering already knows how to address. None of it is glamorous, and all of it matters more now than it did before.

Keep people learning inside the loop (Link 2). Reviewing AI output is real engineering work, and it teaches. A junior who reviews each change an agent proposes, with a senior reviewing that review, can learn a system faster than one who spent a year writing boilerplate.

Write down the why (Link 3). Decision records, runbooks, and comments that explain intent rather than restate the code. Written context outlives the person who held it, and it has a second benefit: it is exactly the context an AI tool needs to stop making suggestions that are locally reasonable and globally wrong.

Put deterministic boundaries around probabilistic parts (Links 4 and 5). Validate meaning, not only shape. Run preflight checks before a change is applied. Keep human approval for consequential actions: production infrastructure, financial records, anything a person relies on. The architecture should always know the difference between "the AI suggested this" and "the system has verified this is safe to do." Those are two completely different statements.

Make failure loud again (Link 6). Every failure should produce a signal a person can read and act on: a clear message, a logged reason, an alert that reaches someone. This is the standard I build my own work around. I call it No Silent Failure, and it comes down to one line: software should never fail a person in silence.

Keep a person reachable (Link 8). A rejection with no reason is a silent failure too, just one that lands on a person. Every automated gate, whether it screens applications, forms or pull requests, should say why it said no and offer a route to a human when it cannot help. Open source projects are already showing one way to do this: a published contribution policy that says clearly what is welcome tells people how to reach a reviewer, instead of leaving them to guess.

Closing

AI is often described as a force arriving from outside and changing everything it touches. I think it is closer to a mirror with an amplifier attached. Give it a well-run organization, with good tests, written context, sensible permissions and careful review, and it amplifies all of that. Give it an organization reducing costs faster than it can understand its own systems, and it amplifies that instead.

This time is different, but not because the technology is so much smarter. It is different because the loop that used to correct our mistakes depended on four things: people who understood the systems, a pipeline that produced more of them, failures loud enough to notice, and a way in that reached a person. The current path is removing all four at once.

The good news is that each of those is something we know how to build. It is careful, unglamorous work, and I think it is the most important engineering work of the next few years.

Odoo 19 Quietly Drops Your _sql_constraints: How to Find Them Before Your Data Does

Doby Baxter — Sun, 27 Sep 2026 14:00:57 +0000

Odoo 19 changed how a model declares a database constraint, and it made the change quietly. A module that still uses _sql_constraints keeps installing, keeps updating and keeps passing its tests. The only sign is one warning in the server log, and the rule the module declared is no longer enforced by anything.

That is the kind of failure I care most about: nothing breaks on the day, and the cost turns up months later as duplicate records nobody can explain. This post walks through what the 19.0 source does with the old attribute, what happens to a constraint that already existed before the upgrade, and how to check your own modules and database.

This article was first published on my site.

What changed

Up to Odoo 18, a model declared its SQL constraints as a list of tuples:

class TradeAccount(models.Model):
    _name = "trade.account"

    reference = fields.Char(required=True)

    _sql_constraints = [
        ("reference_unique", "UNIQUE(reference)", "Trade account references must be unique."),
    ]

In 18.0 there is no other way to write it. Odoo's own 18.0 core declares _sql_constraints in 174 files and has no models.Constraint anywhere, so nearly every custom module written before 19 uses the old form.

Odoo 19 replaces the list with declarations on the class itself: models.Constraint, models.Index and models.UniqueIndex.

class TradeAccount(models.Model):
    _name = "trade.account"

    reference = fields.Char(required=True)

    _reference_unique = models.Constraint(
        "UNIQUE(reference)",
        "Trade account references must be unique.",
    )

What Odoo 19 does with the old attribute

When 19.0 builds a model class and finds _sql_constraints on it, it logs this and carries on (odoo/orm/model_classes.py):

Model attribute '_sql_constraints' is no longer supported, please define models.Constraint on the model.

It does not convert the list. Constraints are now applied from the model's table objects, which are the models.Constraint and models.Index declarations, and nothing reads _sql_constraints any more. For a module written for 19 that still uses the old form, the constraint is simply never created.

On an upgraded database, the update removes it

It is reasonable to hope that a database upgraded from 18 keeps the constraints it already had. Reading the 19.0 source, a module update removes them instead:

At the end of loading, Odoo reflects each model's table objects into ir.model.constraint and marks their external ids as loaded (_reflect_model in ir_model.py). A constraint declared only in _sql_constraints is not a table object, so its external id is never marked.
ir.model.data._process_end then deletes whatever the updated module no longer provides, and a constraint whose external id was not loaded counts as no longer provided.
Deleting an ir.model.constraint record runs ALTER TABLE ... DROP CONSTRAINT and logs Dropped CONSTRAINT.

So the update that brings a custom module onto 19 is the update that drops its old constraints, and the log records it as routine housekeeping. I traced this through the 19.0 source rather than on a live upgrade, so check your own database with the query further down rather than relying on my reading or on the hope.

It happens in real projects

OpenSPP, a social-protection platform built on Odoo, runs on 19. A May 2026 refactor migrated three of its _sql_constraints declarations to models.Constraint. Another, the rule that each change request type has only one document rule per reason, stayed in the old form until an August 2026 fix (#395), and until then duplicates could be saved. The project now runs a lint check of its own for Odoo 19 patterns. None of their tests had failed, because nothing fails.

How to find them

In the code

grep -rn "_sql_constraints" --include=*.py addons/

Any hit in a module whose __manifest__.py version starts with 19. is a constraint that does not exist. In a 16, 17 or 18 module it is correct, and changing it there would break the module.

In the log

Restart the server and search the log for is no longer supported. There is one line per model still using the old form. After a module update, also search for Dropped CONSTRAINT.

In the database

List what PostgreSQL actually enforces on the table, and compare it with what the module declares:

SELECT conname, pg_get_constraintdef(oid)
FROM pg_constraint
WHERE conrelid = 'trade_account'::regclass
  AND contype IN ('u', 'c');

If a uniqueness rule is missing, find out whether duplicates have already got in:

SELECT reference, count(*)
FROM trade_account
GROUP BY reference
HAVING count(*) > 1;

With a checker

This is one of the rules in Nexa, the Odoo checker I build, as odoo.sql-constraints-are-ignored-from-19. It reads the file and the series in the module's manifest, and it stays silent on 16 to 18, where the old form is the only form. Run over OpenSPP's history, it fires on all four of the fixed declarations as the files stood before each fix, and on none after. With no model involved, it takes a fraction of a second:

nexa check models/trade_account.py --no-model

  impact     likelihood
  high       defect     line 18    odoo.sql-constraints-are-ignored-from-19
    TradeAccount declares _sql_constraints, which Odoo 19 ignores: the registry logs a
    warning and creates no constraint, so nothing enforces it -- declare each one as
    models.Constraint

Migrating without losing the rule a second time

The change itself is small, as the two examples at the top show. Three details decide whether the rule survives it.

Clear the duplicates first. If rows already break the rule, adding the constraint fails. Odoo 19 treats that as a warning, "not a deployment showstopper" in the words of its own comment in registry.py, and carries on without the constraint. So migrating the declaration is not enough on its own: run the duplicates query, merge or fix what it finds, and only then update.
Keep the name. Odoo 18 named the constraint {table}_{key}. Odoo 19 names it {table}_{attribute}, with the leading underscore removed. So ("reference_unique", ...) becomes _reference_unique = models.Constraint(...), and both produce trade_account_reference_unique. With the same name, the update recognizes the existing constraint as the one you declared instead of removing it.
Keep the definition text identical. Odoo stores the definition as a comment on the constraint and compares it with what you declare. If the text differs, even in spacing, it drops the constraint and adds it again, and that re-add is exactly the step that fails quietly when duplicates exist.

Then run the pg_constraint query again after the update. The constraint should be there, under the name you expect.

The general lesson

A framework upgrade does not only break things loudly. Sometimes it retires a way of saying something, keeps accepting the old way, and records the difference in a log line that nobody reads. The only defense is to check what the database actually enforces, not what the code appears to declare.

If you run Odoo and would rather have someone read your custom modules for this and the other failures that raise no error, that is what my Odoo reliability reviews are for. They are read-only, fixed-price, and start at £200.

Software Is Where My Actions Count: What a Special Interest Actually Does

Doby Baxter — Sun, 20 Sep 2026 13:25:49 +0000

People assume a special interest is just a hobby turned up too loud. It isn't. It's the one environment where my actions reliably produce consequences I can see, understand, and stand behind. Mine maps onto software, and that single fact explains more about my career than any decision I ever consciously made.

What a special interest actually is

The casual version of the term is something like "an autistic person who is really into trains." Technically true, completely missing the mechanism.

What's actually happening is that a particular domain becomes disproportionately capable of activating things that are otherwise hard for me to reach: motivation, sustained attention, emotional regulation, a sense of competence, a sense of coherence. Not because the subject is objectively more important than everything else in my life, but because my nervous system responds to it in a way it doesn't respond to almost anything else.

That's a very different claim from "I enjoy this." Plenty of things are enjoyable. Very few things reliably switch me on.

There's a name for this, and it isn't mine. Monotropism, developed by the autistic researchers Dinah Murray, Mike Lesser, and Wenn Lawson, treats attention as quantitatively limited: it pools into a small number of intense channels instead of spreading thinly across many. The image in the original work is a torch beam rather than diffused light, and the state it produces is an attention tunnel. Once you model attention that way, most of what follows here stops being a personality quirk and starts being a predictable consequence of how the attention is allocated.

So when someone asks why I'll work on a problem at 2am while physically exhausted, the honest answer isn't discipline and it isn't recklessness. It's that this is one of the few places where my brain will actually start. Telling me to apply that energy to something more sensible assumes the energy is fungible. It isn't. It's tunnel-bound, and the tunnel picked me rather than the other way around.

Same wiring, different surface

I read an account once by an autistic person describing why she spent enormous amounts of time in video games. The word she reached for wasn't "addictive." It was control. Agency. Autonomy. A world where her actions had consequences, the rules were legible, competence was achievable, progress was visible, and mistakes were recoverable. Everything her actual environment, at home and in institutions, did not reliably offer.

That turns out not to be an idiosyncratic account. It's close to a consensus finding in the qualitative research on autistic gamers, to the point where one study in the British Journal of Developmental Psychology takes its title straight from a participant: "I can actually do it without any help or someone watching over me all the time and giving me constant instruction". A large survey of autistic gamers puts stress relief and a sense of achievement at the top of the list of reasons, and work on escapism in autistic adults frames it as a self-regulation strategy rather than a pathology.

I recognized my own relationship with software in all of it immediately, because structurally it's the same thing.

A game gives you a bounded world that responds to you. Software gives you almost exactly the same properties, except the thing you produce exists outside the world you were playing in. You think of something, build it, hit a wall, learn, solve it, see it work, publish it, and someone can use it.

Same wiring. Different surface. The pull was never the subject matter, it was the structure: a domain where my actions count.

What my brain wants, and what software supplies

Here's the mapping, as concretely as I can state it.

My brain wants legible rules. Software is a system where the rules, however complex, are ultimately knowable. When something breaks, there is a reason. That reason can be found. Nothing about it depends on correctly reading a room.

My brain wants fast, honest feedback. Software tells you unambiguously and quickly whether what you did worked. The test passes or it doesn't. The build succeeds or it doesn't. No ambiguity, no social interpretation layer, no waiting weeks to find out whether you misjudged something.

My brain wants depth without a ceiling. Most interests eventually exhaust what's available to learn about them. Software does not. However far down I want to go, there is always another layer, and going deeper is rewarded rather than treated as excessive. A domain that never says "that's enough detail now" is an unusually comfortable place to put a tunnel.

My brain wants self-directed scope. I choose the problem, the approach, the architecture, the stopping point. Nobody assigns me the next thing. That matters enormously, because externally imposed structure is exactly what my executive function handles worst, and self-chosen structure is what it handles best.

My brain wants recoverable mistakes. Version control means almost nothing I do is irreversible. Being able to try something badly, see what happens, and roll it back is what makes exploration possible for someone who cannot reliably plan the whole route in advance.

My brain wants something that persists. At the end, an artifact exists. A repository, a release, a service, a skill I didn't have last week.

Put those six together and you get a description of an environment that could have been designed for how I work. It wasn't, obviously. It just happens to be the shape it is, and my attention found it and stayed.

The autonomy I don't get anywhere else

This is the part that's hardest to explain to people who assume I'm describing a preference.

I actually have a lot of control over my physical environment. I live alone. I arrange my space exactly how I need it. I eat a small, consistent set of foods that work. I go outside at night, when it's quiet and dim and there are no people, because the daytime version of that same errand costs more than my nervous system can consistently pay.

That's real autonomy and it genuinely helps. But controlling my environment is not the same as being able to participate in the world.

Every one of those adaptations still reads as "I can do this, but only under these conditions." I didn't choose 2am because it's my favorite hour to be alive. I chose it because it's when the cost drops to something payable. So even inside a life I've deliberately optimized around myself, I'm permanently aware of the set of things that remain out of reach, and no amount of rearranging my flat changes that.

Software doesn't work that way. In software the barrier between what I intend and what I can execute is thin and getting thinner, because the entire discipline is built out of tools whose whole purpose is to absorb load. I don't have to hold everything in working memory. I don't have to remember every API. I don't have to independently sustain a research thread across days, which is precisely the kind of continuous perseverance I'm worst at. The tooling carries the part I can't, and I do the part I can: the judgment, the design, the decisions, the responsibility for what ships.

That's the difference. Everywhere else I'm adapting the world to the boundaries of my nervous system. Here I'm using tools that let me cross them.

So when the interest activates, it isn't activating in a vacuum. It's activating the only reliable supply of something scarce in the rest of my life: I decided this, I did this, it worked, and it's mine.

Why the artifact matters so much

There's an extra layer on top of the loop, and I underrated it for years.

The work leaves evidence.

Each finished thing is a durable record that says: I learned this, I solved this, I built this, I can stand behind this. That matters disproportionately to someone whose memory doesn't reliably preserve their own history, and whose sense of capability fluctuates with energy levels that swing hard. On a bad day I can't feel competent. But I can look at something I built and read the receipt.

That's also why the interest didn't stay private. Publishing the work turns the internal loop into something with an external footprint: a portfolio, a service, a skill someone else can benefit from. A special interest that produces artifacts stops looking like a fixation and starts looking like a career, which is a fairly arbitrary distinction, but it's the one the world actually uses.

Why leaving is hard, and why "addictive" is the wrong word

I want to be honest about the cost, because the same mechanism that makes this good for me can consume everything I have.

Addiction imports a set of claims that don't fit here. What's actually happening is simpler: an activity becomes extraordinarily reinforcing when it supplies something that's scarce everywhere else in your life.

Monotropism gives a cleaner account of the exit cost than willpower ever did. Leaving an attention tunnel isn't like closing a tab, because you aren't next to the thing, you're inside it. The original paper puts it starkly: for someone in an attention tunnel, unanticipated change is briefly catastrophic. That's not a metaphor for mild annoyance. It's a description of why being pulled out of something feels the way it does.

There's a companion term for the other half of it. Autistic inertia covers both the difficulty of starting and the difficulty of stopping, the latter sometimes called termination resistance, and autistic people describe it as among the most disabling parts of being autistic while simultaneously describing deep absorption as one of the most restorative states available to them. Both things are true at once, which is exactly why this is hard to talk about honestly.

It's also worth separating two things that often get merged. Hyperfocus describes an unusually intense stretch of attention, hours or maybe days. It doesn't explain why someone returns to the same domain for years. A special interest is the long-horizon pattern, and it can become a genuine organizing feature of a life and an identity. The two interact, but they're not the same phenomenon, and collapsing them makes the whole thing sound more pathological and less structural than it is.

The consequence is that stopping isn't experienced as "I'm done for today." It lands closer to "I'm leaving the place where my actions count." That's a far stronger pull than enjoyment alone, and it's why the physical exhaustion always arrives long before the motivation does. There's no backpressure in the loop. Nothing in it signals that the upstream resource is depleted.

The only off-ramp I've found that actually works is making stopping cheap. Before I close everything, I leave myself enough state to resume without reconstructing the whole mental picture: the symptom, the current hypothesis, the last thing I changed, the next concrete step. That note isn't a reminder that the task exists. It's proof the thread hasn't been lost, which is the specific fear that keeps me working when I should be asleep. Once my brain accepts that the tunnel will still be there tomorrow, it will let me put it down.

The interest is not the problem

If there's a failure mode here, it isn't "I care about software too much."

It's that a single domain is carrying the entire burden of proving that my actions matter. That's a load-balancing problem, and the fix is not to take away the thing that works. Autistic accounts consistently point the other way: special interests function as protection against burnout precisely because they restore a sense of control. The fix is to widen the set of places where agency is available, even in small, unimpressive ways, so the interest gets to be one strong source instead of the only one.

What I'd resist entirely is the framing where a special interest is something to be moderated on principle, or grown out of. Mine is where my motivation lives. It's where I'm most competent, most regulated, and most recognizably myself. It produced a skill set, a body of work, and an income.

So if one idea survives this whole essay, let it be this:

I didn't build a career and then discover I enjoyed it. My attention found the one environment where it could reliably act, went all the way in, and the world happened to call the result a profession.

That's not a hobby that got out of hand. That's the only place my agency was ever fully available, and I'd be foolish to treat it as anything less.

AI as a Fluency Machine: What Software Engineering Taught Me About Checking a Model's Answer

Doby Baxter — Sun, 13 Sep 2026 16:33:01 +0000

We refuse to install a dependency without a lockfile, a checksum, and a license audit. Then we paste a language model's answer straight into a model file and call it velocity. The scrutiny didn't disappear — it just stopped applying to the thing writing the code.

The paradox

We have built an extraordinary apparatus of distrust around our own work. Lockfiles pin transitive dependencies to exact versions. Checksums verify the bytes arrived intact. Signed commits prove authorship. CI refuses a merge over one failing test. Code review exists because we decided, collectively, that no engineer's confidence in their own code is sufficient evidence that the code is correct.

Then a model produces forty lines, and they go in.

Not because anyone sat down and decided generated code deserves less scrutiny. It's that every mechanism we built assumes a human author on the other end — someone who can be asked why, who hedges when unsure, who owns the thing afterwards. Generated code walks past all of it, because none of it was pointed at that door.

The standards haven't changed. The risk hasn't changed. Only one thing has: the single participant in the process that cannot be held responsible for being wrong is now also the one we check the least.

As a software engineer, that asymmetry tells me the real disagreement isn't about whether AI writes good code. It's about what we are willing to call checked.

Hallucination isn't the interesting question

Most debates about AI and code ask whether the model hallucinates. Fair enough — it does. But hallucination is the easy failure, because it announces itself. An invented API doesn't exist. The import fails, the type checker complains, the test goes red. The system you already have catches it.

The failure that matters is quieter.

During development, my 7B cited odoo.onchange-is-not-validation — a real rule, in my corpus, traceable to upstream documentation — and then wrote an @api.onchange to guard the value. Every citation verified. The answer was still wrong.

Citation existence is not rule compliance. That one sentence is what the whole project is built on.

I've come to think of the underlying machine as a fluency machine. I use the word deliberately. It doesn't manufacture wrong answers — wrong answers predate it by the entire history of the profession. What it manufactures is the appearance of having checked. A junior engineer who is unsure hedges, and you can hear it in the hedge. A model that is unsure produces the same fluent, well-structured, confidently-cited paragraph as a model that is right. The uncertainty signal we spent careers learning to read simply isn't in the output.

Fluency is not a confidence interval. It just renders like one.

A prompt is not a specification

Here's where software engineering has something to say. Our entire discipline runs on abstraction — interfaces, APIs, frameworks, platforms — each layer letting one engineer reason about one problem without drowning in all the others. A prompt is an abstraction too. It compresses everything you know about a domain into prose and hands it over as though prose were a contract.

But every abstraction hides what it discarded, and prose hides more than most, because prose has no schema. You can't diff it meaningfully, you can't validate it, and you cannot test whether a paragraph still means what it meant before you edited it.

I found the edge of that the ordinary way. Prompt tuning plateaued after two iterations. Hardening the Odoo rule about returning false for an empty field fixed the scalar cases and simultaneously broke the Many2one tuple handling that had been correct the day before. A 7B holds a bounded number of constraints; past that point, more instruction text just trades one error for another.

The same limit showed up in routing. My first attempt used a single system prompt covering both Odoo and TypeScript. Asked a plainly Odoo question — cap a sale order line quantity — it answered entirely in TypeScript with a Zod schema. The instructions bleed. A small model doesn't reliably route between two stacks described in one paragraph.

So I moved the rules out of the prompt and into data. Each rule lives in corpus/rules/*.json against a JSON Schema: a citable id, a severity, the failure it prevents, a wrong/correct code pair, an upstream documentation URL where one exists, and where possible a regex that detects the violation in generated code. The system prompts and the retrieval index became build artifacts, generated from that corpus by nexa build. Same principle as z.infer<typeof Schema> — one definition, derived artifacts, no drift.

That didn't make the model smarter. It changed the failure mode. Instead of rewriting prose and hoping, a rule is written once and flows to the prompt, the retrieval index, and the compliance checker together.

Nobody misconfigured it, but the system decayed

Distributed systems engineers know the shape of the next part. A latency bug in one service cascades through a queue, triggers retries, saturates a database, and surfaces as an outage somewhere else entirely. Every component behaved to spec. The system as a whole did something nobody designed.

I benchmarked the 7B at 37 tok/s. Four instrumented runs later, the report showed roughly 10. I offered three diagnoses; the first two were wrong.

The actual cause was that Ollama's memory estimator is conservative and leaves layers on the CPU with VRAM still free — 11.7 tok/s automatic versus 38.6 forced, same model, same context. My Modelfiles carried num_gpu 99, but the pipeline was calling the raw base model, which has no such parameter. Meanwhile the KV cache environment variables had been set while the server was already running, so they never took effect at all. And two orphaned llama-server processes were sitting there holding 1.4 GB of VRAM, left behind when their parent was killed.

Nobody misconfigured anything. Ollama's estimator was being careful. Windows was doing what it does with environment variables set after a process starts. The orphans were doing what orphans do. Collectively, the system ran at roughly a third of its speed for most of a working session — while I read a number I had measured once and believed ever since.

An unmeasured number decays into a claim.

That is the entire reason nexa doctor exists, and why it checks GPU residency and each of those traps by name rather than just confirming that Ollama is up. There's an old rule in operations: someone owns every service. Complexity raises the effort of attribution. It never removes the need for it.

Patterns inherit their author's blind spots

You can't check for "is this code correct" — the phrase is too vague to be an objective. So, exactly as we do everywhere in engineering, we check proxies. A regex matching @api.onchange in a validation context is a proxy for "this code is using the wrong mechanism to hold an invariant."

Individually, these are reasonable. The problem is that a proxy always discards information, and it quietly inherits the assumptions of whoever wrote it.

So the patterns get tested too. Every rule already carries a wrong and a correct sample, which means the test data existed for free. nexa validate fails the build on three faults: a pattern that doesn't match its own wrong sample catches nothing; a pattern that fires on its own correct sample cries wolf; a satisfied_pattern that clears its own wrong sample is inert by construction.

Then nexa crosscheck fires every pattern at every other rule's correct sample — because self-testing proves a pattern handles its own case and says nothing about whether it goes off on unrelated good code. The first run found three real defects. float-comparison fired on qty > 0, including inside SQL where float_compare doesn't apply; narrowed to equality, which is the actual trap. odoo-read-returns-array fired on any Schema.parse(await ...). And ondelete-is-a-decision correctly flagged a sample in my own corpus that didn't follow its own rule.

That last one is the one I'd keep. The checker was right and the corpus was wrong.

It's also the loop worth being nervous about: my rules become the system prompt, the system prompt shapes the answer, and the answer is then checked against the same rules that produced it. A rule that is subtly wrong is wrong in three places simultaneously, and the pipeline will report VERIFIED at every step. All models are wrong but some are useful — the danger was never the simplification. It's forgetting what got discarded in it.

Which is why the limitation goes in the docs, in plain words: 27 of 32 rules trace to upstream documentation, and the rest rest on general knowledge and deserve more scepticism. These rules were written by an assistant, not harvested from production incidents. Rules drawn from real incidents would be worth more.

"Verified" can be theatre

The standard reassurance in this space is that the tool validates its own output. From an engineering perspective, that tells you almost nothing about how the system behaves. Inserting a step into a pipeline doesn't guarantee verification, any more than a deployment approval guarantees oversight — an approval only matters if the reviewer has the information to spot risk, the authority to say no, and the time to actually look.

We have a name for the human half of this: automation bias. Once software earns a reputation for being usually right, reviewers start confirming its output instead of interrogating it.

The checker half has a sharper version of the same problem. A checker that fires on good code is worse than no checker, because it teaches you to dismiss it — and once you're dismissing it, it will be dismissed on the day it was right. So five of my rules deliberately carry no pattern at all, with the reason recorded for each. Two need set comparison between a decorator's arguments and the attributes its body reads, which is AST work, not regex work. One lives in a diff between module versions. Two depend on context a snippet doesn't contain. Those rules return no verdict rather than a false pass. 84% coverage with an honest list of the gap beats 100% with five patterns producing noise.

So "did it verify?" is the wrong question. The right one is: what exactly was checked, and what does the absence of a finding actually prove?

In Nexa, VERIFIED means the checks that exist found nothing. It does not mean correct. Compliance is only checked against rules retrieved for that question, plus pinned ones — so a rule that was never retrieved is a rule that was never enforced. I'd rather ship that sentence than a green checkmark.

Small and local is not a lesser tool

Now flip the paradox around.

A 7B-to-30B local model does not match a frontier model on hard architectural reasoning. That gap is a function of scale, and no amount of prompting closes it. I put that in the README, near the top, deliberately.

But engineers make a distinction when optimizing: removing overhead is not the same as increasing capability. Stripping out overhead lets existing resources do more — it doesn't upgrade the hardware. Nexa doesn't make a small model smarter. It removes the thing that made a small model untrustworthy: the gap between an answer and any means of checking it.

And for this particular job, that trade isn't obviously a loss. The frontier model has more capability. The local one has more provenance — it answers from rules I can read, cite, version and test, on hardware I own, with client code that never leaves the laptop. No API key, no network call, nothing phoning home. On a machine used for client work that isn't a feature, it's a precondition, which is also why telemetry records rule ids, counts, model names and timings, and not question or answer text unless you explicitly turn it on. A telemetry file is the last place client code should quietly accumulate.

Same technology, different question. One asks how capable this can be. The other asks how wrong it can be without me finding out.

Verification cannot be delegated to fluency

Every mature engineering discipline eventually learns the same lesson: a system can't be trusted merely because it functions. It has to be observable, auditable, and — this is the part we keep skipping with generated code — falsifiable. We'd never run production without logs, traces and deployment history, because once causality goes opaque, reliability becomes impossible. Yet we routinely accept generated code on terms we'd never accept from a library: no provenance, no stated assumptions, no way to ask what it was checked against.

Observability can't be bolted on after a system fails. Verifiability follows the same rule. If a tool isn't designed to make its own answers checkable from the start, no amount of downstream review will conjure that property later — you'll just be reading fluent paragraphs faster.

So if one idea survives this whole article, let it be this:

The true measure of a coding assistant is not how often it is right. It's how reliably you find out when it is wrong.

Correctness can't be prompted into existence. It can't be inferred from formatting, borrowed from a real-looking citation, or assumed because the prose was confident and the rule id resolved. Someone still has to write the rule down in a form that can be checked, decide what a failing check means, and accept what the gaps cost. Those decisions stay irreducibly human — which is precisely what I want from a tool I let anywhere near a client's codebase.

Nexa is source-available under PolyForm Noncommercial 1.0.0 — free to read, run, modify and evaluate for any noncommercial purpose. It's a few hundred kilobytes of Python (stdlib only) that orchestrates open models you pull from Ollama; no weights ship with it. 32 rules today across Odoo, TypeScript and JavaScript, 27 with an automated check, 0 cross-hits.

The ARCHITECTURE.md records every decision with the evidence behind it, including the ones that were wrong first — and an honest account of what it cannot do. If you only read one file, read the limitations section.

When Is a System Not Fit for Purpose?

Doby Baxter — Tue, 08 Sep 2026 18:27:47 +0000

The question

When do we get to say that a system is not fit for purpose?

In software engineering, we usually have a fairly straightforward answer. A system is fit for purpose if it reliably does the thing it was designed to do.

That sounds obvious, but we seem to apply a different standard to public systems.

A government service can have a department behind it, an application portal, a helpline, a set of criteria, a budget, and hundreds of people working within it. It can process thousands of applications and schedule thousands of appointments.

None of that necessarily tells us whether it is actually achieving its purpose.

A system existing is not the same thing as a system working.

And from a developer's perspective, that distinction matters.

Activity is not an outcome

Imagine an application with a perfectly functioning workflow:

User
  ↓
Application
  ↓
Validation
  ↓
Assessment
  ↓
Decision

Every component works.

The application is submitted successfully.

The validation passes.

The assessment takes place.

The decision is recorded.

From an operational perspective, the system has performed exactly as expected.

But what if the user finishes the process without receiving the support they actually needed?

The system has produced activity, but not an outcome.

This is a familiar problem in software engineering. We can build dashboards showing requests processed, jobs completed, transactions handled, and uptime maintained, but those metrics don't necessarily tell us whether the system is solving the problem it was built to solve.

Applications received are activity.

Appointments attended are activity.

Cases opened are activity.

Forms processed are activity.

The more important question is:

Did the user's situation actually change?

That is an outcome.

And when a system measures activity more effectively than it measures outcomes, it becomes possible for the system to look healthy while the people using it experience failure.

The edge-case problem

One of the first things you learn as a developer is that the happy path isn't the whole system.

You can design a beautiful workflow for:

Input → Processing → Success

and still have a terrible system if you haven't thought carefully about what happens when the input doesn't fit your assumptions.

Real systems encounter:

invalid input
missing information
unsupported configurations
unavailable dependencies
unexpected states
conflicting requirements
users who don't behave exactly as expected

Good software doesn't pretend those cases don't exist.

It detects them.

It explains them.

And, where possible, it provides a recovery path.

Public services have the same problem.

A system should be able to tell someone not only that they qualify, but also when it cannot provide what they need.

That isn't necessarily a failure.

In many cases, early rejection is better system behavior than indefinite processing.

If an API knows that it cannot fulfill a request, returning a clear error is preferable to accepting the request, passing it through ten other services, consuming resources, and eventually failing without explaining why.

The same principle applies to services involving people.

If a program cannot realistically help someone, keeping that person inside the process for months isn't evidence that the program is working.

It may simply mean the system doesn't have a meaningful failure state.

What a good failure state looks like

Consider two systems.

System A

A person enters a service.

The system determines that it cannot help them.

It explains why and provides an appropriate onward route.

Person
  ↓
Assessment
  ↓
Not suitable
  ↓
Explanation
  ↓
Alternative service

The person hasn't received the original service, but the system has still produced a useful outcome.

Now consider System B:

Person
  ↓
Application
  ↓
Appointment
  ↓
Documentation
  ↓
Follow-up
  ↓
More documentation
  ↓
More appointments
  ↓
Eventually: cannot help

System B may produce considerably more measurable activity.

But it is arguably the worse system.

From an engineering perspective, the difference is obvious.

System A has a defined failure state. System B has an expensive failure path.

The user spends time and resources discovering something the system could potentially have established at the beginning.

That's not just inefficient.

It's poor system design.

The infinite loop

There is another failure mode that becomes particularly interesting when you look at public services as systems: the infinite loop.

Suppose a program is intended to help bridge the gap between a candidate and an employer.

The intended architecture might look something like this:

Candidate
   ↓
Program
   ↓
Employer connection
   ↓
Employer engagement
   ↓
Employment

But what happens if the program can only meaningfully intervene after an employer has already engaged?

The process becomes:

Candidate applies
   ↓
Employer does not engage
   ↓
Application rejected / ignored
   ↓
No employment
   ↓
No employer-side intervention
   ↓
Candidate applies again
   ↓
Repeat

Nothing has technically crashed.

There may be no obvious software equivalent of an exception.

The system is simply unable to transition into the state required for success.

In software terms, I would immediately ask:

What state transition is missing?

If the purpose of the system is to help create an employer connection, but the system depends on an employer connection already existing before it can provide that intervention, then there is a circular dependency.

The system is waiting for the event it is supposed to help create.

That deserves architectural scrutiny.

Every system has boundaries

This is also where transparency becomes part of system design.

Every system has a boundary.

An API has supported inputs.

A database has constraints.

A service has capacity.

A platform has supported environments.

Good systems document those boundaries.

You don't want a developer discovering after six months that an API simply cannot support the operation they have been building around.

The same should be true for services involving people.

If a program only has established employer relationships in particular sectors, that matters.

If certain types of work are outside its scope, that matters.

If particular circumstances mean the service is unlikely to produce a useful outcome, that matters.

The user needs that information early enough to make decisions about their own time.

Otherwise, the system effectively hides its own limitations and leaves the user to discover them through repeated failure.

Observability matters

Modern software systems rely heavily on observability.

We want to know:

what happened,
when it happened,
where it happened,
why it happened,
how long it took,
where the failure occurred,
and what happened afterward.

Without observability, debugging becomes guesswork.

The same principle should apply to public systems.

If a program claims to connect people with employers, we should be able to answer questions such as:

Which employers have established relationships with the program?
Which sectors are covered?
How many participants were successfully connected through those relationships?
How many were simply advised to submit standard applications?
How many cases were identified as unsuitable?
What happened to those people afterward?
How many received an effective onward referral?

These aren't hostile questions.

They're essentially observability questions.

If the system cannot answer them, then it becomes difficult to determine whether the system is performing the function it was designed to perform.

Metrics can create the wrong behavior

This is another familiar problem in software engineering.

What you measure influences what you optimize for.

If an engineering team is measured primarily on the number of tickets closed, engineers will naturally become better at closing tickets.

That doesn't necessarily mean the product is improving.

If a call center is measured primarily on call duration, reducing call duration becomes an obvious optimization target.

That doesn't necessarily mean customers are getting their problems solved.

The same problem can exist in public services.

If success is primarily represented through:

applications,
appointments,
interactions,
cases,
referrals,
and completed processes,

then the organization can become extremely good at generating activity.

But activity isn't necessarily progress.

The difficult metric is the one that matters most:

What changed for the person?

Did they get employment?

Did they receive the support they needed?

Did the barrier actually get removed?

Did they reach another service that could help them?

Those are outcome metrics.

And outcomes are often considerably harder to measure than activity.

The user becomes part of the error-handling layer

There is another cost that doesn't always appear in system metrics.

When a system fails, somebody has to compensate for the failure.

In software, that might mean a retry mechanism, a dead-letter queue, a fallback service, or an operator intervention.

In poorly designed human-facing systems, that responsibility can quietly move onto the user.

A form fails, so they try again.

An email goes unanswered, so they follow up.

A verbal commitment isn't recorded, so they document it themselves.

A case is transferred, so they reconstruct the history.

A process doesn't explain what is happening, so they maintain their own timeline.

Eventually, the person becomes the system's external state store.

They keep the records.

They track the state.

They reproduce missing context.

They provide the observability the system itself failed to provide.

From a developer's perspective, that's a serious design smell.

The system has outsourced state management to the user.

Documentation becomes infrastructure

This is why documenting every interaction can become so important.

Emails, dates, appointments, names, decisions, promises, and supporting documents effectively become a second system running alongside the official one.

The user maintains it because the official system may not reliably preserve the context they need.

Imagine having to manually maintain your own audit log because a production system doesn't provide one.

You would consider that an architectural problem.

Yet people navigating complicated administrative systems can end up doing exactly this.

They become responsible for preserving the state of their own case.

That work has a cost.

It takes time.

It takes attention.

It takes organization.

It takes emotional energy.

And none of those costs necessarily appear in the institution's metrics.

Accessibility is part of system design

This becomes even more important when the system is intended to support disabled people.

A system that requires sustained attention, precise documentation, repeated communication, and extensive administrative work may unintentionally create barriers for the very people it is intended to support.

That doesn't necessarily mean every requirement should be removed.

It means the system needs to account for the users who have to operate it.

In software, we call this accessibility.

We don't expect every user to interact with a system in exactly the same way. We provide alternatives, reduce unnecessary friction, and design interfaces around the capabilities and needs of the people using them.

Human services should be treated with the same principle.

If completing the process requires overcoming the same kind of barrier that the service is supposed to help with, then the architecture deserves examination.

You shouldn't need the outcome in order to have the capacity to navigate the process that produces the outcome.

Failure should be visible

A well-designed system makes failure observable.

If a dependency is unavailable, the system should say so.

If an input is invalid, it should explain why.

If a request cannot be fulfilled, it should fail clearly.

And if the system itself cannot provide the required service, that limitation should be visible as early as possible.

The alternative is a system where failure is hidden behind continued activity.

The user keeps attending appointments.

More forms are submitted.

More emails are exchanged.

The case remains open.

The process continues.

Eventually, months later, the system reaches the same conclusion it could potentially have reached at the beginning.

From the organization's perspective, there was plenty of activity.

From the user's perspective, there was no progress.

So, when is a system not fit for purpose?

I don't think the answer is simply "when the system isn't perfect."

No serious system is perfect.

And I don't think saying no is inherently a failure.

Sometimes the correct system behavior is:

We cannot help you with this.

The important part is what happens next.

A system becomes questionable when it cannot identify its own boundaries, cannot communicate them clearly, and can continue consuming a person's time and resources without producing a meaningful outcome.

In software, we'd investigate that.

We'd look at the architecture.

We'd examine the state transitions.

We'd inspect the failure modes.

We'd check the metrics.

We'd look at the monitoring.

And we'd ask whether the system is actually optimizing for the thing that matters.

Public services deserve the same level of scrutiny.

Because the ultimate test isn't whether the process ran.

It's whether the system achieved its purpose.

A system can be operational, compliant, fully staffed, and processing thousands of cases while still not be fit for purpose.

Sometimes the most important failure isn't that the system crashed.

It's that the system kept running exactly as designed while the person it was supposed to help went nowhere.

Learning to Build Without a Ladder

Doby Baxter — Sun, 06 Sep 2026 00:52:55 +0000

I never got the junior job.

Not for lack of trying. I spent well over a year applying, building, learning, and applying again. For long stretches I could not get past the first filter, let alone into a room with an engineer. And I am not unusual. I am one of a very large group of people who entered software and security over the past five years or so and found that the door marked "start here" had quietly been taken off its hinges.

We are often described as self-taught, as if that were a personality trait or a lifestyle choice. For most of us it was not a choice. It was the only path left standing once the others were dismantled.

The ladder that used to exist

The traditional way you became a good engineer looked roughly like this:

learn, get a junior role, make mistakes under supervision, become competent, become mid-level, eventually become senior.

Every rung mattered, and the early ones mattered most, because that is where you were allowed to be wrong cheaply. Someone experienced sat near you and said "not there, we tried that two years ago, here is what happened." That sentence is worth more than any tutorial ever written.

What replaced it, for a lot of people, is this:

learn, apply, rejected, apply, rejected, apply, rejected, somehow already be experienced.

And then the same industry turns around and says it needs experienced developers. Where, exactly, are they supposed to come from? You cannot eliminate the junior opportunities and then complain that there is a shortage of seniors. Those seniors had to be made somewhere. The industry has been eating its seed corn and acting surprised at the harvest.

The uncomfortable part is that no single company is behaving irrationally. Each one reasonably asks why it should train someone for two years when it can hire a person who already knows the system, especially when hundreds of thousands of experienced developers have been laid off and are already on the market. Individually rational, collectively ruinous. The full cost does not show up on a quarterly report. It shows up years later, when the people who could have become the next generation of seniors were never given the chance to start.

What I did instead

If the apprenticeship was gone, I had to build my own. So I went where the door was still open: open source.

Open source has always been one of the few places where you can say "I do not have a job yet, but I want to become good," and actually be taken up on it. You find a project. You read the code until it stops being frightening. You fix something small. You submit it. Someone reviews it and tells you, plainly, what is wrong. You improve. You come back for something harder. That loop is an apprenticeship. It is the apprenticeship, just without the salary or the org chart.

Here is what that looked like for me, concretely.

I contributed a fix to GitLab core that was reviewed, merged by a maintainer, and shipped to production in a release. Small in scope, but it was real code in a system that millions of people depend on, held to the standard of people who maintain that system for a living.

I built the Pyxel Config Lab, a tool for building and validating configuration for the European Space Agency's Pyxel detector-simulation framework. It was credited by ESA in an official release announcement. I did not have a job at ESA. I had a problem I understood and the willingness to solve it in the open.

I started contributing to OpenSPP, an open-source social protection platform, because reliability and validation are what I care about most and because that work touches systems that actually matter to people's lives. My first contribution there was, characteristically, about validation: making sure a record could not accept an impossible value and quietly produce nonsense downstream.

I began working into OpenTelemetry, because the instinct that made me care about clean configuration and honest error messages is the same instinct that makes me care about whether a distributed system, or an AI system, can tell you the truth about what it is doing.

Alongside that I built accessibility tooling as browser extensions, and I write. A lot. The writing is not a side project; it is how I think, and it is how a person with no institutional letterhead makes their work legible to strangers.

None of this was assigned to me. Nobody onboarded me. I assembled the apprenticeship out of whatever was reachable, and the reachable thing was the open commons.

What you can learn from home

Here is the part I want to be honest about, because I think the "just teach yourself" crowd gets it badly wrong in the other direction.

Information is everywhere now. You can learn languages, databases, distributed systems, compilers, networking, and architecture from your bedroom. What you cannot fully learn there is what it feels like to be responsible for a system that has been running for six years, with dozens of developers, three generations of architectural decisions layered on top of each other, real customers depending on it, and someone telling you not to touch a particular corner because the last person who did caused an outage.

That knowledge is situational. It is institutional memory. It is the difference between knowing what a database index is and having migrated a live database with users on it at an hour you would rather forget. No course, no book, and no chat assistant can hand you that. You have to live it, inside a real organization, with real consequences. Which is precisely the thing the closed door denies us.

So I am not claiming the self-taught path is equivalent. I am claiming it is what was left, that many of us became genuinely capable through it, and that the fact we survived the missing ladder does not prove the ladder was unnecessary. It proves how resourceful people get when a system fails them.

AI is an accelerant, and the direction is a choice

I work AI-assisted. I do not type every line unaided from a blank file, and I am not embarrassed by that. I remain accountable for every design decision and can explain any of them. For someone learning without a senior at the next desk, an AI collaborator is genuinely powerful: it will explain an unfamiliar architecture, propose alternatives, surface edge cases, write tests that expose your own assumptions, and shorten the hours you would otherwise spend stuck. That is real mentorship-shaped help, available to people the labor market gave nothing to.

But the tool is neutral, and the institutions using it are not. Picture two companies with the identical AI.

Company A says: apprentices use this, seniors review their work and teach them why things are wrong. AI becomes an accelerator for apprenticeship. You can fast-track a motivated beginner into a productive engineer faster and more cheaply than before, and they want to be there, so the company wins too.

Company B says: the AI writes most of the code, so we do not need juniors, give us a handful of seniors. AI becomes an accelerator for headcount reduction, and the learning layer is deleted.

Same technology, opposite outcomes. Company B looks better this quarter. Company B is also quietly ensuring there are no seniors to hire in five years.

There is a bitter twist here for people like me. The same industry that shut the door increasingly rejects the way self-taught engineers actually work. I have been ruled out of roles for using AI in an assessment, judged by a process that bans the exact tool the situation forced me to master, while the label "vibe coder" gets thrown at anyone who works this way. You cannot remove the apprenticeship, hand people a tool to survive without it, and then penalize them for having learned to use it.

The flood is fine. Judgment is the skill.

People worry about the flood: too many apps, too many libraries, too many books, too much of everything now that the barrier to creation has dropped. I do not share the worry. Lowering the barrier to making things is good. If someone who could never program before builds a small game for their friends, wonderful. Not every act of creation has to be economically optimized, any more than every painting has to sell.

The real line is not between AI-generated and hand-written, and it is not between accessible and gatekept. It is between creation connected to understanding and creation disconnected from it, in the places where correctness actually matters. Accessibility is wonderful. Learning is necessary. Blind delegation is dangerous. "Ban the tool" answers none of that. The skill that matters now is judgment: can the person understand, test, and improve what the tool produced. That is the thing we should be teaching, and it is exactly the thing you build by doing real work under review, which is exactly the thing being taken away.

Engineering is not a business subplot

Business constraints are real. Cost, deadlines, regulation, and risk shape engineering, and an engineer who pretends otherwise builds beautiful things nobody can afford. But there is a healthy boundary, and it has been crossed repeatedly. Business should set the constraints and the goals. Engineering should decide how those goals can be met safely and realistically. When leadership starts dictating technical reality instead, that this will take two weeks, that tests are optional, that the generated code is fine as-is, that another senior is an unnecessary expense, that the mentorship layer can go, you get exactly the collapse we are living through. A society can outsource the production of goods. It cannot indefinitely outsource the production of expertise.

The generation that learned to build without a ladder

That is not a happy ending, and I will not pretend it is one. The ladder mattered. Removing it hurt real people and is storing up a shortage the industry will feel for years. But it is also true that the commons is still open, that the work is still real, and that a reviewer on an open-source project will still tell you the truth about your code, which is more than most job applications ever will.

I am building my own path now as an independent engineer, and I try to pass the ladder back down where I can, including teaching basic digital skills to people who have even less access than I did. Not because the system worked, but because it did not, and someone has to keep the door propped open.

The question I would put to the industry is simple, and it is not "will AI replace programmers." It is this: who is going to produce tomorrow's experienced engineers, if today's companies keep removing every opportunity to become one?

Enforcing Data Invariants in Odoo: Model Constraints, Migrations, and Tests That Actually Cover the Fix

Doby Baxter — Sat, 05 Sep 2026 14:30:10 +0000

This post collects a few things I ran into while contributing fixes to OpenSPP, a social-protection platform built on Odoo. They are all variations on one question: when a value has to satisfy a rule, where does that rule need to live so it holds on every path the value can arrive through.

Write paths in Odoo

A stored model field can be written through several paths:

The form UI.
ORM create() and write() from other code.
CSV and Excel import (load()).
Remote writes over XML-RPC, the API, and DCI.

These do not share the same hooks. Where a guard is placed determines which of these paths it covers.

The relevant decorators

Three decorators come up, and the difference between them is the whole point:

Decorator	Fires when	Covers import / RPC / ORM
`@api.onchange("field")`	In the form UI only, as the user edits	No
`@api.constrains("field")`	On every create/write touching the field	Yes
`@api.depends("field")`	When a computed field recomputes	Yes, for stored computes

onchange runs client-side in the form. constrains runs server-side on the stored field. If a rule needs to hold everywhere, it has to be a constrains (or a database constraint), not an onchange.

Example: a future birthdate

res.partner.birthdate had a single guard, an onchange that reset the field if the date was in the future. That guard only runs in the form, so ORM writes, imports, and API writes all stored future dates. The non-stored age compute then rendered those as negative values.

The fix was to add a stored-field @api.constrains("birthdate"). Because the field is stored and writeable, the constraint fires on create, write, and import, so the rule no longer depends on which path the value came through. The onchange can stay as immediate form feedback, but it is no longer the only check.

Invalid state propagates to other fields

A second case shows why the location of the check matters beyond the field itself. A plan model had an is_current flag meaning "the current plan for this case." Completing a plan set its state to completed but never cleared is_current.

Downstream, several things read that pair:

A derived current_plan_id (based on is_current) kept pointing at the completed plan.
A "has an active plan" check read false.
A one-current-plan-per-case constraint then refused to let a new plan be marked current, because the completed plan still held the flag.

The incoherent value was written in one place and surfaced as a failure elsewhere: a user could not mark a new plan as current. The fix folded is_current = False into the same write() that sets the completed state, so every path that completes a plan also releases the flag.

A code fix only covers future writes

A write-time constraint or a corrected write() does not touch rows that are already in the bad state. Existing deployments still held completed plans flagged as current, and those cases stayed blocked after the fix shipped.

That needs a separate data migration. When the manifest version increases, Odoo runs matching migration scripts:

module/
  migrations/
    19.0.2.0.1/
      post-migration.py

def migrate(cr, version):
    if not version:
        return
    cr.execute(
        "UPDATE spp_case_intervention_plan "
        "SET is_current = false "
        "WHERE state = 'completed' AND is_current = true"
    )

Notes on the migration:

The signature is always def migrate(cr, version):, and cr is the raw cursor.
Keep the SQL literal. No f-strings, .format(), or composed identifiers, or the security linters (Semgrep, pylint-odoo) flag it.
The if not version: guard skips fresh installs, where there is nothing to repair.
Repairing existing rows and preventing new bad rows are two separate jobs. Both are needed.

Fixture and demo data can re-seed the bad state

The same module's demo data generator was creating the bad state directly (writing state = "completed" without going through the completion path, and passing is_current: True alongside a completed state). A migration does not help here, because a fresh install recreates the rows after the migration would have run.

The fix was to route both generator sites through the real completion action, so generated demo data satisfies the same invariant as production data. Worth checking the code that seeds data, not only the code that validates it.

Tests that pass without the fix

A test can go green for a reason unrelated to the code under test. Odoo applies field defaults before running validation, and _validate_fields fires constraints on the defaulted fields too.

In this model, registration_date defaults to today, and a pre-existing constraint requires registration date to be after birthdate. So creating a record with a future birthdate raised a ValidationError from that older constraint, before the new birthdate constraint ran. The test asserted only the exception type, so it passed with the new constraint removed.

Two ways to make such a test actually cover the fix:

Assert on the message, for example assertRaisesRegex(ValidationError, "Date of birth cannot be in the future"), so you know which constraint fired.
Or pass explicit values for the defaulted fields so only the constraint under test can raise.

A useful check either way: revert the fix locally and confirm the test fails. If it stays green, it is not covering the change.

It also helps to assert the reported symptom rather than the internal flag. If the bug was "a completed plan blocks marking a new one current," the test should complete the plan and then create a second plan and assert it does not raise, which is the behavior a revert has to break.

Date comparisons and timezone

fields.Date.today() returns the server date, which is effectively UTC. fields.Date.context_today(record) returns the date in the acting user's timezone.

For a "not in the future" check, the server date can reject a valid date for users ahead of UTC. A user in Pacific/Auckland at 10:00 local is already on the next calendar day while the server is still on the previous one, so a same-day birthdate compares as "in the future" against the server date. Using context_today(record) compares against the user's date instead.

Summary

For a rule that must always hold:

Enforce it with @api.constrains or a database constraint, on the stored field, not with @api.onchange.
Add a migration to repair rows already in the invalid state.
Check fixture and demo data so they do not re-seed the invalid state.
Write the test to fail without the fix, and assert the reported symptom.
Use context_today for date comparisons that depend on the user's calendar day.

If GOV.UK Knows the Application Is Invalid, Why Did It Take My Payment?

Doby Baxter — Fri, 21 Aug 2026 13:22:32 +0000

Maybe this is another one of those posts where I end up roasting the government. But stick with me, because this isn't really a politics post. It's a post about state machines, validation layers, and what happens when you put an irreversible action at the end of a workflow that never once checked whether the user should have been allowed to reach it.

The government part is just the catalyst. The engineering part is the point.

What actually happened

I applied for a British passport on GOV.UK.

Early in the form, it asks something like:

Do you have a certificate of naturalisation or a certificate of registration?

There are a lot of yes/no questions on that journey, and this one behaves exactly like the rest of them. I answered No, and the form did what it always does: it let me continue.

So I continued. I answered the remaining questions. I entered my personal details. I entered my bank details. The system accepted my payment of £107.

Only afterward did I learn that the certificate wasn't supporting evidence I could send in later. It was a prerequisite — something I needed before the application was valid at all.

I asked whether the application could be paused while I resolved the prerequisite. No. I was told I had roughly three months, and that the payment is non-refundable. If I can't complete everything in that window, the money is simply gone.

Here's the part that matters as an engineer: the system had my answer from the very beginning. I told it "No" on question three. It took my money on question twenty-something. Nothing in between used the information it already had.

The problem isn't the question

Asking "Do you have certificate X? Yes/No" is completely fine. That's not the bug.

The bug is what the system does after the answer.

A binary question that gates eligibility should not behave identically to a binary question that merely records a preference. If "No" makes the entire application invalid, then "No" is not informational — it's a hard gate. But the interface gave me no signal that I'd just walked through a gate. It looked like every other question, so I reasonably read it as every other question.

That's a semantic failure dressed up as a UI detail.

Input validation was never the issue

This is where my actual specialization kicks in — I spend most of my working life on configuration, error messaging, validation, and deterministic workflows — so let me be precise about which validation failed, because "the form should validate better" is too vague to be useful.

There are several distinct layers, and they are not interchangeable:

Syntactic validation — is this field shaped correctly? (Is the date a date?)
Semantic validation — does this value make sense in context? (Is the date in the past?)
Business-rule validation — is this allowed by the rules of the domain? (Are you old enough to apply?)
Workflow validation — given everything you've told me so far, are you eligible to be at this step at all?
Submission validation — is the application in a state where it can legally, financially, and administratively be finalized?

My passport form almost certainly nailed the first three. Every field was well-formed. Nothing was syntactically wrong.

It failed at workflow validation and submission validation — the two layers that actually protect the user from spending money on something that cannot succeed.

Don't let an invalid state propagate

Here's the conceptual shape of what should have happened:

START
  → eligibility questions
  → prerequisite missing
  → [ STOP: application cannot proceed ]

Here's what actually happened:

START
  → answer indicates prerequisite missing
  → continue
  → continue
  → continue
  → payment accepted
  → application submitted
  → "you cannot actually complete this process"

An invalid state that is detectable at step 3 should never be allowed to survive until step 20. In any other production system, we'd call that error propagation — a known-bad condition carried silently downstream until it detonates at the most expensive possible point.

The fix doesn't require anything clever. It doesn't need machine learning or a smarter form. It needs one correctly defined state transition:

if prerequisite_required and not prerequisite_present:
    block_submission()
    explain_why()
    explain_how_to_resolve()
    preserve_progress()

Never gate an irreversible action on an optimistic assumption

Payment is the textbook example of an irreversible action. Money leaves your account. The system tells you it won't come back.

So the condition for accepting payment cannot be:

payment_allowed = user_reached_payment_page

It has to be:

payment_allowed = application_state == READY_FOR_SUBMISSION

Reaching the payment screen is a fact about navigation. Being ready to submit is a fact about eligibility. The system conflated the two, and the user paid for the difference.

Any time an action is irreversible — payment, submission, deletion, dispatch — the system should treat it as a boundary that requires the whole prior state to be provably valid, not merely reachable.

The real world is asynchronous, and the workflow needs to model that

This is the part administrative software chronically gets wrong.

Completing a prerequisite in real life is rarely something the user can just do. It might depend on:

an appointment with a third party,
a document held by someone else,
a certificate that must be requested, issued, posted, scanned, and certified,
a process with its own multi-week turnaround.

None of that happens synchronously just because the applicant wants it to.

So a good workflow has to distinguish between two states that look identical on the surface but are completely different:

"The user hasn't done this yet." (Their responsibility. Nudge them.)
"The user cannot currently do this because another process hasn't completed." (Not their responsibility. Wait, don't penalize.)

A three-month non-refundable countdown that assumes every dependency is under the user's control is modeling the wrong reality. It's charging people for the latency of institutions they don't control.

Accessibility isn't only screen readers

Here's a distinction I wish more teams internalized: accessibility is not just a property of the UI. It's a property of the workflow.

A service can have perfect semantic HTML, keyboard navigation, ARIA labels, screen-reader support, and AAA contrast — and still be functionally inaccessible, because the underlying process is confusing, unforgiving, and impossible to recover from.

A workflow that quietly assumes users can instantly obtain every prerequisite, infer every unstated dependency, remember every required document, and correctly reinterpret an ambiguous yes/no question is already fragile for everyone. For anyone dealing with cognitive load, memory difficulty, limited resources, or dependence on third parties, that fragility stops being an inconvenience and becomes a wall.

You can pass every automated accessibility audit and still ship something that's impossible for a real person to complete safely. GOV.UK's design system is genuinely excellent at the component level. This failure lives one layer up, in the workflow, where the audits don't look.

What a fail-safe version would do

None of this is exotic. Concretely:

Dependency-aware questions — a gating answer visibly changes the journey instead of blending in.
Hard eligibility gates — invalid state stops at detection, not at checkout.
Explicit prerequisite explanations — say why you're blocked and how to fix it.
Persistent, resumable progress — don't force people to gamble against a clock they don't control.
Pre-payment validation — establish eligibility before taking money, always.
Asynchronous dependency states — model "waiting on someone else" as a first-class status.
Human escalation paths — a real route to intervene when the machine gets it wrong.
Rollback where the system permitted an invalid transaction — if the service let money through in a state it should have blocked, the refund is the system's responsibility, not the user's problem.

The uncomfortable question

So here's where I'll leave it.

If a system lets a user make an error, already holds enough information to recognize the consequences of that error, allows the error to propagate through the entire workflow, accepts payment, and then refuses to let the user recover — where exactly did the error occur?

It did not occur the moment the user clicked the wrong button.

It occurred when the system was designed without a safe state in which that mistake could be recovered from.

That's the bug. Everything else is just where it happened to surface.