I never read the Swift code

In spring 2026 I accidentally became a Swift open-source maintainer. With 5,000+ stars. I don’t speak Swift. I have never read the code. (Well, sometimes I glimpse at it.)

The project is apfel, a command line tool that talks to the Apple Intelligence model already sitting on every modern Mac running macOS Tahoe. A few people asked me how that works. So here is the short meta thought.

Who wrote the code

apfel is built in Swift. I never bothered to learn Swift. The code was written by Opus 4.6, then Opus 4.7, with Codex (at the time 5.5) doing review and refactor. Those were the models as of May 2026. AI First all the way.

And it is not just the one CLI. Around it there is a small tree of tools, among them a SwiftUI chat client with speech in and speech out. Same principle. I did not read that code either.

How does this even hold together?

That is the question I get most. My answer has three parts.

1. TDD

Test-driven development. Tests first. The tests are assertions about behavior, not about implementation. If the tests pass, the thing works for the cases I care about.

I don’t need to know how the Swift does it. I need to know what it does. The tests say what it does.

2. Specs

apfel implements an OpenAI-compatible HTTP API. It runs as a local server on localhost:11434, so you can drop it in anywhere your tools expect OpenAI.

That spec exists. I did not have to invent it. There are public conformance tests, I can run them, and if they pass, my server behaves like the spec. Somebody else already wrote down what “correct” means. I just check against it.

3. Quality control loops, again and again

• Every PR runs the suite.
• Every release is dogfooded.
• Every reported issue starts with a failing test, which the AI then has to make pass.

A bug report is not a reason to go read code. It is a reason to write a test that fails, and then hand it to the AI.

The interesting question

The interesting question for AI-built open source is not “did an AI write the code”.

The interesting question is “did the tests catch the regression”.

If yes, the language is a detail.

The catch

But … here is the catch: having an open-source project is real work, even when the code is automated.

Because the decisions, the responsibility, in the end, still lie with me. People file issues. People depend on the binary. People ship products on top of it. That part does not get automated away.

It just shifts. From “where do I put the semicolon” to “is this the right next behavior to add”.

That is the job now. Deciding what the thing should do, writing down how to check it, and owning the result when someone relies on it.

Where this goes

I think this is what a lot of open source will look like in two years. We will see.

If you want to look at how it is set up, the repo is public: github.com/Arthur-Ficial/apfel. Free. MIT.