Five OSS authors on where fast software needs a boundary (2026)

From August 10 through August 17, 2026, five fresh posts and release decisions put the control point in different places. Armin Ronacher changed the file convention around an agent; Addy Osmani defined where an agent should stop; DHH treated a plugin registry like a package ecosystem; Daniel Stenberg made performance visible before optimizing it; and Linus Torvalds let late fixes in while still reverting code that was not ready. 1 2 3 4 5

The common thread is specific: when software moves faster, each author makes a different boundary easier to see.

Five choices in one view

Author	Fresh signal	Where the boundary goes	Question for a tech lead
Armin Ronacher, creator of Flask	On August 16, he said he had removed `CLAUDE.md` files and found that telling Claude Code to read `AGENTS.md` worked well enough. 1	Keep project instructions in a tool-agnostic convention that more than one agent can read.	Which parts of your workflow belong to the repository rather than to one vendor's filename?
Addy Osmani, engineering and DevRel leader	His August 14 essay separates `goal` from `loop`, then warns that a clear task still needs a human taste check. 2	Define the stopping condition before delegating; keep judgment with the person who owns the outcome.	Can your team state what "done" means in a testable sentence?
David Heinemeier Hansson, creator of Ruby on Rails and Omarchy	On August 16, he said Omarchy's 300-plus community plugins should be treated like packages, with automated security review and versioning planned. 3	Let an open extension surface grow, then add package-style trust and update controls around it.	What changes when your community customization layer becomes a distribution channel?
Daniel Stenberg, curl maintainer	In his August 14 post, he chose a local machine, shell scripts, gnuplot, and a 20-minute build cadence to make performance regressions visible. 4	Prefer a usable feedback system now over an ideal measurement platform later.	Which imperfect signal would help your team catch regressions this week?
Linus Torvalds, Linux maintainer	Linux 7.2 shipped on August 16 after a busy final week. Torvalds accepted the release date while calling late reverts the correct response to code that caused problems. 5	Keep the calendar stable while preserving the authority to remove an unsafe or unready change.	Which decision can remain on schedule, and which change still deserves a veto?

Armin Ronacher: put the instruction where the project can own it

Ronacher, the creator of Flask, wrote on August 16 that he had largely removed CLAUDE.md files from his repositories because he no longer used Claude Code much. When he needed to debug an issue, he found that telling the tool to read AGENTS.md worked well enough. 1

The interesting decision is the filename. CLAUDE.md makes the instruction file part of one product's vocabulary. AGENTS.md describes the role instead. That gives a repository a chance to carry its working rules across agent tools without rewriting the project every time the preferred client changes.

Ronacher did not present a standard or a migration guide. He reported a small working choice from his own repositories. For a team, the useful test is whether the file contains project rules that any coding agent should understand: how to run the test suite, which directories are generated, what a safe change looks like, and what the agent must inspect before editing. Tool-specific instructions can stay beside that shared contract.

The choice also gives friction a useful place. A repository-owned instruction file can say which commands are read-only, which paths need approval, and which checks must run before a result is reported. The agent gets a clearer route; the project keeps the rule.

Addy Osmani: delegate the task, keep the verdict

Osmani's August 14 essay describes a practical split between two primitives. A goal pushes one bounded task toward a measurable finish line. A loop repeats work on a timer or in response to changing external state. He defines a loop as an autonomous feedback cycle in which an agent acts, tests its result, and adjusts until a specific goal is met. 2

His example of a goal is concrete: raise a homepage's Lighthouse score to 90 or above, with a limit of five tries. His example of a loop is operational: check a pull request every five minutes, address review comments, and fix failing CI. The first needs a finish line. The second needs a schedule and a changing input. 2

The harder boundary appears when he describes a task he nearly accepted without looking closely enough. He asked an agent to study competitors and prepare possible changes. The generated implementation would have added substantial complexity for limited gain, in his view. His lesson is direct: "You’re delegating the task, and then you are actually checking back that it’s meeting your bar." 2

Osmani also separates generation from verification. One agent can draft a change, while another checks the specified conditions. That second check still cannot decide whether the product is tasteful, useful, or worth the added complexity. He says tasks involving human taste, subjective design, or open-ended exploration are poor fits for loops when the team cannot define what "good" means. 2

That distinction changes how a team should write automation requests. A request such as "make the interface better" gives the loop no reliable stopping point. A request such as "reduce the mobile LCP below 1.8 seconds without changing the public hook API, and stop after ten turns" gives the loop a measurable target and a limit. The product owner still decides whether the result earns a place in the product.

DHH: a plugin registry becomes a package ecosystem

Hansson's August 16 post concerns Omarchy's community plugin repository. He said the project had passed 300 plugins and asked users to treat the code like an npm package, a RubyGems gem, or an AUR package. He added that automated security reviews and versioning were planned. 3

The context is a fast-growing customization surface. The Omarchy Plugins marketplace invites users to browse community-built plugins for Omarchy Quattro, inspect source, copy an install command, and shape a shell around their workflow. 6 That product shape makes discovery easy, while the code still arrives from a community registry.

Hansson's warning is therefore about category, not only count. Once people install extensions through a recognizable marketplace, the registry starts to behave like a package manager. Users need to know who published an item, how it changes, whether a new version is compatible, and whether a review has found a problem. The trust boundary sits between the friendly catalog and the code it delivers.

The planned controls are still plans. DHH did not claim that automated security review or versioning was already operating in the post. That makes the design question more useful: should a project wait for the registry to become difficult to manage, or define package-like rules before the catalog becomes the default path for customization?

For a platform team, the equivalent moment arrives when internal plugins, actions, templates, or agents become easy for many teams to install. A catalog is a product surface. It needs ownership, update semantics, and a response path for unsafe or abandoned entries.

Daniel Stenberg: start measuring before the perfect platform exists

Stenberg's August 14 post starts with the questions every performance-sensitive project eventually faces: how fast is fast enough, whether a regression has appeared, and what exactly needs to be fast. He writes that curl had discussed a performance suite for years, then chose to begin with a local machine, shell scripts, and gnuplot rather than wait for a more elaborate platform. 4

The first setup updates curl from Git, builds it, runs tests, records logs, and turns the results into summaries and graphs. A cron job starts a new round every twenty minutes. Stenberg says he chose tools he already knew because "something should be better than nothing." 4

He is careful about what the signal can support. The machine is also used for daily development, so the results vary. The tests depend on the exact hardware, libraries, servers, and other conditions. He expects the measurements to be most useful for spotting an unintended short-term degradation, rather than comparing every number across every historical environment. 4

His safeguard is a manually chosen threshold, which he calls a "stake." A test can be compared with that threshold even after the environment changes; if a shift is expected and acceptable, the team can move the stake. That keeps a graph from pretending to be a verdict while still giving maintainers a signal worth investigating. 4

Stenberg also records the cost of optimization. curl merged changes that reduced allocations for an HTTP download, then found that one change made a main structure larger. His conclusion is plain: improvements in one area can cost something in another, so each change needs enough tests and data to decide whether the trade is acceptable. 4

The operational lesson is modest and useful. A measurement system can start with one machine and still create a feedback loop. The team must label its conditions, keep the comparison narrow, and resist turning a convenient number into a universal benchmark.

Linus Torvalds: hold the release date, revert the unready code

Linux 7.2 was released as stable on August 16 after a busy final week. Phoronix reports that the cycle included late driver and networking fixes, plus a revert of the DRM scheduler after the new default caused a regression. 5

Phoronix reproduces Torvalds's release announcement. The direct LKML message is also available to readers who can access it: Linux 7.2 release announcement on LKML. 5

Torvalds wrote that the final week was "bigger than I would have wished for," then added: "if I delayed releases for that reason we'd probably never have a release at all." He described the late DRM reverts as "the correct way to deal with 'oh, that code wasn't ready and caused problems'." 5

That is a two-part release policy. The calendar does not move merely because the patch queue is busy. The contents can still change when a specific regression shows that code is not ready. Torvalds keeps schedule discipline and technical veto in the same process.

The distinction matters for teams using automated discovery or review. A large queue can be normal for a project that has better ways to find problems. A demonstrated regression still deserves a revert, even when the revert is inconvenient and the release is close. The release tool can enforce the date; maintainers still decide whether a change survives it.

Questions for the next design review

Move instructions to the project boundary. Put tool-independent agent rules in a repository-owned file, then keep client-specific behavior separate. 1
Write the stopping condition before the prompt. If a task has no testable finish line, decide whether it needs a human-led exploration instead of a loop. 2
Treat extension catalogs as supply-chain surfaces. Define review, versioning, ownership, and removal paths before the registry becomes the normal installation route. 3
Start a narrow performance signal. Record the machine, dependencies, test conditions, and threshold so the number answers one regression question honestly. 4
Separate calendar authority from change authority. Keep the release date predictable, while giving maintainers a clear rule for reverting code that produces a known regression. 5

These authors are handling speed at five different seams: repository instructions, agent completion, package trust, performance evidence, and release control. The shared design question is narrower than whether software is getting faster. It is which boundary will make the next fast change safe enough to judge.

References

1
Armin Ronacher on AGENTS.mdx.com
2
Addy Osmani, Practical Loop Engineeringaddyo.substack.com
3
DHH on Omarchy community pluginsx.com
4
Daniel Stenberg, curl performancedaniel.haxx.se
5
Phoronix, Linux 7.2 releasedphoronix.com
6
Omarchy Plugins marketplaceomarchyplugins.com