Fabian Braun

Translating a page is solved. Keeping it translated isn't.

2026-10-10T00:00:00+02:00

In 2026, translating a page costs one click and a few cents.

Almost every CMS has a DeepL integration or an AI plugin by now, and every LLM will translate whatever you paste into it, in any tone you ask for. If your problem is “I have an English page and I need a German one”, that problem is solved, and solved well.

So why do multilingual sites still feel like a chore? Why does every agency I talk to have a story about the French version that was “a bit behind” for half a year?

Because the hard part was never the first translation. It’s every day after it.

The day after launch

Here’s how it usually goes. The site launches in English, German and French. Everything is translated, reviewed, published. Everyone is happy.

Three weeks later, marketing changes the pricing paragraph on the English page. Someone updates the German page, because the German market matters this quarter. Nobody touches the French one. Nothing tells anyone that it is now wrong.

A month later, the blog gets a new post. The blog is a separate module, translated with a different tool, by a different person, and the product is called “Starter plan” on the pages and “Basic package” in the blog.

Half a year later, someone adds Polish. Three hundred pages, a blog, a product catalog. The translation button works on each page. It doesn’t tell you which three hundred pages, or what it will cost, or which of them were going to change next week anyway.

None of this is a translation problem. Every single sentence was translated perfectly. It’s a state problem: nobody knows what is current, what is behind, and what is inconsistent.

It’s not a made-up story

That story is invented, but the problems aren’t. Read the public issue trackers of open-source CMSs and their translation plugins, and the same complaints come up again and again, from agencies, in-house teams and single developers. All quotes below are real.

“Which pages are out of sync?” An agency asked for a table with “the languages” as columns and “the status of translation” for every page, because “once you lost track it nearly impossible to track it down if you have many pages”. A team with tens of thousands of machine-translated pages wrote that they “need to see the number of Pages that have manual translations”, and that it took SQL queries against the database to find out. Others just want the editing screen to show which language tabs are still empty.

“I changed a comma and the translation is gone.” One team reported that changing the source “just deletes the previous translation without fallback … even if it’s just a small change like a comma missing”. Another put it more bluntly: “translated strings are repeatedly lost when a user changes the source string. This makes regular users REALLY angry!”

“Half-translated pages go live.” A developer found that the only way to apply translations to a page was to publish it: a page that’s halfway translated can’t be saved as a draft. Another, adding Spanish to an English site, found that “all the Spanish pages will be instantly published, and will use the English content”.

“We wrote our own script.” One developer was trying “to automate the translation of a … website with hundreds of pages” and set out to write a script that sends everything to DeepL. Others ask for empty fields to be filled by a local LLM in the background. Every team builds, or wishes for, the same plumbing.

“And what about everything that isn’t a page?” Products, reusable content blocks and other data outside the page tree don’t fit the page-based workflow, an agency explained; others asked for a way to filter that content by translation status at all.

One agency summed it up: “The top customer complaint we get is probably that the sync does not work.”

Four things a translate button can’t know

When I list what goes wrong after the first translation, it falls into four groups.

1. Currency: which translations are out of date? To know that the French pricing paragraph is stale, something has to remember which version of the English text the French one was made from. A button that translates on demand has no such memory. It translates; it forgets.

2. Consistency: are we saying the same thing everywhere? Product names, legal terms, the formal or informal “you” (Sie or du, vous or tu). Each translation is reasonable on its own; together they contradict each other. Consistency needs a glossary and a memory of how we translated things before, shared across every place where content lives.

3. Control: who decided this is ready? Machine translation is good enough to be dangerous. It reads fluently, so nobody checks it. A broken link, a mangled placeholder, an alt text that says nothing, a brand name translated into a common noun. The fix isn’t to avoid machine translation; it’s to make sure nothing is published without a person approving it, and that obvious errors are caught before that.

4. Coverage: is all the content in the picture? Pages live in the CMS. The blog is a separate module. Products live in a shop or a catalog database. Most tools see one of these. The editor sees all of them, and so does the visitor.

What these four have in common: they need memory over time. Which source text was each translation based on? Which terms did we agree on? What did a person approve, and when? Which content exists in which languages?

A plugin that runs when you click a button is stateless by design, and that’s fine for what it does. But the work that eats agencies’ time is stateful.

What I’d want as an editor

Strip away the technology, and what an editor needs is surprisingly simple:

A list of what’s behind, per language: “French: 12 texts out of date, 3 missing.” Not a feeling, a list.
One action to fix it: retranslate exactly those texts, nothing else, and put the results somewhere I can review them. A draft, not a published page.
The same words everywhere: if I decide that “Starter plan” is “Einstiegstarif” in German, that decision applies to the pages, the blog and the product catalog.
Errors caught before I see them: a link that disappeared, a placeholder that broke, a meta description that’s now 240 characters long.
For agencies: the same overview across every client site, so the question “which client is behind?” has an answer before the client asks it.

None of this is exotic. It’s how software teams have handled translations of interface texts for decades: translation files know when a source string changed and mark the translation as fuzzy, to be checked, instead of throwing it away. Content never got the same treatment, because content lives in many places, many formats and many tools.

What makes it hard

If it’s so obvious, why doesn’t every CMS do it?

Because “which version was this translated from?” is harder than it sounds once content is structured. A page is a tree of components or blocks, often with new IDs every time a new version is saved. One system stores translations as extra rows, the next as extra columns, a third as JSON in a single field. To say “this paragraph in French is stale”, you need a stable identity for every translatable piece across versions, languages and storage formats, and a reliable way to tell whether its source changed.

That’s plumbing. It’s not glamorous, and no single plugin has a reason to build it across all the places content lives.

What I’m building

Disclosure: I’m the django CMS fellow, and what follows is my own project, Ponyglot, not a django CMS Association product.

Ponyglot is that plumbing, for sites built on Django: open-source connectors for django CMS, Wagtail, django-parler and django-modeltranslation extract every translatable field into one model, where each piece has a stable key and a fingerprint of its source text. Taking the problems above one by one:

“Which pages are out of sync?” A matrix per page of what’s up to date, stale, in review or missing, per language; a stale overview per site; and the same counts across all your sites. Content outside the page tree gets the same status as pages.
“I changed a comma.” The text shows as stale, like a fuzzy entry in a translation file. The live translation stays until a new one is approved, and translations an editor wrote by hand are never overwritten.
“Half-translated pages go live.” Results arrive as drafts, or as suggestions with a diff for content that has no drafts. Publishing is the approval; nothing is published automatically.
“We wrote our own script.” “Translate stale and missing” is one action, with a cost estimate first, from the dashboard, the CMS admin or the command line.
“Everything that isn’t a page.” Pages, blog, products and other content share one glossary, one translation memory and one status.
And QA checks for links, placeholders, HTML, length and SEO flag errors before anything is published.

It doesn’t solve everything. Preparing a change as a draft in the source and the translations at the same time, one of the most-requested wishes, is still open: Ponyglot translates the published source. Regional variants derived from a parent language (French for Belgium from French for France) aren’t modelled yet either.

The translation itself is the boring part: DeepL or an EU-hosted LLM, whichever fits the language. The free tools are great at it, and I’d rather work with them than against them.

We’re onboarding a small group of agencies and product teams now. If your multilingual site has a French version that’s “a bit behind”, I’d love to hear how you handle it today: ponyglot.app.

Next in this series: how to know which translations are stale, with fingerprints and a few lines of code.

AI Doesn't Replace Engineering. It Moves It Up the Stack.

2026-10-07T00:00:00+02:00

In Open Source Is Dying Again, I argued that when code becomes abundant, architecture counts. That was a claim about what becomes scarce. This one is about the mechanism behind it, and where it leads if you keep following it.

The usual debate is whether AI can replace engineers. I think that’s the wrong question. “It can’t, because it makes mistakes” ages badly with every model release. “It can, look at this demo” ignores everything that happens after the demo. The more useful observation is this:

Every layer we successfully automate makes the layer above it the new bottleneck.

Following the bottleneck

Not long ago, the expensive step was writing the implementation. AI tools now take a large part of it, and agentic workflows extend the chain until routine maintenance runs largely on its own:

problem → implementation → tests → documentation
issue → diagnosis → implementation → tests → pull request
dependency update → compatibility analysis → fixes → CI → release candidate

Excellent. We should automate all of it. There is no reason to keep repetitive mechanical work manual just for its own sake; the version pins will not miss us.

Once the pull request appears by itself, the question that takes the time is no longer how do I write this? but should we merge it? So we automate much of the review as well — architectural analysis, compatibility risks, a suggested decision — and the bottleneck moves again:

Should we merge it?
  → Does this belong in the product?
    → What should the product become?

Each step is real progress. Each also moves the remaining work somewhere harder to describe, harder to measure, and harder to hand over.

An issue that fixes itself

Take a mature library and an ordinary issue:

Feature X doesn’t work on Python 3.15.

An agent can plausibly handle all of it. It reproduces the failure, finds the change in Python that caused it, adapts the implementation, adds a regression test, runs the compatibility matrix, writes a changelog entry, and opens a pull request.

Measured by the activities we used to call engineering, almost nothing is left to do.

Yet someone still has to decide whether Python 3.15 should be supported yet. Whether the fix preserves compatibility for every user, not only for the test suite. Whether the changed abstraction is the right one, or merely the one that made the tests pass. Whether this warrants a release, and whether downstream projects need to know before it ships.

The code alone doesn’t determine any of these answers. They also depend on the project’s history, its users, its promises, and where it is going. Much of the engineering in this example is genuinely gone. What remains has moved up.

We have done this before

That pattern is not new. Every major advance in software engineering has removed work developers at the time considered essential. Compilers removed most assembly programming. Garbage collection removed manual memory management from most application code. Frameworks removed enormous amounts of plumbing. Cloud platforms and managed databases removed much of the work of running servers and keeping them alive.

Much of that difficulty didn’t move anywhere. It disappeared. Nobody mourns that web developers no longer allocate registers or implement TCP, and nobody had to pick that work up elsewhere.

But none of these steps eliminated engineering. Developers stopped worrying about memory layout and started worrying about data models, latency, consistency and user experience — problems that were always there, but out of reach behind the work of getting anything to run at all.

Some difficulty disappears entirely. What remains moves upward.

AI is another step in that progression, unusual mainly in its size and speed. It can genuinely eliminate large amounts of engineering work. The question is what remains, and where it goes.

From code to intent

The question used to be: how do I implement this? Increasingly it is: what exactly should happen?

I rarely write tests from scratch anymore. I still decide what needs testing, which behaviour is a contract, and whether a test proves what it claims to prove. Typing the fixtures and assertions is increasingly a machine’s job. Oddly, that hasn’t made me think less about testing — only at a different level.

A vague ticket used to be partly self-correcting: a developer would run into the awkward case and come back with a question. Implementation was slow enough to double as discovery. An agent working from the same ticket produces, quickly and confidently, a beautifully implemented version of the wrong thing.

So more of the work goes into expressing intent precisely. That isn’t prompt engineering. It is the part of engineering we used to do implicitly, while typing.

From implementation to boundaries

When you can build almost anything, what not to build matters more. Should this be in the core or an extension? Is this an API, or a detail that should stay free to change? Do these two things share an abstraction, or just look similar today?

AI is very good at producing abstractions when asked. It is much less useful at telling you whether you should have one in the first place.

Boundaries were always the expensive decisions: you can’t cheaply undo them once others depend on them. When the code inside them becomes cheap, the boundaries are most of what’s left.

From components to systems

This is the change I find most interesting.

Instead of spending an afternoon implementing one component, I can spend it exploring three approaches. An agent prototypes each one. Another generates the migrations, writes integration tests, and checks what breaks for existing users. I read the results, throw two away, and keep the parts of the third that worked.

AI doesn’t merely make the same engineer faster. It changes the size of the thing an engineer can hold and manipulate.

Not long ago, I mostly manipulated functions. Then modules. Increasingly, whole subsystems: I can ask what would happen if a layer worked differently and get an answer in the form of working code, not a diagram and a guess.

That is a different job, not a faster version of the old one.

Architecture becomes executable

Historically, architecture was expensive to test. You could argue for approach A or approach B, but building both properly might take months. So architectural decisions rested heavily on prediction: the most experienced person in the room imagined how each option would behave under load, under change, and under five years of feature requests.

If prototypes become cheap enough, architecture becomes increasingly empirical.

Instead of three meetings about whether an approach will work, have agents build representative slices of both. Benchmark them. Write the ugly cases. Simulate the migration from the current system. Try next year’s likely feature request and see which design absorbs it.

That doesn’t make experience worthless. Experience is what tells you which slices are representative and which ugly cases matter. And it changes what the valuable skill is: when producing answers becomes cheap, knowing which uncertainty is worth spending computation on becomes the scarce part. Seniority may come to mean less knowing the answers, and more knowing which questions are worth paying to answer.

It doesn’t stop at architecture

So far, this sounds like an argument that architects are safe. I don’t think the movement stops there.

Imagine software maintenance that is close to autonomous. Agents watch dependencies, fix regressions, review each other’s changes, prepare releases and monitor production. Architectural analysis is excellent, and the suggested decisions are usually right.

What is left is product judgment. Which users matter most when their needs conflict? Which incompatibilities are worth imposing? Which architecture enables the next five years rather than the next release? Which feature request is a local requirement that should stay out of the core? When should an old abstraction finally be allowed to die?

There is an old word for the people who make those calls on a long-lived system: stewards. A steward carries enough context to know why the system looks the way it does, enough authority to decide where it goes next, and enough continuity to live with the consequences. None of those three is a property of code, and none of them is produced by producing more of it.

Now suppose AI becomes excellent at recommending product decisions too. It models the user base, simulates migration costs, and proposes a roadmap better argued than most human ones.

What is left then is accountability. Someone still has to decide whose interests the system serves, and answer for it when those interests conflict. Accountability isn’t primarily a capability. It is a role. It exists because the people affected by a decision need someone who can be asked, persuaded, challenged, overruled or replaced.

Followed all the way through, the stack looks like this:

code → intent → boundaries → architecture → product judgment → accountability

Each layer was always there. What changes is how much of the work sits in it.

The uncomfortable part

None of this means every engineer is fine.

The risk isn’t that engineering disappears. It’s that engineers keep working at the old layer while that layer is automated underneath them.

Someone who describes their job as

I turn tickets into Python.

has a problem, because that description is now a reasonable specification for software.

Someone who describes it as

I understand this domain well enough to turn ambiguous needs into systems that survive contact with reality.

has suddenly acquired extraordinarily powerful tools.

There is a harder question hidden here. Nobody is born with context. People learned to work at the higher layers by spending years at the lower ones: fixing bugs in unfamiliar corners of a codebase, writing tests that reveal how a system really behaves, implementing small features and watching them collide with large ones. That work was never only output. It was also how people learned what the output meant.

There is a paradox here: AI may make experienced engineers dramatically more capable while making it harder for inexperienced engineers to become experienced.

If agents now do that work better, AI doesn’t only move engineering upward. It may remove the ladder people used to climb to get there. Learning will have to happen more deliberately — closer to the people who already carry the context, as programs like Djangonaut Space already practise. That is a real problem. But it is a problem of how we pass on the craft, not a sign that the craft is going away.

Code was never the decision

We have been moving up the stack for as long as software engineering has existed.

AI is unsettling because the layer being automated this time is the one many of us identify as engineering itself: writing code. For a generation of developers, the code was the work, and being good at it was being good at the job.

I suspect that identification will come to look as strange as equating programming with register allocation.

Code is one representation of an engineering decision. It has never been the decision itself.

If machines become extraordinarily good at producing the representation, we get to spend more of our time on what mattered all along: understanding what should exist, how its parts should fit together, and who answers for the choices we make.

AI doesn’t replace engineering. It moves it up the stack.

One Operation, Three Interfaces: A Service Architecture for django CMS

2026-10-05T00:00:00+02:00

How shared content operations could support editors, REST integrations, and AI tools.

Read on django-cms.org ↗

Receiving and Parsing XRechnung Invoices in Django

2026-10-03T00:00:00+02:00

Since January 2025, every business in Germany must be able to receive electronic invoices. Not PDFs attached to an email, but structured invoices following the European standard EN 16931: XRechnung in its UBL or CII syntax, or a hybrid format such as ZUGFeRD/Factur-X, where the XML travels inside a PDF. The obligation to send them phases in during 2027 and 2028. The obligation to accept them is already here.

Most of the discussion so far has been about sending. That makes sense: issuing an invoice is something you control. You choose the format, you generate the XML, you run the validator, and if it fails you fix your own data.

Receiving is a different problem. You get whatever your suppliers’ software produces. Some of it is excellent. Some of it is a PDF with an XML attached that disagrees with the PDF. Some of it isn’t an invoice at all.

I have been building django-xrechnung, a reusable Django application for issuing and receiving XRechnung documents. The outgoing side took most of the code. The incoming side took most of the thinking. This article is about that thinking — for Django developers who will build something similar, and for the people who will have to decide what their business does with the invoices that arrive.

An incoming e-invoice is three things at once: untrusted input, legal evidence, and business data. Most implementations only treat it as the third.

A received invoice is a file someone else wrote

The naive implementation of “receive an XRechnung” looks something like this:

def upload_invoice(request):
    tree = etree.parse(request.FILES["invoice"])
    Invoice.objects.create(
        number=tree.findtext(".//cbc:ID", namespaces=NS),
        total=Decimal(tree.findtext(".//cbc:PayableAmount", namespaces=NS)),
        ...
    )

Every line of it is a problem.

It parses arbitrary XML inside your web process, with whatever entity and DTD handling your parser defaults to. It trusts a file upload’s size. It throws away the original. It picks the first cbc:ID it finds, which may not be the invoice number. It turns the document into a model, so the moment someone edits that model, your database no longer says what your supplier sent you. And if anything after etree.parse fails, nothing is stored at all: the supplier believes they delivered an invoice, and you have no trace of it.

django-xrechnung’s inbound side is, to a large extent, the systematic removal of those assumptions. It is organized around a small number of rules.

Rule 1: Commit the receipt before you look at it

The first thing the app does with incoming bytes is store them. Not parse, not validate — store.

checksum = hashlib.sha256(original).hexdigest()
# A committed row exists before any untrusted parsing or validator execution.
with transaction.atomic(using=using, durable=True):
    document, created = ReceivedDocument.objects.get_or_create(
        inbox=inbox,
        sha256=checksum,
        defaults={"original": ContentFile(original, name="receipt.bin"), ...},
    )
if created:
    _attempt(document.pk, using, settings, limits)

Everything that can go wrong afterwards — malformed XML, a validator that is down, a PDF that explodes when decompressed, a bug in my own code — happens after a durable record exists that this document arrived, when, and in which inbox.

That has a consequence that is easy to trip over: ingestion refuses to run inside an enclosing transaction. If your project sets ATOMIC_REQUESTS = True, the upload view must be non-atomic. Otherwise an exception during validation would roll back the receipt along with everything else, and you would be back to “the supplier sent it and we have no record”. The durable=True flag turns that from a convention into an error.

For developers, the general lesson is: separate admission from processing. Admission must be cheap, bounded, and nearly impossible to fail once the bytes are in hand. Processing can fail as often as it likes, as long as it can be retried.

Rule 2: Treat invoices as hostile input

An invoice arrives from outside your organization, often by email, in a format designed for machines. That is a description of an attack surface.

XML brings its classic problems: entity expansion, external entities, absurd nesting. PDFs bring their own: compression bombs, cyclic object trees, attachments inside attachments. And the official validator from KoSIT, the coordination office that publishes the XRechnung rules, is a Java program you have to start with the untrusted file as input.

So all inspection in django-xrechnung runs in a separate, resource-limited worker process:

The XML parser is a pull parser with entity resolution, DTD loading and network access disabled. Depth, total bytes and the number of embedded attachments are counted while streaming, so a limit triggers before the whole tree exists in memory.
PDF extraction caps every decompression filter’s output and rejects compression filters it doesn’t expect.
The worker sets RLIMIT_AS, RLIMIT_CPU and RLIMIT_FSIZE on itself — in a fresh process, never via preexec_fn inside a threaded Django server.
The parent drains stdout and stderr into bounded buffers and enforces a wall-clock deadline shared across all steps.

The least glamorous part was killing processes correctly. The worker runs in its own session so that the whole process group can be terminated, including any children that kept the pipes open. But if you reap the child first, its pid can be recycled, and your killpg can hit an unrelated process. The fix is to check for exit with waitid(..., WNOWAIT), which reports that the child exited without reaping it. It is a few lines of code, and exactly the kind of detail nobody gets right on the first attempt.

None of this is specific to invoices. But invoices make it non-optional, because accepting them is now a legal obligation. You cannot simply refuse documents from senders you don’t trust.

For business readers: this is also why django-xrechnung validates locally. Online validators are convenient, but every invoice you upload there discloses your supplier relationships, prices and bank details to a third party. Running the validator on your own infrastructure costs a Java installation. Not running it locally costs you control over who sees your purchasing data.

Rule 3: The original is the record

German tax law requires invoices to be kept in the form in which they were received, for the statutory retention period, currently eight years. For an e-invoice, that form is the XML file — or the hybrid PDF with its embedded XML. A table of extracted fields is not the invoice. Neither is a nicely rendered HTML view of it.

So received documents are immutable in django-xrechnung, and Django makes that easier to enforce than you might expect:

class EvidenceQuerySet(models.QuerySet):
    def update(self, **kwargs):
        raise ValidationError("Receipt evidence cannot be updated.")

    def delete(self):
        raise ValidationError("Receipt evidence cannot be deleted through the app.")


class ImmutableEvidence(models.Model):
    objects = EvidenceQuerySet.as_manager()

    def save(self, *args, **kwargs):
        if not self._state.adding:
            raise ValidationError("Receipt evidence is immutable; append a new attempt.")
        kwargs["force_insert"] = True
        return super().save(*args, **kwargs)

bulk_create and bulk_update are blocked as well, foreign keys use PROTECT, and the admin offers no edit or delete actions. The original bytes live in Django storage, so they can be backed up, replicated or moved to cold storage like any other file, and their SHA-256 stays in the database.

It is important to be honest about what this does and doesn’t achieve. It prevents the application from rewriting evidence by accident, which is where almost all real-world damage comes from. It doesn’t stop a database administrator, and the hashes are integrity metadata, not signatures. Documentation that claims more than the code delivers is its own compliance risk.

The same principle extends to processing. A validation run is a ValidationAttempt, and attempts are immutable too. If the validator was misconfigured and you fix it, you retry, and the retry appends a new attempt. The history of what you checked, when, with which validator and rule versions, is preserved.

Rule 4: Decide what “the same invoice” means

Suppliers resend invoices. Mail servers deliver twice. Someone uploads the same file again because they weren’t sure the first upload worked.

django-xrechnung deduplicates by content: an inbox can contain a given sequence of bytes only once, enforced by a unique constraint on (inbox, sha256). Re-ingesting identical bytes returns the existing receipt with created=False, doesn’t reprocess it, and — just as important — doesn’t fire the document_received signal again. To a host application listening for new invoices, a resubmission must not look like a second arrival.

But byte identity is a deliberately narrow definition. A supplier who regenerates an invoice produces different bytes for what is, commercially, the same invoice: a new timestamp in the XML is enough. Recognizing that as a duplicate requires business rules — same supplier, same invoice number, perhaps same amount — and those differ between organizations.

For business readers: byte-level deduplication protects you from technical duplicates. It does not protect you from paying the same invoice twice. That check belongs in your accounts-payable process, and it needs an owner.

Rule 5: Four outcomes, not one

The most important design decision on the inbound side was to stop asking “is this invoice OK?”

Each processing attempt records four independent states:

Processing: did the pipeline run to completion, or did a timeout, a missing validator or a resource limit stop it?
Validation: do the official schema and business rules (KoSIT’s Schematron for XRechnung, or the Factur-X rules for that profile) accept the XML?
Parsing: could the values be extracted unambiguously?
Reconciliation: do the amounts add up?

Each of them can also be unsupported, unavailable or not_run, and those are deliberately different from rejected. A validator that isn’t installed doesn’t make an invoice invalid. A profile the app doesn’t know yet isn’t a failed check. Collapsing all of that into one boolean is how systems end up rejecting good invoices whenever Java is missing — or, worse, accepting bad ones because a check silently didn’t happen.

“Valid” means the format is right. It doesn’t mean the invoice is correct, and it certainly doesn’t mean you should pay it.

The KoSIT validator checks a great deal, including many arithmetic rules. But it can’t know whether you ordered these goods, whether the price matches your contract, or whether the bank account is the one your supplier has always used. That is not a failure of the validator. It is the boundary between format and business, and it is worth making visible in the software rather than letting “green checkmark” stand in for “approved”.

Rule 6: Parse into snapshots, not models

Once a document is validated, it is tempting to load it into your own invoice model. django-xrechnung deliberately doesn’t. Parsed values are stored as a versioned JSON snapshot on the attempt, and received documents can never be turned into outgoing invoices or edited.

Three details matter more than they look.

Values stay as they were written. Amounts, quantities and dates are kept as the exact strings in the XML. Converting "19.00" to a Decimal or a CII date like 20261003 to a date is something a consumer can do when it needs to. A snapshot that has already normalized values can no longer show what the supplier asserted.

Nothing is silently dropped. EN 16931 is large, XRechnung adds to it, and real suppliers add more. The parser reads the fields it knows, and every leaf element and attribute it did not consume is listed in unmodeled together with its XPath. A tolerant parser that ignores what it doesn’t understand looks robust, but it hides information that could matter, such as a document-level discount you didn’t model. Listing what you didn’t read is cheap and makes the gap explicit.

Ambiguity is an error. If a field that should occur once occurs twice, parsing is rejected rather than taking the first value. findtext() happily returns the first match. In an invoice, “the first match” can be the wrong number.

For CII, I used the maintained drafthorse reader to check the document, but take values from the original tree. Libraries that bind XML to objects tend to normalize on the way in, and you never want to serialize a received invoice back from a binding. The original XML stays authoritative; everything else is a view on it.

Rule 7: Reconcile what you can, and say what you can’t

Reconciliation recalculates what can be recalculated: line net amounts from quantity and price, tax bases per VAT category, VAT per group, and document totals. It uses Decimal with cent rounding and ROUND_HALF_UP, and records each comparison with the asserted and the expected value, so that a mismatch can be shown to a person rather than reported as “invalid”.

Just as important is what it refuses to do. Document-level allowances, prepayments, rounding amounts, foreign currencies and VAT rates other than Germany’s 7% and 19% currently make reconciliation unsupported, with a reason. Factur-X MINIMUM and BASIC WL invoices don’t carry line details at all, so there is nothing to reconcile them against.

A partial check never reports success. If I can check the lines but not the document-level discount, the honest answer is not “the lines matched”. It is “I couldn’t verify this invoice; here is why.”

For business readers: plan for an exception queue from day one. Some fraction of incoming invoices will be unsupported by any given tool — an unusual profile, a PDF without embedded XML, two XML attachments where there should be one. A system that tells you which invoices need a human, and why, is far more valuable than one that claims to handle everything.

The PDF is a picture of the invoice

Hybrid invoices deserve their own section, because they cause the most confusion.

A ZUGFeRD or Factur-X invoice is a PDF that humans can read, with an XML file attached that machines can read. For tax purposes in Germany, the structured part is authoritative. The PDF is a rendering of it — ideally a faithful one.

django-xrechnung extracts the embedded XML in the isolated worker, looking both in the PDF’s embedded-files tree and its associated files (/AF), counting a file that appears in both only once. It requires exactly one XML candidate. If there are two, it doesn’t pick one by filename; it marks the document unsupported and asks for review. Encrypted PDFs and PDFs without XML are retained, but not processed. There is no OCR.

And — this is the part I most want business readers to take away — the app does not check that the PDF says the same thing as the XML. That is a hard problem, and a validated XML says nothing about it. If your team approves invoices by looking at the PDF while your accounting system books the XML, you have two versions of the truth and no one comparing them.

Pinning the rules you checked against

The XRechnung rules change. KoSIT publishes new validator configurations, Factur-X publishes new Schematron, and a document that passes today might not have passed a year ago, or vice versa.

So django-xrechnung pins both. The KoSIT installation is verified against a manifest of file hashes; the Factur-X rules are pinned to a specific version of the factur-x package and checked against bundled hashes before use. Every attempt records the validator version, the rule version and the hash of the scenario configuration it used.

Running KoSIT turned out to be its own small project. It compiles every scenario’s Schematron at startup, which dominates the runtime of a single validation. Building the smallest configuration that serves each route — UBL Invoice, UBL CreditNote and CII for XRechnung, a single scenario per Factur-X profile — made a noticeable difference. For higher volumes, the app can talk to a long-running KoSIT daemon instead, which pays the startup cost once. The evidence then records that a daemon was used, because the application can’t inspect the configuration the operator started it with, and pretending otherwise would be a false claim.

For business readers: “we validated it” is only meaningful together with “against which rules, on which date”. If an auditor asks in five years why you accepted an invoice, the report and the rule version you checked it against are your answer.

What I would tell a Django team starting this

If you are about to build e-invoice receiving into a Django project, or deciding whether to adopt something like django-xrechnung, these are the points I would put on the whiteboard:

Store first, process second. The receipt must commit before any untrusted parsing begins. Watch out for ATOMIC_REQUESTS.
Isolate parsing and validation. Separate process, resource limits, no entity resolution, bounded output. Accepting invoices is mandatory; trusting them isn’t.
Make evidence immutable in the ORM. Override save, delete and the queryset’s bulk operations, use PROTECT, and append rather than update.
Keep outcomes separate. Processing, validation, parsing and reconciliation answer different questions. unsupported and unavailable are not rejected.
Snapshot, don’t import. Keep asserted values as strings, list what you didn’t read, and reject ambiguity instead of guessing.
Use Decimal and say what you didn’t check. A partial reconciliation must never look like a pass.
Pin and record your rules. The validator version is part of the evidence.

And for the business side:

Receiving is already mandatory. If your process still assumes invoices arrive as PDFs to be typed in, it is behind the law, not ahead of it.
The XML is the invoice. Approve what you book, and be aware of when people look at the PDF instead.
Valid isn’t payable. Format validation removes one class of error. Contract, delivery and bank-detail checks are still yours.
Expect exceptions, and staff them. The right tool tells you which invoices need a person and why.
Keep the original and the evidence. Eight years is a long time to explain a decision without records.
Know where your invoices go. Validating locally keeps purchasing data inside your organization.

Why this belongs in a reusable application

None of the rules above is exotic. But each of them takes time to discover, usually after something has gone wrong: the receipt that disappeared in a rolled-back transaction, the duplicate that was paid twice, the validator outage that marked a week’s worth of invoices as invalid.

Every German business running on Django will need to solve this problem, and most of them will be solving it for the first time. That is exactly the situation I described in Stop Rebuilding the Same Django App for Every Client: recurring knowledge that should accumulate in software instead of being rediscovered project by project.

django-xrechnung is open source under the BSD license, currently in beta, and its documentation covers the receiving workflow in detail. Its scope is still limited — German parties, EUR, and a defined set of profiles — and it says so in its supported-invoice reference rather than pretending otherwise.

If you are receiving e-invoices in Django, I would like to hear what arrives in your inbox. Especially the invoices that don’t fit.

Open Source Is Dying Again

2026-09-28T00:00:00+02:00

Open source has died many times already.

It was supposed to die when large companies decided it was a threat. It was supposed to die when those same companies decided it was a business model. It was supposed to die when cloud providers started offering managed versions of projects they did not maintain, and again when projects responded by switching to licenses that were no longer open. Every few years, someone discovers that the maintainers of critical infrastructure are unpaid and exhausted, and the obituaries get written once more.

And yet the ecosystem kept growing.

So I am suspicious of anyone announcing the end of open source. But I also think this time is different, because the thing that is changing is not a business model or a license. It is the cost of the work itself.

AI has not killed open source. It has killed the bargain that open source contributors thought they had made.

The old bargain

Nobody ever wrote the bargain down, but most contributors understood it.

You publish your work. Others may use it, study it, change it, and often build businesses on it. In return, a few things hold. Your name stays attached to the work. The license sets the terms under which others reuse it. And the quality of your contributions becomes visible: you build a reputation, and that reputation turns into jobs, invitations, clients, and influence.

None of this was ever guaranteed. But it was stable enough that people chose to take part.

At its core, the bargain was about reciprocity, though never of the one-to-one kind. Nobody paid back the specific person whose library they used. You took from the commons and gave back to the commons. Anthropologists call this generalized reciprocity: it works across a whole community rather than between two parties. That is why it survived obvious free-riding. Enough people gave back, and everyone was also a user of everyone else’s work.

Open source never relied on goodwill alone to keep that going. Licenses made reciprocity a legal obligation, at least for attribution and, with copyleft, for sharing changes. Reputation made it visible. And economics made it sensible.

Each of those assumptions is now under pressure.

Copying has become cheap

Open source always depended on a subtle economic fact: even with the source code available, reproducing a mature project was expensive.

You could read every line of Django. That did not mean you could build a comparable framework over a weekend. The value was not only in the code but in the thousands of decisions embedded in it, and understanding those decisions took time. So it was usually cheaper to use the project, and often to contribute back, than to rebuild it.

That cost has collapsed.

A model trained on public code can produce something that looks very much like the solution a project arrived at over years, adapted to a slightly different context, in minutes. The patterns, the idioms, the carefully chosen boundaries are all available as raw material. Work that once required a developer to understand and reproduce an implementation can increasingly be generated from a description of the desired result.

The incentive to use the original, and with it the incentive to contribute to it, becomes weaker.

This matters more than it seems, because contributing back was rarely pure altruism. Companies upstreamed their patches because maintaining a private fork was expensive. Every new release meant merging their changes again, so giving the changes to the project was the cheaper path. Reciprocity was, to a large extent, simply the rational choice.

AI lowers the cost of maintaining divergent code as well. If a private variant can be regenerated or re-adapted cheaply, the economic pressure to contribute back weakens. Copyleft enforced reciprocity through law, the cost of forking enforced it through economics. Both are eroding at the same time.

Licenses without effect

Licenses were the legal backbone of the bargain. Even the most permissive ones usually ask for one thing: keep the copyright notice, credit the authors.

AI-generated code does not do that. It does not reproduce a project; it reproduces what it learned from many projects, recombined. There is no notice to keep, because there is no identifiable copy. The attribution requirement, the one condition nearly all open source licenses share, simply has nothing to attach to.

Copyleft licenses face the same problem in a sharper form. Their strength was that derived work had to remain open. But if the derivation passes through a model, is the output derived work? Maybe. Probably, in some cases. Proving it is another matter.

Rights you cannot enforce

Even where a claim exists, enforcing it is close to impossible.

To enforce a license, you need to show that your work was copied, by whom, and in violation of which terms. With AI-generated code, the copying happens inside a training process you cannot inspect, and the output appears in codebases you will never see. The individual maintainer has no realistic way to find out, and even less of a way to pursue it.

Rights that cannot be enforced are, in practice, suggestions.

Reputation that never arrives

For many contributors, reputation mattered more than licenses. Very few people have ever sued over open source. Many people built careers on it.

That is eroding too. When someone uses a well-known library directly, they see the name of the project and, sometimes, its authors. When someone receives an AI-generated implementation of the same idea, they see nothing. The knowledge still travels. The credit does not.

The work still matters. It just no longer makes the person who did it visible.

Seen together, licenses and reputation served the same purpose: they made reciprocity traceable. They connected a piece of work to the people who created it, so that credit, obligations, and opportunities could flow back to them. Once that trace disappears, reciprocity has nowhere to go. You cannot give back to someone you don’t know you took from.

Someone always made the money

It would be easy to stop here and conclude that open source is finished. I don’t think that is right, because the bargain was never as fair as we pretended.

Someone has always been making money from open source work, and it was rarely the people doing the work. Companies built products on top of volunteer projects. Cloud providers sold hosted versions of software they did not write. Consultants and agencies, myself included, earned a living by applying open source to their clients’ problems. Most maintainers received a fraction of the value their work created, if anything at all.

AI makes this imbalance more visible and more extreme. But it did not invent it.

It also concentrates it. For more than a decade, open source has effectively meant GitHub, and the company that hosts much of the world’s public code is now also selling AI coding tools trained on public code. The place where the work is shared and the business that profits from learning from it are no longer clearly separate. Moving to community-run forges such as Codeberg, as I am currently doing with my personal repositories, does not guarantee to take any code out of a training set. But it keeps the infrastructure of open source under the governance of the people who use it.

To be fair, contributors do get something back. They use AI tools trained on the commons too, and those tools make them more productive. But that return is mediated and monetized: developers get access to what the commons taught the model, as a subscription. It is still a form of reciprocity, but the relationship has become commercial, and the terms are set by someone else.

What AI changes is which kind of work can be captured cheaply by others. And that points to where contributors should put their effort.

From coder to architect

What becomes cheap is implementation: producing working code for a problem that is already understood.

What does not become cheap is understanding the problem in the first place. Deciding what a system should do and, more importantly, what it should not do. Finding the boundaries that allow a codebase to evolve for a decade. Knowing which abstraction will hold and which one will quietly become a liability. Judging whether a contribution fits a project’s direction, even when it looks perfectly reasonable in isolation.

That is architectural work, and it is increasingly the scarce part.

When code is abundant, architecture counts.

The role of the open source contributor is shifting accordingly: from writing code to shaping systems. From producing implementations to making the decisions that implementations depend on. AI can generate a pull request. It cannot yet take responsibility for where a project is going, or for the community of people who depend on it.

Twenty years of Django

Django is a good illustration of what this means in practice.

It was released as open source in 2005, and it is still one of the most widely used web frameworks two decades later. Comparatively little of its original code survives. The ORM, the template engine, the admin, request handling, and most other parts have been rewritten, some of them more than once. What survived is the architecture: the decisions about how the parts relate to each other.

Many of those decisions were made very deliberately, and some are written down in Django’s design philosophies. Loose coupling between layers. A template language intentionally limited so that business logic stays out of templates. Projects composed of reusable applications, so that functionality can be shared between projects instead of rebuilt for each one. A strict deprecation policy, so that the framework can change without breaking its users every release.

Not every decision was right in hindsight. Early versions contained a good deal of “magic” that had to be removed again. Some abstractions aged better than others, and some are carried along today mainly because removing them would cost more than keeping them.

But the architecture held. It absorbed new versions of Python, a migrations framework, class-based views, a redesigned middleware system, and eventually asynchronous support, without forcing its users to start over. That is not the result of writing a lot of code. It is the result of a community that has spent twenty years carefully deciding which code to write, and which not.

An AI can reproduce Django’s code. What it cannot reproduce is the process that produced it: the discussions, the trade-offs, the rejected proposals, and the people who carry the reasons forward.

Where people grow into that role

Here is the part I find encouraging.

Architectural judgment is hard to learn in isolation. You learn it by working on real systems with a long history, alongside people who have already made many of the mistakes. Most organizations cannot offer that to more than a handful of people.

Open source can.

Mature open source projects are among the few places where anyone can study how long-lived software actually evolves, participate in design discussions, see why decisions were made, and receive feedback from experienced maintainers. That has always been true, but it used to be a side effect of contributing code. Now it may be the main reason to contribute at all.

Programs like Djangonaut Space show what this can look like. They don’t just help people land their first pull request. They pair new contributors with experienced navigators, give them context on how a project works, and help them understand not only what to change but why. That is exactly the kind of knowledge AI does not replace, and exactly the kind of growth that makes contributors more valuable, not less.

It is also reciprocity in its most durable form. Navigators pass on what they once received from the people who mentored them. Open source reciprocity was never really about paying back the person you took from. It was about passing it on. That form of reciprocity doesn’t need a license or an attribution notice, and no model can perform it on anyone’s behalf.

What is dying, and what isn’t

So is open source dying?

The version in which the value of a contribution lay mainly in the code, protected by a license and rewarded with reputation, is in serious trouble. I don’t think it is coming back.

But open source was never only a pile of code. It was also a place where people learned to build software together, where knowledge about how systems should be designed was passed on, and where judgment was developed in public.

That part is not dying. If anything, it has become more important.

The code will be copied. The understanding behind it still has to be earned.

What If Brute Force Produces Insight?

2026-09-19T00:00:00+02:00

OpenAI recently reported that a system involving on the order of 10,000 concurrent AI agents produced a proposed resolution of the Navier–Stokes Millennium Prize Problem. According to OpenAI’s account of the experiment, the effort took about 88 hours, involved 2.7 million agent messages and roughly 130 billion output tokens, followed by another 17 hours of Lean formalization and verification.

The Clay Mathematics Institute describes the problem as “apparently” settled, while emphasizing that its evaluation process is deliberately unhurried. So there is good reason not to treat the story as finished yet.

Still, my first reaction was: that’s an extraordinary amount of brute force. My second reaction was: does it matter?

If the resulting mathematics withstands scrutiny, the proof can be inspected independently of the process that discovered it. We can ask whether each step follows, whether its assumptions are valid, and whether its conclusion is justified. The proof doesn’t remember how it was found.

Search and Insight

Some of the most beautiful results in mathematics are interesting because they reveal unexpected structure. Gödel’s incompleteness theorems, for example, establish fundamental limits on what sufficiently expressive consistent formal systems can prove. Their importance doesn’t come from someone having performed a particularly large calculation. They changed how we understand formal mathematics.

That makes massive AI searches feel fundamentally different. Thousands of agents exploring possibilities sounds less like mathematical insight and more like an enormous search procedure. But perhaps the distinction isn’t as clear as it seems.

Humans traditionally do both: we search and we compress. We try approaches, discard them, notice connections, and eventually find an argument that reduces all that exploration to something another person can understand.

AI may dramatically reduce the cost of the search. OpenAI describes its agents exploring different approaches in parallel and later cross-pollinating promising intermediate results between groups. If systems can do this at enormous scale, vastly more mathematical territory becomes accessible.

The enormous search can disappear once a compact argument has been found.

Perhaps brute force isn’t the opposite of insight. It can be a way of finding it.

Does It Matter How We Got There?

Imagine two mathematicians independently produce the same elegant proof. One arrives at it after years of intuition and careful thought. The other uses a program that searches millions of possibilities until it eventually produces the argument. The discovery processes are completely different; the resulting mathematics may be identical.

Of course, mathematics is more than correctness. We value explanations, useful concepts, connections, and proofs that reveal why something is true. But those qualities can exist in the resulting proof regardless of how messy the path toward it was.

An ugly search can discover a beautiful argument.

This becomes more interesting when AI finds something we didn’t expect. Proving a result mathematicians already strongly suspected is one thing. Producing a valid proof of something that overturns prevailing intuition is another.

Take the P versus NP problem. Most computer scientists expect (P \neq NP), but nobody has proved it. Imagine a machine-generated proof establishing (P = NP) instead. Humans inspect it, formal systems verify it, and nobody finds an error.

At that point, saying it was “only brute force” would miss what happened. An enormous search would have produced a result that changed our understanding of computation.

The brute force would not merely have found the proof. It would have surprised us.

Search Is Moving Up the Stack

I’ve been thinking about a related question in software development. AI is clearly reducing the cost of implementation, which suggests that scarce human work moves upward toward intent, context, architecture, and judgment.

AI doing mathematics complicates that picture because it isn’t merely executing a path somebody else specified. Increasingly, it can also search for the path. In the Navier–Stokes effort, the agents were deliberately given different approaches to explore, with intermediate findings later fed into further searches.

That suggests a progression:

execution
    ↓
search for solutions
    ↓
verification
    ↓
interpretation
    ↓
choosing worthwhile problems

We shouldn’t assume that AI stops permanently at any particular line. But as execution and search become cheaper, the value of the remaining layers changes.

For mathematics, verification still matters. OpenAI has also published the Lean formalizations and instructions for independently checking them. But verification isn’t the end of the work.

If a machine really proved (P = NP), for example, knowing that the proof is correct would only begin the next phase. We would want to understand why our intuition had been wrong, what follows from the result, which existing assumptions need to be reconsidered, and what new questions suddenly become interesting.

A proof can establish that something is true without telling us what the result means.

And before all of that comes another question: why were we looking there in the first place?

What Remains Scarce?

I don’t find the question “Can AI have insight?” particularly useful. It depends too much on what we mean by insight and what we believe happens internally in humans or machines.

A more practical question is:

What remains scarce when machines can search enormous spaces of possible solutions?

Today, choosing worthwhile problems, understanding why they matter, interpreting results, and connecting them to everything else we know still look like unusually valuable forms of judgment. Perhaps AI will become good at those things too. I don’t see a strong reason to assume otherwise.

That is why the interesting consequence of AI doing mathematics may not be that machines are becoming mathematicians. It may be that search and insight were less cleanly separated than we thought.

If AI keeps making both execution and search cheaper, the useful question for humans is no longer simply what machines cannot do. It becomes:

Which questions are worth asking, which answers matter, and what do we understand differently once the search is no longer ours alone?

Stop Rebuilding the Same Django App for Every Client

2026-09-09T00:00:00+02:00

Agencies build different websites for different clients, but they don’t always build different applications. One corporate website needs people, another needs locations, another needs events. Others need services, jobs, case studies, publications, or projects.

The details differ, but the underlying concepts often don’t. And yet we frequently build them again: a Person model for one customer, another Person model for the next, with different CMS integration, templates, multilingual setup, and publishing logic.

After five projects, the agency has implemented People five times. It has completed five projects — but has it built an asset?

Build the domain application once. Adapt it to the client.

The Repetition Is Easy to Miss

Take something as ordinary as a team section. The first client needs:

Person
├── name
├── role
├── photo
└── biography

The next client also needs departments and locations. A third needs multiple languages, while a fourth needs drafts and publishing. The fifth wants people to appear on team pages, office pages, articles, and landing pages.

These projects are different, but much of what we’re building is not. We still have a person with relationships, URLs, templates, perhaps an API, and because this is a CMS project, we repeatedly need the same editorial capabilities around it:

localization
versioning
preview
publishing
frontend editing
permissions
composition into pages

The recurring cost isn’t only the Person model. It is everything required to turn that model into something editors can actually work with.

Project Reuse Is Not Product Reuse

Of course, developers already reuse code. We copy models and plugins, keep project templates, and borrow snippets from previous projects. That helps, but copying an implementation is different from maintaining a reusable application.

When I copy the People implementation from Client A into Client B, the two versions immediately begin to diverge. A bug fixed for Client B doesn’t automatically improve Client A. A better editorial workflow discovered on Client C doesn’t become available to the others, and a useful API added for Client D remains a Client D feature.

The agency keeps learning. The software doesn’t.

What if recurring project knowledge accumulated in reusable Django applications instead?

Django Already Has the Right Unit of Reuse

Django has had an answer to this problem from the beginning: applications.

A People application can own the things that belong to the People domain:

people/
├── models.py
├── urls.py
├── views.py
├── api.py
├── templates/
└── ...

It can define what a Person is, relationships between people, departments and locations, APIs, permissions, and business logic. None of this needs to belong to the CMS.

This is the same distinction I argued for in The CMS Is Not the Application:

The application should own the architecture. The CMS should make it editable.

The difficulty has traditionally been the second half. Making a normal Django application feel like first-class content inside a CMS has required enough integration work that rebuilding the feature inside each project can still feel easier.

That is the problem I’ve been trying to reduce with djangocms-custom-content.

Make the Application Editable

Suppose we start with a reusable People application. Its domain might be very small:

class Person(models.Model):
    slug = models.SlugField(unique=True)

Then we add the editorial content that needs to vary by language and publishing state:

class PersonContent(models.Model):
    person = models.ForeignKey(Person, on_delete=models.CASCADE)
    language = models.CharField(max_length=15)

    name = models.CharField(max_length=200)
    role = models.CharField(max_length=200)
    biography = models.TextField()

What we want from the CMS is not ownership of Person. We want capabilities around it: make the content multilingual and versioned, give editors preview and frontend editing, allow people to be composed into pages, and provide a useful administration interface.

The Person remains part of the Django application. The CMS makes it manageable as content.

That distinction is what makes reuse interesting.

One Application, Different Clients

Client A can use the People application with a simple team page. Client B can add departments, Client C can relate people to offices, Client D can expose them through an API to another frontend, and Client E can use the same people in articles, case studies, and landing pages.

The projects don’t have to become identical. The reusable application provides a stable domain and a set of capabilities, while individual projects remain free to compose and extend them.

Conceptually:

                    People
                      │
          ┌───────────┼───────────┐
          │           │           │
      Client A    Client B    Client C
          │           │           │
       Team       Locations      API
       pages       + teams     + website

A useful improvement to People can now flow back into the reusable application instead of remaining trapped inside one customer project.

Over time, the agency isn’t merely delivering projects. It is accumulating capabilities.

From Projects to a Capability Portfolio

Once you start looking at agency work this way, People is only the beginning. Many agencies repeatedly build some variation of:

people/
events/
locations/
services/
jobs/
projects/
case_studies/
publications/

Not every agency needs the same applications, and there shouldn’t be one universal model for an Event or Service that satisfies every website. The point is not to standardize every client. The point is that an agency can decide where its own recurring knowledge deserves to become software.

Perhaps after building event systems for four customers, you know what your Event application should look like. Perhaps your agency has a particularly good model for Locations, or understands publishing organizations and has developed excellent applications for Authors, Publications, and Topics.

That knowledge can become part of your capability portfolio. The next project starts from there rather than from zero.

Reuse Changes the Economics of Improvement

Suppose improving the People application takes two days. If it belongs to one client project, the improvement needs to justify two days for that client. If the application is used across ten projects, the economics change.

Accessibility improvements benefit ten implementations. A better editing experience benefits ten editorial teams. Compatibility work benefits ten projects. A bug fix happens once, and a new CMS capability becomes available everywhere the application is used.

The cost of making the shared capability better is spread across the value it creates.

That is how product development works. Agency work usually doesn’t — but perhaps the boundary doesn’t need to be as sharp as we assume.

Reusable Does Not Mean Generic

There is an obvious danger here. Once developers discover reuse, we tend to generalize. Our simple People application becomes configurable, then highly configurable, then it needs twenty settings because every previous customer did something slightly different.

Eventually we have created a generic framework nobody particularly enjoys using.

That’s not what I’m proposing. A reusable application should still have opinions and represent a useful model of its domain. Projects can extend it when necessary, and sometimes a client’s requirements really are different enough that a separate implementation is the right answer.

The goal isn’t maximum reuse. Just as with component architecture, maximum flexibility isn’t automatically a virtue.

The goal is to identify the things we genuinely build repeatedly and allow the knowledge behind them to accumulate.

This Is What I’m Exploring with djangocms-custom-content

djangocms-custom-content is infrastructure for experimenting with this model. It tries to make the CMS-specific part of a reusable Django application inexpensive enough that the application can remain the primary architectural unit.

A normal Django domain can gain multilingual editorial content, versioning, preview, frontend editing, CMS administration, application URLs, and relationships between versioned and ordinary Django objects without having to become a special-purpose CMS architecture.

I’ve included applications such as People, Services, and Categories as examples, not because I think django CMS should own universal implementations of those concepts. Quite the opposite: they are there to explore how little CMS-specific machinery should be necessary for developers to build their own reusable applications.

The framework is still young. The interesting test now isn’t whether I can add more features to it.

It is whether other developers and agencies recognize the problem.

What Do You Keep Rebuilding?

That’s the question I’m most interested in. If you build Django or django CMS projects for multiple clients, which applications have you built more than once?

People? Events? Locations? Services? Jobs? Or something much more specific to the industries you work with?

And if you’ve tried turning those implementations into reusable Django applications, what stopped the reuse from working? Were customers’ domains genuinely too different? Was extension too difficult? Did CMS integration create too much project-specific plumbing? Did maintaining a reusable package cost more than rebuilding it?

Those answers matter more to me right now than another feature request. Because if the recurring problem is real, the opportunity isn’t merely to make custom content easier. It’s to change what accumulates when we build client projects.

The agency should keep more than the experience. The software should learn too.

Plugin Architecture Is Editor Experience

2026-09-07T00:00:00+02:00

How technical component architecture becomes product design.

Read on django-cms.org ↗

Make Your Django Application Editable

2026-08-31T00:00:00+02:00

Adding editorial capabilities without surrendering application architecture.

Read on django-cms.org ↗

The CMS Is Not the Application

2026-08-24T00:00:00+02:00

Where the boundary between application and content system belongs.

Read on django-cms.org ↗

Why You Should Join the Djangonaut Space Program as a Navigator — A Veteran’s Perspective

2025-07-17T00:00:00+02:00

On turning experience into leverage: mentoring new contributors, transferring context, and strengthening the community that sustains open source.

Read on medium.com ↗

Why I Still Write Code

2025-03-25T00:00:00+01:00

I have been writing software for a long time, and my role has changed considerably along the way. I spend more time today thinking about architecture, product direction, automation, and the long-term consequences of technical decisions than about implementing individual features.

And yet, I still write code.

The reason is not that I think writing code is inherently valuable, or that everything important should be implemented by hand. Quite the opposite: I believe strongly in automation and in moving repetitive implementation work out of the way.

I still write code because technical judgment requires contact with engineering reality.

Staying close

It is possible to understand a software system at many levels. You can understand its product, its architecture, its interfaces, its deployment, or the organization around it without knowing every detail of its implementation.

That distance is often useful. Architecture requires abstraction, and technical direction requires looking beyond the problem immediately in front of you.

But distance has a cost.

A clean architecture diagram does not tell you where an abstraction becomes awkward in practice. A specification does not necessarily reveal which existing assumption it violates. A pull request can look perfectly reasonable in isolation while gradually moving a system in the wrong direction.

Writing code occasionally takes me back into that reality.

I encounter the boundary that looked cleaner from above. I discover why an old piece of code is more complicated than I expected. I find that something I wanted to generalize should perhaps remain specific, or that two apparently unrelated problems are symptoms of the same architectural weakness.

Those observations influence decisions much larger than the code I happened to be writing.

Close to the automation

This is particularly important to me because I like automation.

Good automation removes repetitive work, makes knowledge executable, and allows people to concentrate on decisions that actually require their attention. Much of my work over the years has been about making systems do more so that people have to do less.

But automation also creates distance.

Once something works reliably enough, we stop thinking about what happens inside it. That is often exactly what we want. Nobody should need to understand an entire technology stack merely to complete an everyday task.

The situation changes when we are responsible for the system itself.

Automation encodes assumptions about processes, data, responsibilities, and exceptional cases. Those assumptions gradually become part of how an organization operates, often surviving much longer than anyone originally expected.

Being close to the implementation helps me understand what we are actually automating, rather than only what we intended to automate.

The goal is not to do manually what a machine could do for me.

The goal is to understand enough to remain in control of what the machine does.

Systems have surprisingly long lives

Software has a tendency to live longer than expected.

django CMS is a good example from my own work. It has evolved through many generations of Python, Django, browsers, deployment practices, contributors, organizations, and ideas about what a content management system should be.

A.IX is different, but the underlying design question is similar: what does it mean to build systems that may still matter decades from now? When investing is long-term the software also needs to be long-term.

Thinking in decades changes how I look at software.

The interesting question is no longer whether an architecture is elegant today. It is whether the system can absorb changes we cannot yet predict, whether parts can be replaced without replacing everything, and whether somebody will still be able to understand why important decisions were made.

Long-lived software does not survive by staying the same.

It survives because it can change.

Good design compounds

This is where architecture becomes less theoretical.

A clear boundary might save a little work today, but over many years it can make hundreds of changes easier. A stable interface can allow several generations of implementations to come and go behind it. A deliberately small core reduces the number of assumptions that must survive every technological cycle.

Good design compounds.

Bad design compounds too. A convenient shortcut becomes a dependency, the dependency becomes an assumption, and eventually that assumption appears in places nobody anticipated when the original decision was made.

After enough years, the cost of a design decision has remarkably little to do with the amount of code involved.

This is one reason I still want to experience some of those decisions at implementation level. Architecture is not something decided once and subsequently implemented. It emerges through many small decisions made over the lifetime of a system.

You cannot steward a long-lived software system entirely from above.

Designing for replacement

When building software expected to last, I don’t think the objective should be to preserve today’s implementation.

The objective should be to preserve the ability to replace it.

Operating systems change. Databases change. Frameworks change. Infrastructure changes. Organizations change. Requirements change. People certainly change.

Trying to predict all of those changes is futile.

What we can do is design boundaries that limit how far a change propagates. We can be deliberate about ownership of data. We can keep interfaces smaller than their implementations. We can avoid making the core of a system dependent on things that are likely to be temporary.

A stable system is not one in which nothing moves. It is one in which things can move without everything moving at once. That principle matters much more to me today than choosing the supposedly perfect technology for a particular moment.

Digital sovereignty

There is a broader principle behind this that I increasingly think about as digital sovereignty.

The term is often discussed at the level of governments, cloud providers, regulation, or open-source policy. Those are important conversations, but there is also a very practical version of it.

Can we understand the systems we depend on? Can we operate them? Can we modify them when our requirements change? Can we move them? Can we keep them running when someone else’s priorities change? Open source helps, but access to source code alone does not create sovereignty.

Capability does.

An organization that technically possesses the source code to an important system but no longer has the knowledge required to understand or change it is not particularly sovereign.

The same principle applies at a personal level.

I don’t need to implement everything myself, and I don’t want to. But I want to retain the ability to investigate a system, understand the important parts, question its assumptions, and change it when necessary.

Writing code maintains some of that capability.

Simplicity creates freedom

This also explains why I increasingly value simplicity.

Every additional dependency, service, abstraction, platform, and protocol may solve a real problem, but it also introduces another thing we depend on and another piece of knowledge someone has to maintain.

Complexity therefore has an organizational cost beyond development effort.

It reduces the number of people who can understand a system. It increases the number of external decisions that can affect it. It makes replacement harder and independent operation more expensive. Sometimes that cost is absolutely justified. But it should be a decision rather than an accident.

A system you understand is easier to change, and a system you can change is a system you have a chance of keeping.

Coding is not the output

This changes what writing code means to me.

Earlier in my career, code was much more directly the occasional output of my work. A problem needed solving, and I implemented the solution. Today, the most valuable outcome is often a decision: identifying the actual problem, finding the right boundary, choosing what should remain stable, deciding what should be replaced, or recognizing that something should not be built at all.

Writing code supports those decisions.

Sometimes I implement a small part because I want to test an architectural assumption. Sometimes I need to follow a problem deeply enough to understand where it actually originates. Sometimes building something is simply the fastest way to discover whether an idea survives contact with reality.

The amount of code I produce is therefore becoming less interesting to me.

The quality of the judgment it enables is much more interesting.

Knowing when to go down a level

Moving toward architecture and technical stewardship does not mean continuously moving further away from implementation.

It means being able to move between levels.

Sometimes the right place to work is the product direction. Sometimes it is the architecture. Sometimes it is an interface or specification. And sometimes the uncertainty cannot be resolved from there, and the right thing to do is to go down another level and look at the code.

Then you come back up with better information.

The further I move from implementation as my primary job, the more deliberate I become about which code I still write.

I don’t write code because writing code is the objective.

I write it to stay close enough to the systems I help shape that my decisions remain grounded in how those systems actually work.

For systems that should remain understandable, adaptable, and ours to change for decades, I think that matters.

That is why I still write code.