DEV Community: GoodBarber

How do you give local content in a WKWebView a real https origin? (iOS 17)

Pierre-Laurent Medori — Thu, 01 Oct 2026 11:45:29 +0000

On September 16 I opened a test widget on my iPhone. At the top, a quote that loads when the widget opens. Under it, two text areas and a Compare button that returns a similarity score. Two calls to the same third-party API with the same key: a GET for the quote, a POST for the score.

The quote appeared. The Compare button answered with the only sentence its code can say when that call fails: "Impossible de calculer la similarité. Veuillez vérifier votre connexion." Unable to compute the similarity, please check your connection. The connection was fine, my Android test phone did exactly the same, and in a browser both calls worked.

GET works, POST fails. I spent a morning on the verb. The cause was the page's origin, and the GET had never worked.

This piece is about that origin: where a page in a WKWebView gets one when its files live on the device, how our iOS engine now serves them from a fixed https://secure.internal with a proxy API that arrived in iOS 17, and what changing an origin breaks in places no crash log reaches. The widget comes back at the end, once the dates make sense.

Why local content needs an origin at all

At GoodBarber, an app builder for native iOS and Android apps, some sections of an app are web content: custom code written by the app's owner, HTML widgets, extensions. The files live on the device so that the section opens offline. On iOS they are displayed in a WKWebView.

How those files are served decides whether the page is a secure context, a prerequisite for APIs such as crypto.subtle. It also sets the origin seen by CORS and CSP checks, cookie behaviour, and where localStorage and IndexedDB data are stored.

One of those checks is ours. My team is piloting an extension builder, where I look after the backend: the owner of an app asks for a feature in a sentence, a model writes it, and the result runs in the app's web version and inside its native apps. A widget that needs a private API key never holds it. The page frames a small page served by our token issuer, gets a short-lived token, and calls a proxy of ours that keeps the key. The issuer lets only approved origins frame its page, through a CSP frame-ancestors directive. So the origin a native shell gives its local files decides whether any of those widgets can work at all. The builder has not shipped to customers, and the phones in this story are my own test devices.

Change the serving mechanism and all of that changes with it. We went through three versions in one year.

Three origins in one year

Period	How the page was served	Origin	What it cost
before June 2026	an HTML string with a custom base URL, files through a `WKURLSchemeHandler`	a custom scheme	not a secure context, an `Origin` header that third-party servers do not recognise, `Secure` cookies ignored, URL rewriting and a permissive CSP to hold it together
June to August 2026	a small HTTP server inside the app, bound to loopback	`http://127.0.0.1:<port>`	a secure context and plain HTTP semantics, but an IP address and a changing port in the origin
since September 2, 2026	a loopback CONNECT proxy in front of a TLS listener	`https://secure.internal`	iOS 17 minimum for this approach, and web storage starting from empty once

The second step was already a big one, and our iOS team built it as a real server: request parser, range requests for media, keep-alive, recovery when the listener dies. It also relays the page's cross-origin fetch calls, which the shell rewrites towards it. Loopback is a potentially trustworthy origin, so the page became a secure context and third-party scripts finally saw an http origin they understood.

The remaining problem was the port, assigned at runtime. There was no single origin to put in a remote allowlist. On July 30 the token issuer started accepting http://127.0.0.1:*, which is valid CSP and accepts any port, including any unrelated local server on the phone. A fixed https name would give the app and those services a value they could agree on.

WebKit will not hand over https

Apple's documentation for setURLSchemeHandler(_:forURLScheme:) rules out the direct approach: registering a handler for a scheme WebKit already handles, such as https, raises an exception.

Android takes the opposite position. shouldInterceptRequest lets an app answer any request, https included, and WebViewAssetLoader packages the pattern with a domain reserved for it, appassets.androidplatform.net. Our Android engine moved from file:// to that loader on July 31, a fixed https origin came with it, and the issuer accepted it the same day.

That Android approach does not transfer to WKURLSchemeHandler.

Why not a real certificate for a real domain?

The tempting shortcut is a public hostname that resolves to 127.0.0.1, a certificate from a public authority, and the private key shipped in the app. Let's Encrypt has a page about certificates for localhost whose answer is: don't. A private key distributed in an app is a compromised key, the certificate may be revoked, and the DNS lookup gives an attacker something to intercept. It also makes an offline section depend on DNS.

We could still use a certificate whose trust was limited to our own WebView. It did not need recognition from a public authority.

The piece that arrived with iOS 17

iOS 17 added proxyConfigurations to WKWebsiteDataStore, fed by the Network framework's ProxyConfiguration. Apple presented it at WWDC23 for network relays, with a remote relay in the example. Nothing says the proxy has to be remote.

import Network
import WebKit

// The CONNECT proxy is a listener our own app opened on loopback.
let proxy = NWEndpoint.hostPort(host: "127.0.0.1",
                                port: NWEndpoint.Port(rawValue: connectProxyPort)!)

var configuration = ProxyConfiguration(httpCONNECTProxy: proxy, tlsOptions: nil)
configuration.matchDomains = ["secure.internal"]  // only this name uses the proxy
configuration.allowFailover = false               // never try a direct connection

WKWebsiteDataStore.default().proxyConfigurations = [configuration]

Those two properties carry the design. With matchDomains, WebKit sends CONNECT secure.internal:443 to our listener instead of resolving the name, so the name never reaches DNS and the section opens in airplane mode. With allowFailover off, WebKit never falls back to a direct connection, so the name cannot leak to a resolver while our server is restarting.

Inside the app, three loopback listeners do the work:

A TLS listener serves the files. Its identity is embedded in the app: self-signed, RSA 2048, a single SAN secure.internal, TLS 1.2 minimum, ALPN http/1.1.
A CONNECT proxy on a port the OS assigns. It accepts exactly one request, CONNECT secure.internal:443, and pipes the bytes to the TLS listener. Anything else gets a 403.
A plain HTTP fallback for media, in case the media stack does not follow the data store's proxy.

The configuration is pushed again every time the server restarts, since the port changes, and before the WebViews are told to reload.

Accept one certificate, for one host

A self-signed certificate fails the system's trust evaluation. That is expected, and the navigation delegate is where it is settled. Ours is Objective-C. Here is the same logic in Swift:

func webView(_ webView: WKWebView,
             didReceive challenge: URLAuthenticationChallenge,
             completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {
    let space = challenge.protectionSpace
    guard space.authenticationMethod == NSURLAuthenticationMethodServerTrust,
          space.host.caseInsensitiveCompare("secure.internal") == .orderedSame,
          let trust = space.serverTrust else {
        completionHandler(.performDefaultHandling, nil)  // every other host: the normal path
        return
    }
    let chain = SecTrustCopyCertificateChain(trust) as? [SecCertificate]
    let leaf = chain?.first.map { SecCertificateCopyData($0) as Data }

    if leaf == pinnedCertificateDER {                     // byte-identical to the embedded one
        completionHandler(.useCredential, URLCredential(trust: trust))
    } else {
        completionHandler(.cancelAuthenticationChallenge, nil)
    }
}

The exception applies only to that host and that exact certificate. Every other host follows normal trust evaluation.

The embedded key is shared across our apps and can be extracted from a binary. We treat it accordingly. The design rests on the local routing and on the delegate's narrow trust decision; it does not give the certificate public authority or make it an app identity.

One more gate sits in front of the files. Loopback listeners are reachable by other processes on the device, so every URL starts with a random token generated for the session, and a request without it gets a 403.

Choosing the name

Since the name never touches DNS, it is cosmetic. It shows up in location.origin, in the web inspector and in server-side allowlists, never in front of a user. Two constraints still apply: the suffix must never be delegated on the public DNS, and no certificate authority must ever issue for it.

That rules out .app, which is a real top-level domain, and .local, which belongs to multicast DNS and answers on the local network. It points at .internal, which the ICANN Board reserved for private-use applications on July 29, 2024, permanently excluding it from delegation in the DNS root zone.

What we measured

The new engine landed on September 2, and the issuer swapped http://127.0.0.1:* for https://secure.internal the same day. These are the September 4 verification runs: iPhone 15 Pro simulator, iOS 17.4, our internal app in Debug, two real customer apps loaded in it.

Check	Result
Page loads logging `location.origin` and `isSecureContext`	43 loads across plugin sections, HTML widgets and scratch sections, 43 times `https://secure.internal` and `true`
`crypto.subtle`	present
TLS handshake through the tunnel	TLS 1.3, 6 ms
Import of the embedded identity	3.7 to 4.0 ms, measured four times
Live CONNECT tunnels	peak of 1, back to 0 after each cycle
Native bridge, storage round trip, cross-origin GET and POST relays	exercised on 9 scopes towards 3 remote hosts
Backgrounding for 50 seconds, then return	the WebView survives and the appear event fires again
Video rendering	not testable on the simulator, whose WebKit GPU process is denied GPU access; normal on a device

What the https origin changed

Mixed content appeared. Old custom code links http://fonts.googleapis.com/… stylesheets, in dozens of HTML files across 12 sections of a single test app. Under an http origin nobody noticed. Under https, WebKit blocks them as active mixed content and the page silently loses its fonts. The server now adds Content-Security-Policy: upgrade-insecure-requests to HTML documents, and to nothing else. Our Android engine met the same files after its own migration.

Tunnels have to die on the first EOF. A 28-minute capture showed 68 CONNECT tunnels alive at the same instant, all killed together with ENETDOWN when the app was suspended. Our relay waited for both directions to finish before closing, and WebKit keeps its side open and idle. A CONNECT tunnel is done as soon as either peer stops writing. With that rule, and a counter logged on every open and close, the peak is 1. ENETDOWN on suspension is now logged as a routine end of life, because it is one.

Web storage starts from empty. localStorage, IndexedDB and cookies are filed by origin, and WebKit offers no supported way to move them from one origin to another: WKWebsiteDataStore can enumerate and delete by origin, not read or rewrite. A custom section that kept a login token asks for the login once after the update. That is the visible price of an origin change.

The fourth change has no log line at all. It is the widget from the first paragraph.

Back to September 16

The phones ran internal builds of our shells from early summer. That morning I built both engines on my laptop and ran the same widget on fresh installs.

Surface	Native shell	GET, the quote	POST, the score
Web	none, a browser	ok	ok
iOS simulator	built that morning	ok	ok
Android emulator	built that morning	ok	ok, 48%, no console error
Test iPhone	internal build, early summer	a quote was displayed	error message
Test Android phone	internal build, early summer	a quote was displayed	error message

Same bundle, same backend, same key. The only variable left was the shell installed on the phones. Read the last two rows again: I wrote "a quote was displayed", not "ok". That morning I wrote "ok".

The verb was a good suspect, because a WebView does treat a request with a body differently. Browsers attach an Origin header to a same-origin POST and not to a same-origin GET, as the Fetch standard specifies, so any guard that compares Origin to an expected value is only ever exercised by POSTs. On Android, shouldInterceptRequest hands the app a WebResourceRequest with a URL, a method and headers, and no body. On iOS, our relay has to buffer the whole body before forwarding anything, and a GET has nothing to buffer. One fact should have cooled me down: both calls carried a bearer token in an Authorization header, which makes both of them preflighted cross-origin requests. For CORS, my GET and my POST were in the same class.

The coding agent I was pairing with asked for one trace from the phone, Safari's Web Inspector or chrome://inspect. I chose to build instead, because a build feels like progress. It worked, and this went into my notes: an outdated app relays the GETs and loses the body of the POSTs; check the build date before you look at the server. The second half is good advice. The first half is a mechanism nobody observed. The fix was right, the cause was invented.

Two days later I asked the same agent to draft an article from that session. Before writing the mechanism down for strangers, it checked it against git history, and the dates in this article do not allow it.

The iOS relay has buffered the complete body since the day it was written, June 4. There is no older relay that drops bodies for a phone to be outdated with.
On September 2 the issuer stopped accepting http://127.0.0.1:*. My commit message gives the reason: the feature is unreleased, and an app is rebuilt when the feature is activated for it. An iPhone build older than September 2 can no longer frame the token page. No frame, no token. No token, no call, whatever the verb.
Android builds older than July 31 load the page from file://. A file:// page has an opaque origin, and an opaque origin cannot be listed in frame-ancestors. No token there either.

So on those phones the GET could not have worked. Yet both showed a quote. The simulator still had the bundle it downloaded on the 16th, with the function that loads the quote, as the model wrote it (key name and author line shortened):

gbProxyFetch(KEY, "/v1/quotes")
  .then(function (res) {
    if (!res.ok) { throw new Error("Erreur API"); }
    return res.json();
  })
  .then(function (quotes) { /* render quotes[0] */ })
  .catch(function (err) {
    document.getElementById("quote-text").textContent =
      "« La simplicité est la sophistication suprême. »";
    /* ...and "Léonard de Vinci" in quote-author */
  })

On a shell that cannot frame the token page, the token request fails, the promise rejects, and this catch prints Leonardo da Vinci. That is what both phones were showing: Leonardo, in French. The POST went through the same failure with nothing to fall back on, so it told me to check my connection.

The asymmetry was not between two HTTP verbs. It was between two catch blocks. Nothing had worked on the phones; one of the two failures was dressed as a success. The evidence was on the screen: the API returns its quotes in English, the fallback is in French. And the SDK rejects with a typed error whose kind names the stage that failed, init when no token could be obtained. Both catch blocks received it. Neither read it.

An origin is versioned by the binary

A feature that lives in a web page inherits the page's origin, and inside a native app the shell chooses it: file://, a loopback port, a custom scheme, a fixed https name. CORS, CSP frame-ancestors, cookies and every server-side allowlist key on it. So every allowlist that names an origin is, in practice, a list of builds, and the builds are installed on people's phones on dates you do not control.

The switch of September 2 was a deliberate decision, and it holds: a rebuilt app carries the current shell, the current shell serves the origin the issuer expects, and the two move together. An app owner never meets the old origin. That works because the platform owns both ends, the native shell and the services behind it, which is also why every date in this article is known to the day. The one way to meet the old origin was to test an unreleased feature on an internal build from early summer, on the phone of the person who made the switch.

On the company blog I wrote about what quietly breaks when an app is not updated: store visibility, push delivery, OS changes. This is the same decay seen from the server side. An allowlist moves, and every build older than that date loses a capability, without a crash and without a line in the phone's log.

What I check first now

Is the half that works real? Before comparing a GET and a POST, find out whether the GET's data came from the network. Search the page for catch. If a model wrote the code, expect a fallback: models are polite about failure, they fill the hole.
One trace from the failing device. Web Inspector or chrome://inspect, five minutes. It would have shown no request to the proxy at all, neither GET nor POST, and a refused frame in the console.
The build date of the shell, before any server log, whenever the report says "fine on the web, broken in the app". Then compare it with the dates your allowlists changed.
Substitution, last. The same bundle on a fresh shell proves where the fault is not, and says nothing about what happened on the old one. "Works on the simulator I built this morning" and "works on the phone in my pocket" are different claims. That gap is where a correct fix picked up an invented cause.

The model's fallback stays. A quote widget that shows a default quote instead of a broken box is the right behaviour for the person using the app; it is only a trap for the person debugging it. So its firing becomes visible:

.catch(function (err) {
  console.warn("[quote] proxy call failed:", err.kind, err.message);   // the line that was missing
  showFallbackQuote();
})

With that line, the first look at the console says init, no token, before anyone opens Xcode. Degrade gracefully for the user, loudly for the developer.

After the migration

https://secure.internal is shared across our apps, just as appassets.androidplatform.net is shared by Android apps using that loader. It gives browser policies a stable value to compare. Authentication still needs its own mechanism, which is what the token is for.

The practical gain is that local content gets ordinary HTTPS behaviour while staying available offline. The cost sits in everything attached to the previous origin: storage, remote allowlists, and the builds already installed. That is why the new name is boring, fixed, and meant to stay. Changing it later is another migration, even if every HTML file stays the same, and the phones in people's pockets will not follow.

The assistant is making the native app mandatory again

Mathieu Poli — Thu, 01 Oct 2026 07:25:35 +0000

For ten years, a well-built website was an acceptable answer to the question "do I need an app?". This year, Apple and Google settled how the phone's assistant will act for us, and that answer no longer quite holds. The app is becoming an entry ticket again, and not for the reasons of 2008.

My colleague Dominique Siacci explained at the end of September why agents won't kill apps: on a phone, they can't act without them, because the app already carries the identity, the rights and the relationship an agent needs. I'd like to draw the consequence for the question we've been asked for fifteen years, and which is changing its answer for the third time.

Three answers to the same question

I've been building app platforms since 2011, and I've watched the answer to "do I need an app?" change twice.

The first answer was yes, no discussion. Between 2008 and 2014, being on the home screen meant existing. An icon on the phone was worth a shop window downtown. That rush is what gave birth to GoodBarber, and to dozens of tools like it.

Then the web took back control. Progressive Web Apps, Google pushing the browser as a platform, and a decade of "you don't need an app, a website is enough". The argument was solid. So solid that we added a PWA engine next to our native engines, in 2017, and we still sell it. One project description, three outputs: Swift, Kotlin, and the web. When I say the app had become optional, I say it as someone who built the option.

The third answer is taking shape this year.

What changed this year

At WWDC in June, Apple made App Intents the door through which Siri gets into third-party apps, and deprecated the old mechanism, SiriKit. iOS 27, released on September 14, launched a new Siri meant to act and search inside apps from a single sentence. It's early days. According to Apple, it's in beta and English first. It isn't available on iPhones in the European Union, and actions in third-party apps are coming "soon". Android is heading the same way with AppFunctions, shipped in Android 16 and still in beta with Gemini. Dominique covers the mechanism, so I won't go over it again.

The door itself isn't new: App Intents have existed since 2022. What changes this year is that Apple makes it the standard way in, and that the assistant will walk through it on its own, from a sentence.

For the question of this article, one thing matters: both mechanisms are native development kits, built into an app's binary, and a web page can't register with them. There is work on the web side, WebMCP, but it targets agents running in the browser, on an open page. The phone's assistant only looks at what's installed. I'm not saying anything about adoption, which nobody knows, or about when everyone will get access. I'm saying the entry ticket is defined, by both platforms, the same way.

Why this isn't 2008

It's tempting to read this as a step back.

In 2008, having an app was about capturing attention: an icon on the home screen, notifications. The app was a shop window. Tomorrow, having an app will be about being present in the assistant: when someone says "get me a seat for Saturday's concert", it's your app or someone else's that answers. The first was won with design and marketing. The second is won by describing your app, what it does as well as what it holds, precisely enough for a machine to use it.

There's a condition, and Dominique puts it himself on his list of what would prove him wrong: the assistant only calls what's installed. To be present in the assistant, you first have to be installed, and that's exactly the 2008 problem: the shop window is still the prerequisite.

This isn't the story I told in September either. There, I was talking about the cost of building: coding agents make it cheap to build the same app three times. Here, it's about distribution: who gets to be in the assistant. Two different mechanisms, pushing in the same direction.

So, do you need an app in 2026?

The question "do I need an app?" has had one answer per era. Yes, to be seen. No, a website is enough. And now: if you want to exist, one way or another, in the phone's assistant, yes.

First, to act. Booking a class, ordering, tracking a delivery, moving an appointment: these are exactly the sentences people will say to the assistant, and it can only carry them out in a native app that has declared those actions.

But also to be found. The assistant searches as much as it acts. When someone asks it to "find me a concert in Ajaccio next weekend", it will look in the content that installed apps have described to it: Apple explicitly plans for Siri to answer questions about an app's content. It's already what apps built on GoodBarber do when you ask Siri "what's new?", from iOS 17, without their owners having to touch anything. The rollout happens in stages, and my colleague João Aleixo explains how on our blog. A cultural events calendar or a local news outlet has as much to gain as a booking app.

And the assistant doesn't only live in the phone. In the car, few apps get a place on the CarPlay screen: Apple reserves it for a few categories, navigation or audio for instance, and rebuilding an interface for the dashboard rarely makes sense. But Siri is in the car, and an app that has declared its actions can answer there by voice.

The website keeps its role: it's what people find on Google, and it's what welcomes the visitor who comes once and won't install anything. We still sell PWAs, and many projects will have both: the website for Google, the app for the assistant.

It isn't urgent. If your users are in Europe, the new Siri hasn't reached them yet, and I don't know when it will. But the entry ticket is already set, and it's a native app.

The web had made the app optional. The assistant is making it mandatory for anyone who wants to be within earshot.

Mathieu Poli, Head of Frontend Engineering @ GoodBarber. I teach and write about frontend engineering, product design, and AI, and everything that happens when the three meet.
X: hellomathieup · LinkedIn: hellomathieup

Agents won't kill apps... on a phone, they can't act without them

Dominique Siacci — Tue, 29 Sep 2026 07:08:15 +0000

At WWDC this year, in the keynote, Apple confirmed something I had been holding as a logical intuition more than as an open question: when the assistant that lives in your phone wants to do something for you, it goes into the apps installed on that phone. An app declares the actions it can perform, and that is what Siri calls. On Android, Google is building the same door under the name AppFunctions, and describes it in its own documentation as the on-device equivalent of the tools an agent calls over MCP.

Two operating systems, the same year, the same decision. Meanwhile what you keep reading in 2026 is that apps are on their way out.

Where I'm standing

I am a co-founder of GoodBarber, a platform that builds and publishes mobile apps, where I run engineering and a little bit of everything. So a piece by me arguing that apps have a future deserves the suspicion you'd give a baker writing about bread. Read it that way. Further down I list what would prove me wrong, and I'll come back with numbers when we have them.

The case against apps, taken seriously

Carl Pei, the CEO of Nothing, said it plainly at SXSW this spring: apps are going to disappear. The argument is coherent. An agent doesn't need a screen to order a pizza; it needs an endpoint. If it can reach your service through an API or a website, the app in between is a detour, and a company's real product becomes the surface its agents can call.

I believe half of it. Agents do remove navigation: nobody wants to tap through four screens when a sentence does the job. A clean, documented surface matters more than it ever did. And we run one ourselves: a production MCP server that agents call all day to manage apps, without opening a single one of them.

The disagreement is about where the agent goes when the user is holding a phone.

What I think, and I'll own it

Apple clearly wants everything the assistant in your phone does, in what they now call your intelligent personal hub, to go through the apps installed on it. And I think they're right. It's the most logical channel there is.

Not because apps are nice, or because I sell them. Because on a phone, the app is the one place where three things already exist together: an identity, a set of rights, and a relationship. Everything an agent would have to rebuild from scratch on the web is already sitting there.

The door

On a phone, the assistant doesn't browse. It calls what an app has declared. The shape is familiar if you've written tools for an agent: a name, typed parameters, a description the model reads, a result it can show or speak. The difference is that the tool lives inside an installed app, with the app's data and the app's rights, and the operating system is the one dispatching the call.

If your service isn't installed, it isn't a tool. The assistant can't find it, can't ask it anything, can't act through it. That is a hard line, and both platforms drew it on purpose.

The rights

Think about what an agent needs before it can do anything useful for a person: who they are, what they've paid for, what they've allowed, how to reach them. On the web, every one of those is a login, a consent screen, a token, a form. In an installed app, all of it already exists. The session is open. The subscription is active. The notification permission was granted months ago. The agent inherits all of it the moment it goes through the app, and it can't do more than the user could, because an interface inherits the rights of whoever it acts for.

This is why I don't think the app's role shrinks as agents get better. An agent that can act on your behalf is worth exactly as much as the rights it can act with, and those rights live in apps.

The interface

Here is where I go a step further. I think the assistant is going to be the natural way to use an app, on the phone. You say what you want; the assistant asks the app; the app answers, in the assistant, with a card, a list, a confirmation. The screens stay for what a screen does better than a sentence, comparing, browsing, checking. I wrote about an agent as the first interface you don't have to learn from the operator's side; this is the same idea reaching the person who uses the app.

And I don't think it stops at Siri. An assistant that belongs to the app itself, that answers from its content and acts within its rights, is a second way in, next to the screens, not instead of them.

Two doors, one rule

From where we sit, an app now has two doors for agents, and they don't lead to the same room. Its owner's agent talks to the server that manages the app: content, products, notifications, the things an owner does. The phone's assistant talks to the installed app itself: the things a user does. Two doors, two sides of the product, and one rule that holds on both: each door inherits the rights of whoever it acts for, the owner on one side, the user on the other.

Our engine already answers one question from Siri, "what's new", and it is reaching apps in stages. The real work is ahead, and it has a shape of its own: we don't write one app, we publish thousands from the same engine, each described by its own configuration. So what an assistant can do in an app is something we define the way we define a feature: once, in the engine, as an opening, and every app that has the feature gets it.

What would prove me wrong

I want this list to be checkable, so here it is.

The assistants route around the apps. If in two years Siri and Gemini reach most services through the web or through APIs without an installed app, and the platforms let them, the door I'm describing was a phase.
Nobody installs. If assistants don't bring people to install anything, and the only apps worth calling are the ten everyone already has, this thesis holds for the giants and for nobody else.
The door stays half-open. If third-party actions stay a demo feature, reserved for a few partners, the mechanism exists and doesn't matter.

If you ship an app: what did you expose to Siri or Gemini first for this release, and what did you decide to keep behind a screen?

Our tools are built for humans, not for agents

Mathieu Poli — Wed, 23 Sep 2026 07:20:37 +0000

You don’t need to believe AI thinks to anthropomorphize it. Handing it our tools is enough. GitHub, the pull request, code review, Scrum, the sprint, the standup, everything that organizes the work of a development team was designed to coordinate humans, and since agents started writing code, we’ve been handing all of it to them as is.

The frontend team I work in, at GoodBarber, started out adapting that way, then realized fairly quickly it was a mistake and changed course. What I take from it, personally, is that the tooling has to be redefined for machines, not adapted from ours.

Our tools are tools for humans

The standup exists so that people working side by side don’t each drift off in their own direction. The sprint bounds time because we always overestimate what we’ll ship in two weeks. The pull request keeps a record of a choice its author will have forgotten in a month, and code review puts a second pair of eyes where the first no longer sees anything.

None of these tools is about code. They compensate for the flaws of people, and they were tuned, over twenty-five years, to the speed at which people work. A Medium post titled “Built for Humans”, published in June 2026, says it in one sentence: these processes were calibrated on us.

Anthropomorphism, at industry scale

When AI coding agents arrived, we built nothing for them. An agent opens a branch, pushes commits, writes its pull request, answers the reviewer’s comments, and nobody found that strange.

A study from NAIST, published on February 19, 2026, on 33,596 pull requests opened by five agents, shows how far it has gone: depending on how the agent writes its description, humans answer it faster or slower and accept its code more or less often. We are grading a machine’s manners on a form written for colleagues.

In the other direction, a session at Stanford on April 30, 2026 proposed managing agents with Scrum and Kanban, standups included, to give them the memory and coordination they lack.

In July 2026, Kyle Galbraith of Depot wrote that GitHub is the wrong shape for this new world. His subject was infrastructure. I replied that the problem looked wider to me: Scrum, PRs, sprints all coordinate humans, and we keep anthropomorphizing AI by handing it our rituals.

Anthropomorphizing, here, means giving the machine a process designed for someone who forgets and gets tired, without having checked what that process was protecting us from.

Do pull requests work for AI agents?

Yes, they work, and that’s the trap. An agent knows how to open a PR, describe it and answer a comment. The ritual accepts it without blinking, so we keep the ritual and try to adapt inside it.

That’s what we did at GoodBarber. Before agents, the pull request was already our bottleneck. Code waited for a reviewer longer than it had taken to write. With agents, the number of pull requests exploded, our reading capacity stayed the same, and review delays started being counted in weeks. We spent our days reading code written by a machine, never catching up with the queue.

The Faros AI report of April 2026, on 22,000 developers, counts 67.4% more pull requests to handle per developer per day, so there is nothing local about it.

Reading all that code, I understood that review rested on an assumption we had never had to state: the author will be there tomorrow. They will remember why they made that choice, and they will own the bug if there is one. The whole conversation around a PR rests on that. An agent closes its session and its context is gone.

A January 2026 study of 33,707 agent-authored pull requests, picked up by Addy Osmani, sees it in the data: agents merge small, well-scoped changes fast, and disappear the moment they get subjective feedback.
The pull request assumes an author who will come back. The agent doesn’t come back.

We didn’t manage to adapt review. We removed it. In the spring of 2026 it stopped being mandatory on more and more pull requests, starting with the changes we knew how to undo, the line I described in my piece on the net. As of September 2026, it only remains on changes rated critical, the ones whose release is risky. Everything else goes through a pull request loop between agents, and ships without a human having read the diff.

The first weeks were stressful, I won’t pretend otherwise. But the productivity gain is such that we can afford to handle the misses, provided we assessed beforehand that the risk stayed contained.

Scrum went the same way, only more abruptly. A two-week sprint is tuned to one person’s throughput, and once execution moves to agents, the sprint is empty long before it ends. The “Built for Humans” post tells it as a scene: two weeks of work finished by Tuesday. What limits the team now is what it can specify and verify, and Scrum has no tool to measure that.

At the September 2026 rentrée, we used the calendar to drop our human-designed methods all at once. We’re trying other ways of working right now, and I don’t have a method to recommend yet.

What a tool for machines needs

What’s missing is the tooling that comes next. Bryan Finster published in July 2026 the experiment that gave me my diagnostic. He had agents run the same tasks with and without our disciplines: TDD, pair programming, separating author and reviewer. His result: refactoring improves the code, writing the test first changes nothing. “Refactoring is the mechanism. Test-first ordering is the ceremony.”

The mechanism serves the machine. The ceremony served the human who had to force himself to think before writing. The ceremony is the human part of the tool, and it’s exactly what we hand the agent when we anthropomorphize.

From there, we can say what a tool designed for a machine looks like, because we already know its properties in the negative.

It asks nobody to be present while the machine works, whereas a ritual rests entirely on presence.

It draws the line between what the agent executes and what it proposes on the reversibility of the mistake, not on how confident the model sounds.

It gives the agent a written context it reads before starting, in place of a meeting where someone recites it.
And it verifies at the machine’s production speed, not at a human’s reading speed.

We had to design such a tool, on a small scale, because we had no choice. When AI writes code for someone who isn’t a developer, inside our product, that person has no pull request, no sprint, no reviewer. There was no ritual to lend it.

What we wrote looks like none of our meetings: a line drawn on reversibility, and an access surface declared up front and checked server-side, a choice my CTO Dominique has written about. It’s not much, but it’s designed for the machine, and it was easier to find there than in my own team, where we had a ritual within reach.

The tooling has to be rebuilt

My position is that the next generation of development tools has to be defined for machines, not adapted from ours. A faster pull request or an automated standup keep the human shape, and the human shape is the problem.

We’ll need tools that carry context so nobody has to remember it, that bound damage rather than time, and that verify at the pace the machine produces. I don’t know yet what they will look like. I’m wary of those who already do, they usually sell one.

It’s the same conclusion I reached about frameworks: when producing gets cheap, what holds value is what remains underneath, and for a team that’s the tooling.

If you’re adapting your team to AI, look at what you’re handing it. If it’s a pull request, a sprint and a standup, you’re not adapting to AI. You’re teaching it to pretend to be one of your colleagues.

Our tools compensate for our flaws. Before handing one to a machine, ask whether it has the flaw.

Mathieu Poli — Head of Frontend Engineering @ GoodBarber. I teach and write about frontend engineering, product design, and AI, and everything that happens when the three meet.
X: @hellomathieup · LinkedIn: hellomathieup

Cover photo by nikohoshi on Unsplash.

Listing a remote MCP server in every directory: what each one actually checks (September 2026)

Pierre-Laurent Medori — Thu, 17 Sep 2026 11:52:00 +0000

The Save button did nothing. We opened the network panel. The request had returned HTTP 200.

Inside the response: a validation error on a field the form did not show.

By then we had spent several days trying to get the same remote MCP server listed across directories. Another directory had published us in about ten minutes. A GitHub list had tested our endpoint and accepted its 401. Elsewhere, our submission was waiting for a human.

"Get the server listed" had turned into a collection of different jobs.

One line of context so you know where I stand: I run engineering at GoodBarber, an app platform, and our MCP server lets assistants manage the apps through an authenticated connection. It is hosted, it requires OAuth, and there is no public server code for a directory to scan: our public repository holds skills and client configuration. That distinction decided which submission paths worked.

After getting the server into ChatGPT's plugin directory, we widened the search. What follows happened between September 7 and 14, and every public state was checked again on September 14. The delays are the ones our submissions went through, not a promise from anyone.

The official MCP Registry: publish the identity first

The official MCP Registry accepts metadata for hosted servers, closed-source implementations included, as long as the server is publicly reachable. It authenticates the publisher's namespace and validates the metadata. Beyond that, its metadata is deliberately unopinionated, and curation is left to the aggregators downstream.

Our entry, dev.goodbarber/goodbarber-public-mcp, has been there since April 28 (version 1.0.0). On September 7 we published version 1.2.1, with DNS authentication: it declares streamable-http, the remote endpoint and the product page. On September 14 the registry API still marked it active and latest.

We would do this first again. It gives importers a stable identity and a record to consume, instead of asking each directory to rebuild the product from a README.

Glama had already imported a connector entry from that record. We claimed it, and on September 8 it displayed "Ownership verified" and "Healthy". Both were still there on September 14.

Upstream publication does not tell you when the downstream pages will exist. MCP.Directory says it auto-discovers servers from the official registry, where our entry has been since April. Its submission form promises a review within 24 hours, and its first, required field is a GitHub repository, from which it detects the tools by analyzing the server's implementation. The Knights Who Say Ni wanted a shrubbery; a hosted server with no public code has no repository to give. On September 14, MCP.Directory's sitemap still had no GoodBarber URL, six days after a server listing request and five skill submissions. Where those submissions sit, we do not know.

awesome-remote-mcp-servers: the CI that accepts a 401

awesome-remote-mcp-servers is built for our shape of product. It only lists servers the provider hosts: reachable at a public URL, usable by anyone who can sign up, speaking Streamable HTTP or SSE. Each entry's name links to the product's homepage, not to a GitHub repository, because the endpoint is the thing being listed. The list was created on September 8, and our PR went in the same morning.

It also gave us something we could test. Its submission workflow at the merge commit probes each endpoint with a real initialize handshake and sends no credentials. We replayed the check before submitting. Our endpoint answered with an authentication challenge, structurally like this (generic domain):

HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource"

The workflow takes a 401 or a 403 as a live endpoint that requires authentication, and reads the WWW-Authenticate header to choose between the OAuth and API-key markers. Our 401 passed with the OAuth marker. The probe never completes OAuth and never calls a tool: a green check here means the door exists.

Two more rules matter before you open the PR. Every entry needs a Glama connector badge, and CI checks that the connector exists. And the contribution rules document a fast track for automated agents: three robot emoji at the end of the PR title. Our PR was prepared by an agent, so we used it. PR #4 was opened at 07:23 UTC, labeled endpoint-ok and has-connector by CI nine seconds later, and merged at 13:50 UTC, on September 8.

Then the bot ran again on the merged PR. It added duplicate and missing-connector, removed has-connector, and asked us to remove the duplicate entry. The duplicate was ours: the check was now reading the list it had just merged. The README on the main branch settled what the labels could not.

Gemini CLI and GitHub: a crawler versus a review queue

The Gemini CLI gallery instructions describe a daily crawl of public GitHub repositories carrying the gemini-cli-extension topic. A gemini-extension.json manifest at the root of the repository supplies the metadata, and an extension appears in the gallery only if it passes validation. The instructions say there is no issue to file and no email to send.

We added the topic on September 9. On September 14 the topic and the manifest were in place, and the gallery page had no GoodBarber entry. A daily crawl gives no per-repository result, so we cannot tell whether we failed validation or were never picked up.

GitHub's MCP gallery has another gate. In discussion #1257, a GitHub answer explains that onboarding a new server is a manual curation process, and that new registry versions sync once a server has been onboarded. We asked to be included on September 8; on September 14 the expected gallery URL still returned 404. Republishing the registry record would change nothing there.

Our Claude Code plugin sits in a similar waiting room. Plugins are submitted through a form, and the public community marketplace catalogue is a read-only mirror, synced nightly from Anthropic's review pipeline, of the plugins that passed automated security scanning and were approved. Ours was submitted on September 7, shown as awaiting review on September 8, and still absent from that catalogue on September 14.

Claude connectors: ten minutes, then an inventory problem

The Claude connectors directory is a different destination from the Claude Code plugin marketplace. Remote servers are submitted from an organization's admin settings, through a portal that connects to the server. Our connector listing appeared about ten minutes after we submitted it on September 8, while the plugin was still waiting. Its tier is community, and that is the word we use.

Then we read the published inventory and found our own mistake. The directory's public record listed 120 tool names and left out an entire tool family, the one behind push notifications and analytics, while the description we wrote advertised both. The portal syncs the tool list from the server through the connection made at submission, and our connection did not expose that family. The description is ours to edit from the dashboard; the tool list is not an editable field, and changing it goes through the review team. Either way, the fix is ours.

For someone following the Claude connection guide, the only question that matters is whether the tools they get cover the task they came for. A directory listing does not change the tools a connection exposes, so the check we owe that reader goes beyond the listing: the published inventory against the description, then a real connection.

mcp.so: HTTP 200, application-level failure

The Save button from the opening was on mcp.so. We were updating an existing listing whose transport and overview had gone stale.

On September 8 the edit request returned HTTP 200, and its body carried application code -1, an "Invalid submission" message and a validation error under fieldErrors.tagline. The old tagline was too long. The form had no field to fix it and showed no error.

We sent the edit again with a shorter tagline, then read the public page, because a save response is a claim, not a result. On September 14 the listing showed Streamable HTTP, OAuth and the updated overview.

If that sounds familiar, it is the write-safety piece in miniature, with a web form in place of an agent. The green request in the network panel meant an HTTP exchange had completed, nothing more. Read the body, then read the page.

MCP Market: fast, paid, and one button to check

On September 8 we paid $69 for the remote-server "Official" listing option, which is a different product from the GitHub-repository submission. The listing was live the next morning, inside the advertised 24 hours, with the badge and the categories we asked for.

Search MCP Market for GoodBarber and a second card shows up next to ours: GoodBarber Skills, filed under Marketing Automation.

Then we clicked Try Now.

We had submitted our MCP product page as the destination. The published button led to our app-creation page, with MCP Market campaign parameters added, and still did on September 14. Both pages are ours, and it matters anyway: someone looking for connection instructions lands on a different step of the product journey.

Paying got the listing published fast. Checking where it sends people stayed our job.

Smithery and skills.sh: read what the signal measures

On Smithery, verification happens in the server's settings, through what its publishing guide calls an automatic official-vendor verification checklist. Our domain and backlink proofs passed their recheck on September 8. The public data embedded in the listing page said verified: false afterwards, and still did on September 14. The guide names the checklist without listing its items, and nothing we could see explains the step between two passed proofs and a false flag. We write down both states rather than calling the whole thing verified.

skills.sh showed our 44 skills on September 14, with installation counts. There is nothing to submit there: skills appear through the anonymous install telemetry of its CLI, when people run npx skills add. Those skills are instruction packages for using the server, and the counter measures installs: not a completed workflow, and not an OAuth flow that works in every client.

The September 14 snapshot

Every state below was checked on September 14, 2026; submission and publication dates are the real ones. Read "pending" as pending, and "absent" as unexplained.

Directory or catalogue	Admission mechanism	Observed delay	State on September 14	Pitfall
Official MCP Registry	Namespace authentication, metadata validation	Entry since April 28; 1.2.1 on September 7	Version 1.2.1 active and latest	Curation is left to aggregators
Glama	Registry import, ownership claim, health checks	Initial import not timed	Ownership verified; Healthy	Ownership and health are separate signals
awesome-remote-mcp-servers	Endpoint CI without credentials, Glama connector badge, PR	Same day, September 8	PR #4 merged	The probe stops at the 401
MCP.Directory	Registry auto-discovery; GitHub-based form with a 24-hour review promise	September 8 to 14, unresolved	No GoodBarber URL in sitemap	The form expects a GitHub repository
Gemini CLI gallery	Topic crawl, root manifest, validation	September 9 to 14, unresolved	No entry on the gallery page	A daily crawl gives no per-repo result
GitHub MCP gallery	Manual curation, then version sync	September 8 to 14, unresolved	Expected URL returns 404	Registry publication does not grant admission
Claude Code community marketplace	Submission form, security scan, approval, nightly mirror	September 7 to 14, unpublished	Absent from public catalogue	Separate from the connectors directory
Claude connectors directory	Admin portal; tools synced from the connected server	About 10 minutes, September 8	Community listing; 120 declared tools, no push or analytics	The synced tools did not match our description
mcp.so	Authenticated form and API validation	Update completed September 8	Corrected transport and overview live	HTTP 200 carried a validation failure
MCP Market	Paid remote-server submission	Live the next morning, September 9	Official listing live; a GoodBarber Skills card also listed	Try Now destination changed
Smithery	Official-vendor verification checklist	Proofs passed September 8	Public data still says `verified: false`	Passed proofs did not flip the public flag
skills.sh	No submission; CLI install telemetry	First install not timed	44 skills listed	Installs are not workflow success
Docker MCP Catalog	Remote-server PR, Docker team review, test credentials by form	Open since September 8	PR #4968 open; 0 comments	Review outcome unknown
VoltAgent skills list	Skills-list PR; rules require real community usage	September 8 to 14	PR #1031 closed without merge or comment	Adoption comes before the listing
BehiSecc skills list	Skills-list PR	Open since September 8	PR #689 open; 0 comments	Skills listings have their own review
Cline marketplace	Submission issue; review of adoption, credibility, maturity, security	Open since September 9	Issue #2492 open; 0 comments	Review weighs community adoption

The order we would follow next time

Start with the official registry, and with one description, one endpoint, one product page and one documentation URL, the same everywhere. Separate the hosted server from the skills package before choosing routes: some submission forms start with a GitHub repository, and a hosted server has nothing to put in that field.

Then read each gate before you submit. Replay public CI checks. If an agent prepares the PR, use the documented agent fast track. For a crawler, check the topic and the manifest. For a curated catalogue, read the acceptance criteria first, since some weigh community adoption, then keep the submission reference and wait for evidence of admission.

After publication, read what went live: the tool inventory, the authentication metadata, every destination link. Keep dates next to results and recheck weekly. The merged PR, the badge and the live page can tell three different stories.

All of it points to one page, the connection guide. If you are connecting GoodBarber to an assistant, start there.

One more thing: that was a dense week, and these procedures move fast. What you read above comes from each directory's own documentation where it has one, and from what we saw on the forms otherwise, checked on September 14. If you run one of these directories and something here is wrong, or already out of date, tell us in the comments.

Which check caught a mismatch in your own listing: the response body, the tool inventory, or the link after publication? Genuinely curious.

The URL on the flyer doesn't know your app changed

Dominique Siacci — Tue, 15 Sep 2026 14:29:50 +0000

A link leaves your system the moment it's printed. The QR code on a restaurant's counter card, the URL at the bottom of a club's poster, the link a shop put on its packaging three seasons ago — none of these can be recalled. You can't redirect ink. Whoever scans that code has an appointment with your app, and they chose the date: maybe this afternoon, maybe in four years, long after the app was redesigned twice and the section it pointed to was renamed.

A link is a promise. And the inconvenient part of the promise is that its duration was never yours to choose.

One door, many keys

Links reach an app from more places than anyone plans for: a QR code, a push notification, a URL shared in a chat, a link inside the app's own pages, another app handing over an address. Every one of those arrives shaped differently.

Our answer is architectural: all of them funnel into a single resolver. Whatever the source, the link is first translated into the same internal representation — what is being asked for, in which section — and only then does anything happen. The variety of doors is a parsing problem at the edge; behind the edge there's one door, and one promise to keep.

Formats get added. They don't get retired.

Over the years, the shape of our links has changed — of course it has: URLs got cleaner, more readable, more shareable. Each generation was an improvement, and each one created the same obligation: every link emitted in the old shape was already out in the world, printed and pinned and bookmarked.

So the rule is simple and it only goes one direction: formats get added, never retired. A link built the way we built them years ago still resolves in the app that ships today — not because that old parsing code is anyone's pride, but because the alternative is breaking a promise someone else is still holding. Backward compatibility of this kind isn't a feature you announce; it's debt you carry with a straight face, because the person who scanned yesterday's format doesn't know it's yesterday's, and shouldn't have to.

Durable by construction

Honoring old links forever would be impossible if a link depended on things that change. So the durability is built into the addressing, not into a policy of never changing anything.

A link targets a section by a stable identifier — never by its position in a menu. Reorder the navigation, redesign every screen: the identifier doesn't move, so the link doesn't care. Renamed a section's public URL? Where the platform can, the old slug is absorbed by a permanent redirect to the new one. Even the domain gets the benefit of the doubt: a link is matched with and without www, in http as well as https — so a flyer printed back when the web still said http:// opens today's app without noticing what decade it is. None of these tricks is clever on its own; it's the ordinary toolbox of URL hygiene. The only discipline is in refusing to skip any of it, anywhere, ever.

The pattern behind all of it: everything around an app changes over three years — the design, the structure, the web's own defaults. The address layer is built so that nothing a link relies on is among the things that changed.

When the promise can't be kept

Sometimes resolution genuinely fails — the section is gone, the content deleted. What happens next depends on where the link came from, and the distinction matters.

Inside the app, a link that resolves to nothing is a bug, and it gets treated like one: a not-found screen, visible enough that someone fixes it.

But a link arriving from the outside world — the flyer, the QR in the street — never ends on a dead end. As a last resort, when every attempt at resolution has failed, the visitor lands on the app's home. Not because errors should be hidden, but because of who's standing there: this person didn't hit a bug, they exercised an old promise. Handing them an error page punishes them for our history. Handing them the home screen at least honors the half of the promise that's left — there is an app here, and you're welcome in it.

You don't control when a link will be redeemed. You only control whether, on that day, it's honored. Build for the second, because the first was never up to you.

"Too many levels of symbolic links" with no symlink in sight: autofs, a bind mount and a cron container

Pierre-Laurent Medori — Tue, 15 Sep 2026 11:54:39 +0000

In September, our PHP crons started failing with an error that sounded specific:

Too many levels of symbolic links

That is ELOOP, the error a symlink loop gives you, so the first move was to look for a loop on /srv/apps/app-a/task.php. There was no symlink on that path. Nothing to untangle.

Paths and component names below are generic examples, not ours.

By the time we looked again, on September 10, the file was readable. The autofs service had just restarted, and the same file answered on /opt/code/app-a/task.php and on /srv/apps/app-a/task.php. That left a question the successful ls could not answer: what had to work for the second path to reach the first?

For context: I run engineering at GoodBarber, an app platform, and these crons run its background jobs. The short version of what follows: the code was already bind-mounted into the container, the paths the crons used still went through autofs, so we mounted the code directly at those paths and took them out of the automount map. If ELOOP sends you hunting for symlinks that are not there, look at your automounts, and at what the container's mount namespace can actually see.

The autofs layer inside Docker

The cron container's Compose configuration already mounted the application code from the host:

host /srv/code/app-a -> container /opt/code/app-a
host /srv/code/app-b -> container /opt/code/app-b

The application expects /srv/apps/app-a and /srv/apps/app-b. The image supplied those two paths through an autofs direct map:

# /etc/auto.master
/- /etc/auto.apps --ghost,--timeout=30

# Two entries in /etc/auto.apps
/srv/apps/app-a -fstype=bind :/opt/code/app-a
/srv/apps/app-b -fstype=bind :/opt/code/app-b

Any access to either path could trigger the automounter. The other entries in that map were NFS shares, managed by the same daemon.

Two layers of mounting for code that was already local. Opening a PHP file depended on the service that manages our network mounts.

Why an automount can return ELOOP

The error name is narrower than the mechanism behind it. In Linux v6.1, follow_automount() increments nd->total_link_count, the same counter symlink traversal spends, and returns -ELOOP once it reaches MAXSYMLINKS, which is 40. During a path lookup, every automount crossed counts against the symlink limit. No symlink required.

The autofs documentation describes the other half. When an autofs filesystem is visible in several places and the mounts created by its daemon do not propagate to the others, access from those other places "will likely result in the ELOOP error". The caller keeps meeting a trigger and never sees the mount it is waiting for.

That is how you get ELOOP without a symlink. Which of the two our incident took, we cannot say: the investigation tied the failure to an NFS incident and an unhealthy automounter, and we did not capture a kernel trace. What the configuration did show is the dependency itself, and it had no reason to exist, whatever upset the daemon first.

The fix stayed in configuration

On September 10 we added direct Docker binds at the paths the crons actually use. The relevant Compose fragment:

volumes:
  - type: bind
    source: /srv/code/app-a
    target: /srv/apps/app-a
  - type: bind
    source: /srv/code/app-b
    target: /srv/apps/app-b

We also gave the cron container its own copy of the automount map, with those two entries removed. It takes both changes: leave the keys in the map and autofs installs its triggers over the direct mounts again.

One detail of our image: the map path, shown here as /etc/auto.apps, is a symlink to the real map file. The Compose override mounts the cron-specific map over that target. The web containers keep the map they had.

The application teams maintain and deploy that code. This was an operations fix, so it stayed in the mount configuration and the application paths did not move. No PHP patch, no local checkout drifting away from what the application teams deploy.

Proving the dependency is gone

Roy from The IT Crowd has a suggestion: "Have you tried turning it off and on again?" We already had a readable file after a restart. The useful test was whether it still needed the automounter.

Inside the cron container, check each mount on its own:

findmnt -o TARGET,SOURCE,FSTYPE /srv/apps/app-a
findmnt -o TARGET,SOURCE,FSTYPE /srv/apps/app-b
grep -cE '^/srv/apps/app-(a|b)[[:space:]]' /etc/auto.apps

Both mounts should resolve to the host-backed code, with no autofs trigger underneath. The count should be 0, and grep exits with status 1 when nothing matches. If mounts are stacked, read /proc/self/mountinfo as well: the filesystem on top hides what sits below it.

Then check the cron runs after the deployment. The jobs have to actually run, and their new logs have to be free of ELOOP. Silence from a job that never started proves nothing.

The deployment was confirmed working on September 10. One check we have not run yet: in a maintenance window, with the NFS-dependent jobs paused, stop autofs inside the cron container, read the PHP entry point, then restart autofs and confirm it is active. The direct bind should stay readable. That tests the dependency removal, not an NFS hang.

The maintenance we kept

We now have two maps, and any change to their shared NFS entries has to land in both. Removing a runtime dependency left us a configuration chore.

The code was local all along. We changed how the crons reach it, and opening a local PHP file no longer needs the automounter to cooperate.

Have you met ELOOP with no symlink in sight? What was underneath on your side: autofs, a bind mount, something stranger? Genuinely curious.

Everyone is going back to native. We never left, and the bet paid in a way we didn't expect

Mathieu Poli — Fri, 11 Sep 2026 11:45:22 +0000

You've probably read it by now: Shopify is moving all of its mobile apps back to Swift and Kotlin, six years after going all-in on React Native. In their own words, "building the same feature in Swift and Kotlin no longer carries the cost it used to," because coding agents now do enough of the work in between. We never left, and I want to be precise about why. We bet on native in 2011 for one reason: iOS and Android would outlive every layer stacked on top of them. Every layer since has been temporary, which we expected. What ended the detour was AI, which we didn't.

We bet on native because it was the layer that would last

When people ask why an app builder compiles Swift and Kotlin instead of shipping one cross-platform codebase, they expect an answer about quality, and the honest answer is about time. In 2011 we had to decide what to build our engines on, knowing we'd carry that choice for a decade or more, so the question we asked was which layer would still be there in ten years.
The platforms would. Apple and Google were not going to abandon their operating systems, their toolchains or their SDKs. Everything in between, the frameworks promising to spare you the platforms, had to earn a decade of existence, and nothing about them suggested they would. So we invested in the layer that was certain to remain, and we treated everything stacked on it as temporary, however popular it was that year. That's the whole bet. It cost us more per feature, and it bought us a foundation we have never had to rewrite because a dependency died underneath it.

Every layer since has been temporary

The waves came on schedule, roughly one every few years, and each was presented to us as our replacement. 2011: PhoneGap, bought by Adobe that year, and the first serious promise of one web codebase for every platform. 2015: React Native. 2016: Xamarin, bought by Microsoft, and the promise of C# everywhere. 2018: Flutter 1.0. We evaluated two of them seriously, React Native a couple of years after it shipped and Flutter once it had matured, and both times the same question decided it: what's the lifespan of this layer, compared with the lifespan of what's underneath?
Then the answers arrived. Adobe discontinued PhoneGap in 2020. Microsoft ended Xamarin support in 2024. And this year Shopify, which had bet on the most successful of those layers, announced its way back to the platforms. The intermediate layer kept changing names while iOS and Android kept theirs. None of that makes the people who chose those frameworks wrong: for a company shipping one app, avoiding a second codebase was a rational bet, and I'd have made it in their seat. It's just a bet on a shorter horizon than ours.

Why we could afford a bet nobody else could

What made our choice possible is simpler than vision, and I'd rather state it plainly. An app builder doesn't build one app; it builds engines that render thousands. At GoodBarber, our iOS engine is Swift, our Android engine is Kotlin, and a third engine produces a Progressive Web App; a single project description feeds all three. We build three times, but we build three times once, and every app the platform renders amortizes those three engines a little more. The duplication cost that pushed the industry toward hybrid, divided by thousands of apps, was simply our business model. The reason to leave native never existed on our side of the fence.
The bill is real, though. Three engines mean three expertises to hire and three implementations to keep in step, and the parity work between platforms is a permanent line in our budget. It's payable for one reason only: it's paid once, and divided by thousands.

What the bet bought

Most of what native bought us lives below what users can name. The sensory layer: haptic feedback, parallax, motion, a tab bar that floats, scrolling with the system's exact physics, transitions that belong to the OS. A media player that keeps playing when the screen goes dark and follows the user from screen to screen. Local notifications that fire from the app binary itself when someone enters a geofence or walks near a beacon, with no server involved, which only exists when the app is real native code running with the operating system's own permissions. Each platform's own idioms, because three engines can be right in three worlds instead of average in two: the share sheet is Apple's on iOS and Android's on Android. And when Apple ships a new primitive at WWDC, we can adopt it as soon as it lands, with no framework in between that has to wrap it first.

It ended, but not the way we pictured

We expected the intermediate layers to wear out one by one, and we expected time to settle the bet. What settled it was AI, and from a direction we hadn't imagined. Instead of waiting for the hybrid frameworks to fade, it removed the only reason anyone had to use them. The whole case for a shared codebase was the cost of building twice, and models and agents now carry enough of the translation, the testing and the review across platforms that duplication stopped deciding anything. A team shipping one app can land today where we've been since 2011, on the platform's own languages with the platform's own tooling. Two roads to the same place, fifteen years apart: agents for them, architecture for us.
For us, AI lands on top of that structure rather than instead of it. Generated sections live inside apps whose engines were already native, and the model works with first-party toolchains, where it can test its own work fastest. We bet that the platforms would outlast everything built on top of them. They did. We just thought the proof would take longer, and come from somewhere else. The bet paid, not the way we pictured, which is usually how bets pay.

Mathieu Poli — Head of Frontend Engineering @ GoodBarber.
I teach and write about frontend engineering, product design, and AI — and everything that happens when the three meet.
X: @hellomathieup · LinkedIn: hellomathieup

Fourteen years of blog posts, seven languages, one laptop: an open-weight model did our hreflang backfill

Pierre-Laurent Medori — Thu, 10 Sep 2026 11:37:50 +0000

In May I had 5,892 blog posts spread over seven hosts, the oldest dated November 7, 2011, and not one field anywhere that said which post was the translation of which. Same company, same blog: French on fr.goodbarber.com, English on www, then es, it, pt, de and nl on their own subdomains. In our CMS each language blog is a separate site, and for fourteen years a translation was published as a new, unrelated article. Google's hreflang wants, for every article, the full list of its language versions, and it wants the list on every one of them. We had the articles. We did not have the list.

One line of context so you know where I stand: I run engineering at GoodBarber, a no-code app platform headquartered in Ajaccio, Corsica. I have no religion about where a model runs. This post is about one job where a two-year-old open-weight model on a laptop was the right tool, with the numbers to show it, and about why we are hosting a Hacktoberfest Fest on exactly this subject on October 21.

Why this is a judgment call, not a join

Every obvious key fails. The number at the end of each URL (-a1332 in French, -a1486 in English for the same article) is a per-blog counter. Publication dates are days apart for a translation, sometimes months. Titles are translated freely, and the monthly "What's new at GoodBarber" post carries the same title every month in every language. Slug overlap works when the translator kept the English words and fails precisely when they did their job.

A person would read the summary of the French article, read the summaries of the English candidates, and decide. That is a language model's job. The question was which one, and where.

The recipe: four scripts, one afternoon of GPU time

Hardware: a MacBook Pro with an M3 Max and 48 GB of memory. Runtime: Ollama. Two models, both open weights: gemma2:27b, Google's June 2024 release, 15 GB on disk at the default 4-bit quantization, under the Gemma terms; and bge-m3, BAAI's multilingual embedding model, MIT licensed, 1.2 GB, 1,024 dimensions. Around 600 lines of Python with httpx, no framework, no vector database.

1. Crawl, deterministically

One script dumps every article of every language blog into a JSONL file, one line per article, from the CMS listing API. It flushes each page as it lands and skips ids already on disk, so it survives being interrupted.

blog	articles	first post	last post
fr	1,085	2011-11-07	2026-04-24
en	1,083	2011-11-07	2026-04-24
es	893	2013-01-24	2026-04-23
it	892	2013-01-24	2026-04-23
pt	778	2013-01-24	2026-04-23
de	683	2013-11-25	2026-04-23
nl	478	2013-11-25	2026-04-23

5,892 articles, crawled on the morning of May 4, 2026.

2. Narrow before you ask

French is the pivot: it is the source language of most of our posts and the largest blog. For each French article and each of the six other languages, the candidates are the articles of that language published within 90 days of the French one, closest first, twenty at most. The model never sees the 1,083 English posts. It sees at most twenty summaries and picks one, or none.

DATE_WINDOW_DAYS = 90
TOP_K_CANDIDATES = 20
MIN_CONFIDENCE = 0.7

This is where most of the accuracy comes from, and it costs nothing. A retrieval step does not need to be clever; it needs to make the question small.

3. Ask one small question, in JSON, at temperature zero

The prompt, verbatim:

Match translations of blog articles between languages.

RULES:
- A match means the SAME article translated - same specific content, same arguments,
  same examples - not just the same broad topic or shared keywords.
- Two articles can share a keyword (e.g. 'no-code', 'GoodBarber', 'app') and still be
  DIFFERENT articles. Reject those.
- Compare the FULL summary, not just the title. Look for the same specific subject,
  same angle, same takeaways.
- If you are not sure it's the same exact article, set index=null.
- Return high confidence (>0.8) only when the summary clearly describes the same content.

SOURCE (fr):
title: ...
summary: ...
date: ...

CANDIDATES (en):
[0] title: ...
    summary: ...
    date: ...
[1] ...

Reply JSON only: {"index": <int>|null, "confidence": <0..1>}. Default to index=null when unsure.

The call:

r = await client.post(
    "http://localhost:11434/api/generate",
    json={"model": "gemma2:27b", "prompt": prompt, "format": "json",
          "stream": False, "options": {"temperature": 0.0}},
    timeout=600,
)
answer = json.loads(r.json()["response"])

Three rules around it. An answer under 0.7 confidence is discarded. An article can belong to one row only, so a matched URL leaves the candidate pool for everyone else. And after every pivot the CSV is rewritten atomically, with a sidecar file recording which (pivot, language) pairs were already attempted, so a Ctrl-C or a rerun never pays for a prompt twice.

That sidecar exists because I reran the thing several times while changing the prompt and the thresholds. With a hosted API, each rerun is a line on a bill and a rate limit to negotiate. Here it was a keystroke.

I measured the cost of one prompt again today, September 9, on the same laptop, with the same code and the same model: the French "GoodBarber vs Glide" article against its thirteen English candidates within the window, 1,342 prompt tokens, 16 tokens out. Cold, 24.7 seconds, of which 11.2 to load the model. Warm, 2.3 seconds. Both runs answered {"index": 2, "confidence": 0.95}, and index 2 is the right article. About 6,500 (pivot, language) pairs at that speed is roughly four hours of GPU time. The crawl ran on May 4; the CSV was last written on May 6 at 20:49. Sent to a hosted model, those eleven million or so prompt tokens would have cost somewhere between a couple of dollars and a couple of hundred depending on the model. Money was never the argument. The meter was.

4. Verify with a different model

The generator is the judge. It should not also be the reviewer. Three layers, cheapest first:

Deterministic checks. Host matches the column, slug has the expected shape, each URL appears once in its column, and the publication dates within a row span 90 days at most.
Slug overlap. A cell whose slug shares almost no words with the French slug, in a row where the other cells share plenty, gets flagged. It is a heuristic with known false positives on well-translated slugs; it only surfaces candidates.
A second model. bge-m3 embeds the title plus the first 300 characters of the summary for all 5,892 articles (an 82 MB cache on disk, once). For each row, pairwise cosine similarity between the cells. A cell whose mean similarity to its row-mates drops 0.15 below the others is an outlier; a row whose mean is under 0.55 is weak. In fix mode the script proposes, for each outlier, the article of that language closest to the centroid of the other cells, and only if it scores at least 0.70 against the centroid, at least 0.70 against the French pivot, and beats the current cell by at least 0.10.

Two models disagreeing is the review queue. A human reads the queue, not 5,325 cells.

What came out

	rows	en	es	it	pt	de	nl
French pivots	1,085
cells filled		959	766	760	688	616	451

5,325 of the 5,892 articles landed in a row, 90.4 percent. 347 rows are complete in seven languages, 151 more in six.

The gaps are older than the model. The Spanish, Italian and Portuguese blogs opened in January 2013 and the German and Dutch ones in November 2013, and the early years published a lot of local-only content that was never translated. So the 193 French posts of 2013 yielded 227 matched cells and no complete row, which is the right answer, not a miss. From 2019 on, more than half of the French posts have all six translations.

year of the French post	French posts	matched cells	complete rows (6 of 6)
2013	193	227	0
2015	142	542	0
2018	48	226	20
2021	64	354	51
2023	87	473	65
2025	26	155	25

Two implementations, one list

We had no ground truth. Nobody was going to grade 5,325 pairs by hand, and a validator written by the same person with the same assumptions grades itself. So over the same two weeks in May, a colleague, Marc, built a second implementation with nothing in common with mine: a different method, an embedding model and a nearest-neighbour index (pgvector) instead of a generator and a prompt, the same French pivot, a similarity threshold at 0.60, and a preference for the French article that shares the same thumbnail image, by hash, when one exists. No date window, no candidate list, no shared code, and no import of my CSV. Two lists, built blind. The rule was simple: when they said the same thing, we would stop.

I pulled the export of the second implementation today and diffed it against my May file.

Its export lists 1,137 rows today; 1,051 of my 1,085 French pivots are in it.
Of the 4,122 cells both pipelines filled, 4,037 are identical: 97.9 percent.
85 differ. I read the first 40 by hand: in 38 the second implementation is right and mine is wrong, the other two are a toss-up. The errors cluster in three families: serial posts (the monthly "What's new", the engine revision announcements, where a 240-character summary does not carry the edition), topic pairs published in the same window (two reseller posts, two native-ads posts, which my 90-day filter served up together), and a handful where the summary simply was too short.
284 cells the second implementation filled that mine had left empty, and 110 that mine filled and it leaves empty.

Two implementations that share nothing but the corpus, landing on the same answer 98 times out of 100: that was the stop criterion, and we stopped. Since June our blog sitemaps carry the alternates, rebuilt from that export on every regeneration, best-effort: if the export is unavailable, the sitemap is generated without alternates rather than not at all. As of today, on our seven hosts:

host	blog URLs in sitemaps	with hreflang alternates
www (en)	1,107	983
fr	1,084	1,022
es	945	844
it	943	854
pt	888	801
de	768	701
nl	561	536

5,741 of 6,296 URLs, 91.2 percent. The alternates live in the sitemaps only, not in the pages' <head>, which Google accepts as one of the three supported ways to declare them. One entry, as served today, shortened:

<url>
  <loc>https://www.goodbarber.com/blog/design-trends-2026-...-a1608/</loc>
  <xhtml:link rel="alternate" hreflang="fr" href="https://fr.goodbarber.com/blog/tendances-design-2026-...-a1439/"/>
  <xhtml:link rel="alternate" hreflang="en" href="https://www.goodbarber.com/blog/design-trends-2026-...-a1608/"/>
  <xhtml:link rel="alternate" hreflang="es" href="https://es.goodbarber.com/blog/tendencias-de-diseno-2026-...-a1137/"/>
  <xhtml:link rel="alternate" hreflang="it" href="https://it.goodbarber.com/blog/tendenze-design-2026-...-a1102/"/>
  <xhtml:link rel="alternate" hreflang="pt" href="https://pt.goodbarber.com/blog/tendencias-de-design-2026-...-a1341/"/>
  <xhtml:link rel="alternate" hreflang="de" href="https://de.goodbarber.com/blog/designtrends-2026-...-a1441/"/>
  <xhtml:link rel="alternate" hreflang="nl" href="https://nl.goodbarber.com/blog/designtrends-2026-...-a1435/"/>
</url>

The same seven lines appear under the French, Spanish, Italian, Portuguese, German and Dutch URLs of that article in their own sitemaps, which is what makes the set reciprocal.

What I would tell you about open weights, after this

Task design beats model size. The 90-day window and the twenty-candidate cap did more for accuracy than any model choice would have. A June 2024 model at 4-bit was enough because it was never asked to search; it was asked to compare twenty summaries.

Repeatability is a feature. Temperature zero and JSON mode gave me the same answer on the same prompt today as in May. Debugging a matcher that answers differently on each run is not debugging.

The meter changes what you build. The attempts sidecar, the reruns, the fix loop: none of it would exist at a price per prompt. Zero marginal cost is not about saving money on the final run. It is about how many times you are willing to be wrong on the way there.

Verify with a second, cheaper model. bge-m3 is 1.2 GB and MIT licensed. It never decides; it reviews. Two models with different failure modes are worth more than one bigger model.

Build it twice. When there is no ground truth and no budget to make one, two implementations that share nothing, not the model, not the method, not the code, not the author, are a test suite you can afford. Where they agree, you are done. Where they disagree, you have a review queue, and 85 cells is a queue a person can read. Gemma 4 was already on the same disk in May, by the way; I ran the two-year-old one because it felt faster.

Privacy was not the argument here. Blog posts are public. But the crawl hit an internal API on a 192.168 address and nothing left the LAN, so if your corpus is not public, the same recipe runs unchanged.

Hacktoberfest 2026 comes to Ajaccio, and we are hosting

Hacktoberfest changed shape this year. It is now run by Major League Hacking and DEV, in partnership with DigitalOcean, and it stopped counting pull requests. The 2026 edition is 300-plus in-person Fests plus a global online event, all about building with open source AI: write your first skills.md, build an open-source agent, fine-tune an open-weight model. The tagline is "AI belongs to everyone", and after the afternoon described above I have no argument with it.

GoodBarber is hosting the Ajaccio Fest:

When: Wednesday, October 21, 2026, 18:00 to 21:00.
Where: CampusPlex, 95 cours Napoléon, Ajaccio, in the middle of town.
Program: doors at 18:00; at 18:30 a talk on building with open source and open-weight AI, why it matters and concrete ways to start; Q&A and open discussion at 19:15; drinks and time to talk to the people around you from 20:00; end at 21:00.
Language: the talk is in French; slides and shared resources are in English so you can keep going with the wider Hacktoberfest community afterwards.
Price: free. Registration on the MLH event page is recommended. Open to working professionals and university students.

No conference format, no pitch. We are one of the few tech companies headquartered on the island, and most developers here work alone; the point of the evening is to get them in one room on a weekday. If you have contributed to open source for years, come. If you have only been curious about where to start, come with a laptop, install Ollama and pull one model beforehand, and the recipe above fits in an evening.

Fourteen years of posts got their hreflang from a 15 GB file and an afternoon. The interesting part was never the model. It was that nothing stood between me and trying.

The price of a new word

Dominique Siacci — Tue, 08 Sep 2026 12:30:38 +0000

An app built on our platform is, at bottom, a configuration — a description read against an engine that all apps share. And that configuration is written in a vocabulary the platform defines: the section types. Articles, events, videos, products, forms. A section type is a word in the platform's language.

This article is about what it costs to add one.

From the outside, adding a section type looks like building a screen and shipping it. It never is. The difference between a feature and a word is that a feature gets used, while a word has to be understood — by everything that reads the language. Until every reader understands it, the word doesn't exist; there's just a screen with a secret.

Everyone who reads the language

Take the events section — on paper, a calendar of what's coming. Here's who has an opinion about it the day it's born.

Navigation has to know how to route to it and back out of it. The design system has to know how to dress an event — and not in one app's theme, in every theme any app might wear: an event card has to look deliberate in a minimal text-first design and in a photo-heavy one, because the word belongs to the whole language, not to the app that inspired it. Push has to be able to announce one: a new event should be able to notify subscribers exactly like any other content, without the push system containing a single line specific to calendars. Links have to reach it: an event needs an address that a shared post — or a printed flyer — can carry, and that address has to keep working long after the event itself scrolled off the screen. If the app runs the chatbot, events become material for answers: "what's the best show for a first visit?" is now a question the app is expected to handle based on its content. If an agent operates the app, creating and editing an event has to be an operation an agent can perform. And before any of that, the back office has to exist: someone has to write events — forms, fields, dates that end after they start.

Each of those is a question the new word has to answer before it's allowed into the language. The calendar screen — the thing that looked like the whole job — is one line on the invoice.

The matrix grows in both directions

Here's the part that compounds: a word added is a word maintained, and the grammar grows both ways.

Every new word has to be understood by all existing readers — that's the invoice above. But every new reader has to understand all existing words. The day we plugged a chatbot into apps' content, it couldn't just handle whatever section type was fashionable that year; it had to read the whole language, every word ever added. The day agents arrived, same story: operating an app means operating all of it. The true price of a word was never the feature work of its launch season. It's the row and the column of that matrix — paid once when the word is born, and again every time the language gains a reader, forever.

A lighter way to say something new

That price would be unbearable if it were the only option. It isn't — and this is where the economics of a platform get interesting.

Not every need deserves a word. When one app needs something bespoke, a section can be described and generated for that app alone. The generated section lives in a slot the platform already understands: navigation knows how to reach it, every theme knows how to frame it, and nothing anywhere else has to learn a thing. The price stays small for exactly that reason — it teaches nobody anything. Which is also the honest statement of what it doesn't buy: it's a local phrase, not a new word. One app speaks it; the language hasn't changed.

So there are two prices, and they're honest about what they purchase. The small one is local: the need is served today, for the app that has it. The full one is universal: every subsystem learns the word, and every app on the platform can use it, forever. A bespoke need lives comfortably at the small price. When the same need keeps arriving from different directions, it's telling us it wants to be a word — and then we pay the full price, knowingly.

The invoice is the feature

Because here's what the full price buys. Once the platform has learned a word, it works everywhere the language is spoken: every app can add an events section and inherit — with zero additional work, theirs or ours — the navigation, the theming, the push, the addresses, the answers. An extra screen works where you put it. A word works everywhere, for everyone, from then on.

That's what "adding a feature" actually means on a platform, and why it bears no resemblance to shipping a screen. The price of a new word is what makes it a word.

Trust is the net, not the eyes: can you ship AI-built software you can't review?

Mathieu Poli — Tue, 08 Sep 2026 07:26:13 +0000

Can you trust software built with AI by someone who can't read the code it produced? The whole debate keeps circling one question: did a human check it? I build these systems for a living, and the question I'd rather answer is a harder one: would anything have caught the mistake before it shipped?

The fear is a proxy

This started as an exchange on X. I had written that "did a human check it?" is the wrong question about AI-built software, and someone sent back a better one:
"AI didn't replace builders — it exposed the real gap: trust. Builders don't just assemble apps; they earn the trust to ship them. What do you think breaks that trust faster: a flaw in the AI's code, or the fear that no human ever looked?"
The fear, clearly. But I think the fear stands in for something else. Nobody actually wants a human to have read every line; people want to know that something would have caught the mistake. Almost everything written about AI and code quality answers the first demand and leaves the second one alone. Trust is the net, not the eyes.

We trust people. Planes tell the whole story.

Trust is anthropomorphic, it attaches to faces. Aviation shows how deep that runs: in a UBS survey, only 17% of passengers said they would board a pilotless plane, and more than half wouldn't buy the ticket even if it were cheaper. An Ipsos poll found 81% of Americans uncomfortable with the idea. People want a human in the cockpit, and no discount changes their mind.

Now look at what actually made flying the safest way to travel, because it wasn't the pilot's eyesight. Checklists, written after crashes, so that no landing depends on someone remembering. Two pilots, because any one person will eventually be tired, sick or wrong. Redundant instruments, mandatory maintenance intervals. Aviation never found better humans; it wrapped ordinary, fallible ones in a structure that catches what they miss. The passenger's trust goes to the pilot, and the catching is done by everything around him.
I think software is at the moment where it has to learn the same distinction.

Meanwhile, the eyes are losing ground

Even where competent eyes exist, the guarantee is dissolving. I've reviewed enough code to vouch for the first half: we miss things. Every incident postmortem I've read includes a change that a competent person approved.

The volume takes care of the second half. Faros AI's engineering report, built on telemetry from twenty-two thousand developers, measured what AI adoption does to the review pipeline: pull requests merged without any review at all are up 31.3%, and median time in review has quadrupled. Reviewers haven't gotten lazier, the queue simply outruns them. So "a human looked at it" is failing on both ends: it was never sufficient, and it's becoming rare.

None of this makes review useless. It just can't be the thing the whole weight of trust rests on, and an automated reviewer doesn't change that: still a pair of eyes bolted on after the fact, just faster ones. The net is whatever was already there before anything shipped.

The less you know, the more net you need

Here's the part the debate skips, and the reason it concerns me directly. All the standard advice about AI-generated code assumes a particular reader: a developer who inspects the output, someone who knows what to look for. For that person, AI is an accelerator with a known failure mode, and their own judgment is the control.

Take that person away. The maker who describes an app in plain language and gets working software back, the exact promise of no-code and vibe coding alike, cannot be the check. It isn't carelessness: checking requires knowing what failure looks like, and that knowledge is precisely what they didn't need in order to build. Telling them "review the output carefully" is telling them to inspect a bridge with no idea what a crack is.

That inverts the usual hierarchy: the people with the least domain knowledge are the ones who need the most protection, and they need it built into the floor they stand on, because there is no crew around them. If trust has to come from somewhere, it can only come from the system underneath, the layer whose job is to carry the judgment the person on top can't supply.

The engine is a net

For me this part was never abstract, because building the net is most of the job. I run frontend engineering at GoodBarber, an app builder, and the engine we build is, among other things, an accumulation of catches. I gave a talk about this at the No Code Summit, transcribed on our blog: the talk was about safeguards, stopping the obvious mistake from shipping without standardizing what people build. Set an ad frequency aggressive enough to degrade the reading experience, and a floor holds. Push a configuration past what the layout can carry, and the engine transforms it instead of rendering the mistake, a mechanism I've detailed in the article on our rendering engine.

None of these catches is spectacular, which is sort of the point. A net is an accumulation of places where a mistake runs out of room, each one settled once, in the structure, on behalf of people who will never know the question existed. Checklists, second instruments, walls an error can't cross: aviation wrote that shape down a century ago, and engines like ours have been writing the software version of it for fifteen years, since long before anyone called this an AI problem.

And it runs deeper than what you see on screen: my colleague Pierre-Laurent has written about privacy guarantees enforced at the binary level, a catch nobody has to remember exists.

AI on top, humans underneath

Put AI on top of that picture, because that's where it's landing. Generation raises the need for the net: more people building without the knowledge to check, and mistakes produced faster than anyone can read them. An AI generating into the void ships whatever comes out; the same AI generating into an engine meets the floors, the transformations and the walls that were already there for humans.

One principle from our own work with this, because it's the most reusable thing I know on the subject: the line between "the AI does it" and "the AI proposes it" shouldn't be drawn by how confident the model sounds, but by whether the mistake can be walked back. What's reversible can run. What isn't, waits for a human.
That line ended up deciding more than what the AI may touch: it set the pace at which my team stopped reviewing every pull request by hand, a story I've told separately. (Deciding what the AI gets to do inside our own tool was a story in itself. My colleague Dominique has told it.)

That, I think, is the durable place of these engines in the AI era: carrying the part of trust that neither the model nor the maker can carry alone. Built by humans, with AI generating on top.

Trust is a property of the system

So, back to the fear. Promising that a human looked won't cure it; that promise is already breaking inside professional teams, and it was never available to the maker building alone. What cures it is catches you can name.

Deciding which mistakes deserve a catch, and which are cheap enough to let through, is judgment work, the kind that doesn't get automated away when generation gets cheap. And every check nobody formalizes doesn't disappear. It joins the bill someone pays later, usually at the worst time.

Some will read all this as giving up on humans. I see it as the opposite: taking what careful people do and making it survive their absence. The rule I come back to is the one I'd offer anyone building with AI today: you don't fully hand off what you can't undo.

Photo: Maya Alexa G. Romero / Unsplash

The most expensive thing we could sell you is a fork

Dominique Siacci — Thu, 03 Sep 2026 13:04:19 +0000

The request arrives regularly, and it's always reasonable: we love the platform — we just need a version of it that's ours. One extra screen. One different behavior. One exception to a rule that makes sense for everyone else but not for them. From the customer's side, it's the most natural ask in software: they pay, the need is real, and the code already exists. How hard can a copy be?

Our answer is no. It has been no for as long as the platform has existed, and it will survive any deal size. Not because the need doesn't count — because refusing the fork is an architecture policy, maybe the oldest one we have.

A fork is the product minus its future

A fork costs nothing on the day you create it. Version control makes it a keystroke. Every cost comes after, and it compounds.

A forked engine leaves the inheritance flow. Everything that makes a platform worth paying for — the changes every app absorbs at its next build: the OS deprecations quietly handled, the new capabilities that just appear — stops reaching it. Someone would have to re-apply each of those changes to the fork, by hand, forever, on a codebase that drifts a little further from the source every month. That someone has better things to do, and eventually doesn't do it.

So "a version just for us" is not what we'd actually be selling. We'd be selling a version nobody keeps alive — the product, minus its future. The evolution is the product. A fork is a way of buying the part that was already done and cancelling the part they were paying for.

Where the need gets to live

The need behind the request is real, though, and refusing the fork doesn't make it go away. What's negotiable isn't whether the need gets served — it's where it lives.

The old principle says it in six words: open for extension, closed for modification. The engine is closed; the surface around it is the offer. Custom-code sections, custom widgets, custom navigation — places designed for behavior we never anticipated. And more recently, a bespoke section can be described and generated without a line of the engine changing underneath it.

Extension doesn't even have to mean living outside the engine. Sometimes the specific need becomes capability embedded in every build and expressed only where it's enabled — injected at compile time, dormant everywhere else. That may sound like a fork wearing makeup, but it differs in the one way that matters: the engine stays one. Every build still comes from the same source, still inherits everything, still moves forward with the fleet. Nothing has left the flow.

What the refusal costs us

Here's the part that took longer to understand: a no-fork policy is a discipline for us before it's a constraint for anyone else. You can only keep refusing forks if the extension points are good enough that the refusal isn't a dead end — and extension points are only good if the engine behind them is built for it.

Which is where the unglamorous principles earn their keep. Components with one responsibility, that evolve only for that responsibility. Modules that depend on each other as little as possible and talk through interfaces. Functionality grouped with the functionality it belongs with. Written down like that, it reads like a textbook page — until you see these rules as the thing that makes the "no" possible. Every one of them exists so that the engine can stay shared while the needs it serves diverge.

And the requests themselves feed the discipline. A fork request that no extension point can absorb isn't a customer to talk out of it — it's a spec for the next extension point. I won't claim we convert every refusal that way; we don't. But the ones we did convert are the reason the next request usually finds a place to live.

The only "just for us" that lasts

What a customer really asks with "a version just for us" is: does my need count? The answer that holds up over years isn't another platform. It's another word in the platform — a capability added to the shared engine, that every app inherits, including theirs.

Their edge case today, everyone's feature tomorrow. It's a slower yes than a fork, and a less flattering one. It's also the only version of "just for you" that will still be alive in three years.