Cloudflare.
Sandia.
Sandia Again.
NIST.

At 12:09 a.m. on August 24, I opened a pull request against a NIST repository.

Technically, that means the last one missed August 23 by nine minutes.

That is not how the day felt.

The working stretch had started hours earlier. At 2:57 in the afternoon, I had opened a pull request against Cloudflare's CI project. At 11:25 that night, I opened one against Wiretap, an open-source project from Sandia National Laboratories. Two minutes later, I opened another, separate Wiretap pull request. Then came NIST, nine minutes across midnight.

I looked at the sequence.

Cloudflare.
Sandia National Laboratories.
Sandia National Laboratories again.
NIST.

All four pull requests are still open as I publish this. None has been merged. That matters. A submitted patch is not an endorsement by Cloudflare, Sandia, or NIST, and the maintainers get to decide what belongs in their projects.

But acceptance was not what had me staring at the list. It was the fact that four independently defensible contributions had emerged from one continuous stretch of trying to understand and use unfamiliar systems deeply enough to improve them.

Cloudflare: find the seam that is already there

The Cloudflare contribution came out of a larger experiment I have been building around source control and CI. I have been exploring what happens if GitHub remains useful as a public forge and collaboration surface but stops being the necessary operating system underneath source storage, agent execution, CI, and deployment.

The architecture I was working toward put more of that machinery on Cloudflare. While tracing how Cloudflare's own CI project represented source control, I found something useful: much of the abstraction I needed was already there.

There was a SourceControlProvider. There was an adapter layer. Cloudflare Artifacts was already the default provider. The system had a seam.

The problem was that the public boundary did not fully let an external provider inhabit it. The contribution was therefore not to invent another provider framework beside Cloudflare's. It was to make the existing architecture genuinely extensible: export SourceControlProvider, expose createAdapter and the related types, and widen CIWorkflow.getProvider() so a custom provider can type-check cleanly while Cloudflare Artifacts remains the default.

That is a pattern I keep coming back to: find the seam that already exists. Make it real rather than building a parallel system around it.

Sandia: a real dual-stack bug

Later that evening, I was working through Sandia's Wiretap. I had been using an agent-assisted workflow inside a container to inspect the project while testing its nested userspace networking path. I did not begin with a plan to find a Sandia bug. I was trying to understand the system well enough to use it.

That work took us into UserspaceSocketBind.Open(), where something looked wrong in the very specific way that makes you reread a function because you assume you have misunderstood it.

A variable named ipv4 was being opened using udp6. The ipv6 variable was declared but never actually opened. The same receive path was added twice. bind.ipv6 therefore never got a live IPv6 socket. The send path still selected the IPv4 socket for IPv6 destinations, and cleanup only closed the IPv4 side.

This was not a style preference. It was not an excuse to refactor Wiretap. It was a small, concrete dual-stack correctness bug.

The patch separated the IPv4 and IPv6 socket paths, made IPv6 sends use the IPv6 socket, closed both sides correctly, and added a regression test. No routing redesign. No CLI changes. No unrelated cleanup.

That could have been the interesting contribution for the evening.

It was 11:25 p.m.

Sandia was not finished.

Sandia, again

The second Wiretap issue was a completely different kind of problem.

Wiretap's status command already had a good interface for people. It printed the network as a terminal tree. A human could look at it and understand topology quickly.

But a script cannot really look at a tree. Neither can a test harness, control plane, or software agent. They have to parse presentation output, which quietly turns a visual interface into an undocumented machine protocol.

The answer was not to take the tree away. It was to stop making machines pretend they were humans.

The second Sandia patch added wiretap status --json while preserving the existing terminal tree as the default. It reused the topology Wiretap already assembled, projected public status fields into an explicit structure, sorted data that could otherwise arrive nondeterministically from concurrent operations, represented network-information failures as structured data, and deliberately did not serialize private or preshared keys.

The conceptual difference between the two Sandia contributions is useful. #112 repaired execution correctness. #113 improved the boundary between runtime state and the humans or machines trying to understand it.

By the time I opened the second Sandia pull request, I had to look at the sequence again.

Two distinct upstream changes to a Sandia National Laboratories repository in the same working stretch.

The proper noun does enough work on its own.

NIST: make the diagnostic tell the truth

Then the calendar turned over.

Nine minutes after midnight, I opened usnistgov/metaschema-java #428.

The NIST bug was small. That made the ending better, not worse.

Metaschema Java's generate-schema --as path supports JSON and XML. But its help text and invalid-value diagnostic were drawing valid choices from a broader databind Format enum, which also contained YAML. The command therefore advertised a capability the schema generator did not actually have.

The fix was essentially to make the public description of the system derive from the authority that actually governs it: SchemaFormat, not the broader Format. The help was corrected from a source-format description to a generated-schema-format description, and regression tests covered both the help text and invalid YAML diagnostic.

I spend a lot of time thinking about standards, contracts, interfaces, and what systems promise to the people relying on them. So there was something fitting about ending the session here.

An interface should tell the truth about the system behind it.

Four patches, one kind of boundary

Seen from far enough away, the four contributions are variations on one problem.

Cloudflare had an architectural seam whose public boundary was narrower than the architecture behind it. Wiretap had a dual-stack execution path whose bookkeeping did not match the abstraction. Wiretap also had useful runtime state trapped inside presentation-oriented output. NIST had a public diagnostic surface broader than the implementation behind it.

In every case, the interesting work was at a seam: where one provider meets another system, where IPv4 meets IPv6, where a terminal interface meets automation, where a CLI claim meets the code that actually defines capability.

The quality of a system shows up at its seams.

That is also where agents become interesting to me.

What the agents changed

I am not a conventional software engineer by background. My work has crossed federal telecommunications policy, accessibility, standards, product design, systems thinking, and a lifetime of being close to computers without making software engineering my primary professional identity.

None of that means I lacked opinions about architecture. Policy and standards work train you to look for boundaries, authorities, incentives, state, failure modes, and the difference between what a system claims and what it actually does.

Historically, however, there was a large gap between seeing one of those problems and being able to carry the observation all the way into a tested patch inside an unfamiliar repository.

Agentic development tools changed the economics of that gap.

I did not manually type every character of these patches unaided. That would be the wrong story. Agents performed a great deal of inspection, implementation, testing, and iteration with me.

But the opposite story would be wrong too. The agents did not independently decide that these four changes deserved to exist.

The human work was selecting the system worth investigating, deciding which behavior was actually a bug, understanding what the surrounding architecture was trying to do, rejecting hypotheses that were not proven, constraining the scope, asking for evidence, and deciding whether a patch was sufficiently narrow and defensible to send upstream.

One of the more important decisions from the Wiretap work was not a pull request at all. We had a promising hypothesis for a separate latency-related issue, but not a deterministic reproduction. It stayed out. Another persistence idea was clearly feature-sized rather than bug-fix-sized. It stayed out too.

Agents lowered the cost of exploration and implementation. They did not decide what deserved to exist.

The playing field

I have been carrying around a line for a while: the playing field levels when everyone uses the same tools.

I think this day gave me a more precise version of what that might mean.

It does not mean everyone suddenly possesses the same expertise. It does not mean software engineering stops being a discipline. And it certainly does not mean judgment becomes less important because code becomes easier to produce.

It may mean that more people can bring the expertise they already have all the way to an executable artifact.

A telecom-policy person can test an infrastructure hypothesis instead of stopping at a memo. A standards person can inspect and repair the tool implementing the standard. An operator can trace the actual failure path. A product thinker can examine the real extension seam instead of filing a vague feature request. A sophisticated user can move from describing a defect to presenting a regression test and a minimal fix.

The boundary between user and participant moves.

That changes the economics of technical participation. The old path from I see a problem to I can responsibly send a fix upstream required a substantial amount of specialized implementation labor before the domain insight could even become reviewable code. That cost has not disappeared, but it has dropped sharply.

If raw code production becomes less scarce, the scarce things become easier to see: problem selection, domain knowledge, systems understanding, taste, skepticism, scope, and responsibility.

Those are not new skills. What is new is how directly they can now act on software.

The distance is getting shorter

I do not know whether any of these four patches will merge. That is the ordinary and healthy part of open source. Maintainers will review them, disagree with them, modify them, accept them, or reject them according to what their projects need.

The thing I cannot stop thinking about happened before review.

In one long working stretch, I moved from using serious technical systems to reading them, testing them, finding narrow problems, producing evidence, and sending possible fixes back upstream.

The remarkable part may not ultimately be that I sent four pull requests in a day.

It may be that the distance between seeing a problem and being able to responsibly contribute a fix has suddenly become much shorter.

And if that is true, the interesting question is not whether everyone becomes a programmer.

It is what happens when the people who already understand a domain deeply — policy people, operators, researchers, standards people, designers, subject-matter experts, sophisticated users — gain enough implementation leverage to participate directly in systems they previously could only describe, regulate, request changes to, or work around.

I do not think expertise is disappearing.

I think expertise is getting a shorter path to the machine.

Cloudflare. Sandia. Sandia again. NIST.

Nine minutes after midnight, I looked at the list one more time.

If the boundary between observer and participant can move that much in one day, I want to know where it goes next.