The factory needs a border (2026)

Between July 20 and July 26, five OSS authors drew different boundaries around faster software. Armin Ronacher challenged a fuzzy rule for AI-written repositories. Addy Osmani described the review gate that keeps an agentic software factory from going dark. Linus Torvalds accepted AI-assisted kernel fixes while calling Linux 7.2-rc5 too large. Daniel Stenberg put an experimental security feature behind explicit curl switches. DHH returned to a product argument about small teams and constraints.

The common question is narrower than whether AI is good or bad: what exactly is allowed to cross the boundary, and who can verify it?

Five boundary decisions

Author	Fresh signal	Boundary to inspect
Armin Ronacher	Codeberg's "mostly generative AI" rule leaves authorship hard to measure.	Write policy around observable behavior, not percentages nobody can audit.
Addy Osmani	A software factory can run with the lights on or off.	Give autonomy only where verification is cheap and reliable.
Linus Torvalds	Linux 7.2-rc5 is large, but the release is still ordinary rather than alarming.	Treat AI-discovered fixes as input, not as a reason to relax release discipline.
Daniel Stenberg	curl 8.22.0 will carry experimental HTTP Message Signatures support.	Make new protocol behavior explicit, reversible, and testable.
David Heinemeier Hansson	AI makes the small-team, self-funded path more accessible to people who could not previously build everything themselves.	Decide which constraints protect product quality before adding scale.

Armin Ronacher: a policy needs a legible boundary

Armin Ronacher, the software developer behind Flask and Jinja2 and founder of Earendil, wrote on July 24 about Codeberg's decision to exclude projects that are largely written with generative AI. He accepts that the association can make that choice. His objection is to the word "mostly" and the enforcement burden it creates. 1

"In an actively developed codebase, what does 'mostly' mean, and who can still tell?"

That is a governance question disguised as an authorship test. Ronacher says he could not reliably assign authorship percentages to many of his own recent projects. He would prefer a clearer rule: if the concern is autonomous repository spam or abusive resource consumption, write rules for those behaviors directly. A vague middle ground pushes interpretation onto moderators and community norms. 1

For a project maintainer, the useful distinction is between a tool's provenance and its effects. Provenance can be difficult to reconstruct after a mixed human and machine workflow. Effects such as spam volume, resource consumption, license violations, or unreviewable changes are easier to define and enforce.

The question for an engineering team is simple: can a contributor explain the rejection condition without first estimating what percentage of a patch came from a model?

Addy Osmani: keep the lights on where judgment is expensive

Addy Osmani, an engineering and evangelism leader whose work has covered Chrome, AI developer experience, and coding-agent quality, published "Software Factories, Light and Dark" on July 20. He separates three layers: a loop that repeats a task, a harness that constrains the loop, and a factory that runs many harnessed loops against a queue of work. 2

His sharpest line is also the one most useful to architecture reviews:

"A software factory is many harnessed loops running at once, fed by a queue of work and drained through a review gate into production, with humans owning the whole thing from above. It is not a bigger agent; it's an org chart made of loops." 2

The "dark" version removes the human reading step. Osmani's concern is not that every generated change is immediately broken. It is that a team can keep tests green while the amount of code no person understands grows faster than the team's ability to inspect it. He calls the gap "comprehension debt" and describes verification, rather than generation, as the limiting resource. 2

That gives a more useful autonomy rule than "human in the loop" as a slogan. A short, narrow change with an immediate and hard-to-fake oracle may earn unattended execution. A change that affects an authentication flow, billing system, public API, or year-long architecture decision needs a person upstream, reading the plan before the diff becomes expensive.

The question for a tech lead is: which changes can your system verify quickly, and which decisions must be read before they are implemented?

Linus Torvalds: AI input does not cancel release discipline

Linus Torvalds, the creator and maintainer of the Linux kernel, posted the Linux 7.2-rc5 announcement on July 26. The direct lore.kernel.org page was behind a bot challenge when checked; Phoronix reproduced the announcement and linked the original message. 3

The release report says many fixes continue to surface through AI and LLM agents, including audio work and a FireWire networking issue that had been in mainline since 2009. Torvalds' own note is more restrained. More than a third of the release was networking, partly because work had accumulated during conference travel, and he wrote:

"So it's a bit too big for my liking, but nothing in there strikes me as particularly strange or scary." 3

That is a useful separation of signal from volume. AI-assisted discovery can increase the number of valid fixes that reach maintainers. It can also increase the amount of material that has to be sorted, reviewed, and scheduled. A large release candidate is not automatically evidence that the process is failing, but neither is a fix found by an agent evidence that the release should move faster.

The question for a kernel or platform team is: what evidence lets you accept a machine-discovered change without letting the discovery mechanism set the release cadence?

Daniel Stenberg: make experimental protocol behavior explicit

Daniel Stenberg, curl's founder and lead developer, published a post dated July 27 whose publication timestamp places it late on July 26 in the channel's UTC-08 view. He described experimental support for HTTP Message Signatures, the mechanism defined by RFC 9421 for signing selected components of an HTTP request so they can be checked for alteration across proxies, load balancers, CDNs, and other intermediaries. 4 5

The feature adds four command-line options: one for the algorithm, one for the signing key, one for the key identifier, and one for the headers or request components to sign. Ed25519 is the default algorithm; HMAC-SHA256 is also supported. Stenberg says the feature is merged and is planned for curl 8.22.0, but it must be explicitly enabled in the build and is not recommended for production yet. The project reserves the right to change it without backward compatibility. 4

This is a small feature with a good release boundary. The capability is available for testing, its production status is visible, and the project tells users where compatibility guarantees do not yet apply. The four flags also make the security decision inspectable in a shell script instead of hiding it inside an opaque default.

The question for a platform team is: when a security-sensitive feature is experimental, can a user tell what is enabled, what is signed, and what may still change?

DHH: constraints are part of the product

David Heinemeier Hansson, co-owner and CTO of 37signals and creator of Ruby on Rails, Hotwire, Kamal, and Omarchy, returned to the small-team argument in a July 26 post about a conversation with David Senra. His claim is that AI changes who can take the bootstrapped path. Earlier, a person with an idea generally needed to be a designer or programmer to build the first version alone. Now, he writes, "The Idea Guy really does have a place and a path." 6

The technology point is secondary to the product decision. DHH says his own preference is quality, control, and independence, even when that means staying a smaller "lifestyle business." He uses Vaxry's Hyprland window manager as an example of a compelling product made under tight constraints, and argues that a team should choose its ambition before accepting the operating model that comes with outside capital. 6

For an engineering leader, this is a reminder that scale is not a neutral upgrade. More capital, more people, and more automation can increase output while changing who gets to say no, which interfaces get simplified, and how quickly a team can reverse a bad product decision.

The question is: which constraints are you removing because they block the product, and which are you removing because they protect you from making a worse one?

What to put behind the boundary

These five posts point to four concrete rules for teams adopting faster software production:

Define contribution policies in terms maintainers can observe and apply. If the real issue is spam, abuse, licensing, or review load, say that directly.
Assign autonomy according to verification cost. Small, deterministic loops can run unattended; long-lived architectural decisions need a human before implementation.
Keep release and protocol boundaries explicit. AI-discovered fixes still need scheduling discipline, and experimental security features need visible opt-in and compatibility warnings.
Treat constraints as product decisions. Before scaling a team or a factory, decide which forms of control and reversibility the product needs to keep.

The code can be generated faster than a team can agree on what should be accepted. The useful work this week was defining that acceptance boundary in terms people and tools can actually enforce.

The factory needs a border