E-commerce platform Shopify wants to make reading source code a thing again. And it has an unlikely ally for its back-to-the-roots approach: AI agents. The company is launching a new storefront theme for its customers, aka “merchants,” that it claims is completely understandable by anyone with even a smidgen of HTML knowledge. It is designed to be simpler for both people and machines to digest and hack against. Shopify hasn’t named this new theme yet, but is unveiling it in developer forums as the probable successor to Horizon, its current JSON-heavy base theme, which customers use to customize their own Shopify pages. The new code is mostly HTML, interpolated by the company’s own block-based Liquid templating language, which is also fairly easy on the eyes. When merchants peek into the templates directory of this new theme, they will see plain-text files of easy-to-parse code, not long strings of inscrutable JSON. This theme has 93% fewer lines of code than Horizon. The company’s increasingly popular AI service is driving this rearchitecture redesign. “Every leading model already understands HTML. It is expressive, local, and token-efficient,” wrote Ben Sehl, Shopify product director for storefronts, in a missive on X. And Shopify’s Liquid template language meshes perfectly with HTML. From merchants to merchandisers In his post, Sehl recalled a decade ago, when he was a merchant himself, and Shopify only offered a basic template. It was easy for Sehl, then a novice web coder, to modify with a third-party starter kit. Over time, Shopify enriched the templating, allowing users to become full-fledged designers. The Online Store Editor gave them more control over how a page and its various “block” components would look like. Every button and knob could be customized. Flexibility begets complexity, however. The user template instructions were converted to JSON. “That trade-off gave merchants far more control, but it came with a developer-experience cost: you could no longer understand a page by reading one file,” Sehl wrote. “The moment templates became JSON, they stopped being a great developer surface. They became an auto-saved output,” Sehl wrote. Good for the bot, good for the human Recently, Shopify added an AI assistant called Shopify Sidekick, which gave users even more control over how they designed their pages. No longer would they have to remember that #0000FF means ‘Blue’ in HTML speak. They just “declare” the background color to be blue and the agent will make it so. This year, 20% of Shopify merchants are using Sidekick to edit their themes, making 25 million edits this year alone. Consequently, Shopify faced the task of simplifying things for the AI agent itself. It turns out that agents want the same things as humans: code that is easy to read, explicit contracts, and constructive feedback. So the company has reorganized its theme architecture using these qualities as first principles (while maintaining existing Liquid themes in a “forever API”). While these changes better support our new AI overlords, the underlying code also became more readable to humans as well. “The deeper problem with serialized configuration isn’t that JSON is inherently bad. It’s that configuration has a constrained vocabulary,” Sehl explained. Reveal source code For this new base theme, Liquid gained a new syntax and parser, built with some additional discipline to execute more complex instructions on the back-end. What the user sees, however, are composable, typed blocks that fit easily alongside ordinary HTML. In this new approach, each user-designed theme is given a special directory and files with instructions and pointers of how additional artifacts should be generated. Furthermore, an expanded doc tag contains examples and instructions on handling contracts and snippets. Key to the new theme is a new composable block tag, which contains a set of nested parameters describing page components that the developer can feed with values, configurations, overrides, and other instructions. React devs will recognize parameters as doing a similar job to React’s props, but without the need to create a virtual DOM. Also familiar to React users will be the new partial primitive, which allows a specific region of a page to be updated without needing to re-render the entire page. The team also added standard actions, a collection of event triggers for the site, such as, say, updating the shopping cart. “This one primitive will let us remove thousands of lines of reactivity code from Horizon,” Sehl wrote. Shopify also developed 20 new rules to ensure generated themes meet the company’s policies around contracts, structure, validation, complexity, nesting, and file-size limits. And if the user wants to get fancy, Liquid now allows for logical capabilities such as Boolean expressions, infix operators with precedence, and literal arrays and objects. At some point in the future, the Tailwind CSS framework will even be supported. All these improvements should simplify things for the merchant at home, trying to assemble a customized storefront. For instance: In a declarative, settings-driven architecture, the developer must anticipate how many buttons they plan to use before they start the layout. With HTML, when the merchant discovers they need additional buttons, they just wrap them all in an HTML div tag. Palatable for AI AI experts are slowly coming around to the idea that the best diet for AIs is not dense, symbolic-heavy code — at least for non-coding tasks. Like humans, LLMs seem to do better on a diet of more easily-understandable prose (LLMs were, after all, trained on human language). One developer, for instance, found that SQL was easier to process compared to the Domain Specific Languages (DSLs) of 17 different tools. For prompting, Anthropic recommends the semantically-rich XML, whereas a decade ago that format was largely cast aside by the industry for the leaner, less-verbose JSON. Perhaps Shopify’s efforts to appease AI may lead not to more slop but to a movement for more readable code. ®

AI seemed simpler in 2024 when Anthropic released the first version of the Model Context Protocol (MCP), an open standard for connecting AI applications to external systems. Back then, developers primarily used the protocol on their personal computers. As those laptop-bound demos were adapted for multi-client enterprise use, MCP servers moved into the cloud, where the original design quickly created scalability problems. On July 28, MCP's maintainers plan to finalize the protocol's 2026-07-28 revision, bringing many changes – including some that aren't backward compatible – that reflect some "hard lessons" the core MCP team learned over the past two years, said Anthropic technical staff member David Soria Parra in a livestream Tuesday. The 2026-07-28 revision will come with the "most substantial changes we have made to the specification, probably since adding authorization," Parra said. "A lot of things that made MCP are gone." Parra claims the new MCP will be easier to deploy and use. If users have been updating their SDKs, they shouldn't have much problem upgrading. But he also warned that the underlying data transfer mechanism has totally been rebuilt, which "makes things on the wire a bit more complicated than they used to be." Protocol-level session tracking will no longer be required. For those who rolled their own MCP engine, some long days of reconfiguration may be ahead. "If you built your own implementation, it's going to be a lot of uplift to make this correct," Parra admitted. Anthropic donated MCP in 2025 to the AAIF, a Linux Foundation fund co-founded by Anthropic, Block, and OpenAI. By that time, the SDK was being downloaded over 97 million times a month and at least 10,000 MCP servers had been set up. MCP is now stateless like the rest of the internet The chief change is that the new revision removes protocol-level sessions, allowing each request to be handled independently. This "stateless" approach, common in the cloud-native world, is used to scale web services behind a fleet of load balancers. Anthropic originally built MCP so that servers could be built to expose resources, tools, and prompts. An LLM-connected application can host clients to communicate with these servers via JSON-RPC 2.0. However, this approach came with excessive complexity and operational difficulties, especially creating and supervising protocol sessions for every individual action. As Parra acknowledged, the original specification failed to properly define how session details should be preserved, leading to complications. Furthermore, routing grew overly intricate when extra resources were required. The solution was simple. Under the new revision, information about the protocol version, client identity, and capabilities travels in the _meta parameter with each request, eliminating the need for protocol session tracking. MCP now operates very much like the Claude Messages API, also stateless, which provides the interface for sending and receiving messages with Anthropic's models. "I think that it's a very smart and nice way to just move… state away from the server onto the wire protocol and hope that bandwidth is for free," Parra said. MCP's routing mechanism was also totally gutted. The original messages were sent over JSON-RPC HTTP POST payloads, with the actual operation buried in the JSON body. The new revision also mirrors routing information in HTTP headers, allowing networking gear to route requests without tracking session status or inspecting the JSON-RPC body. MCP can now be extended however you desire A number of features in the original MCP have also been deprecated. One is sampling, which seemed useful at the time but turned out to be used rarely. It allowed an MCP server to ask the client's model to generate a completion, but the semantics were confusing and hard to implement, Parra said. Roots was also deprecated. It allows clients to tell servers which file system locations are relevant to a session. It was "a very niche thing," Parra said. Logging also got its notice for being excessively chatty, and developers were advised to just use stderr, stdio, or OpenTelemetry. "We are widening the surface to the things we thought were useful, but we are also realistic about narrowing [MCP] down to the good pieces that everybody is actively using," Parra said. MCP also has been enhanced with extensibility. "I think the extensions are a model for us to really test out things in the protocol before we bake them into the protocol," said Den Delimarsky, an Anthropic technical staff member who also joined the conversation. There are many use cases that are domain specific where an extension would be helpful, but the potential user base is not big enough to warrant rolling that feature out to everyone. And experimental features will be tested through extensions. Extensions can be bundled with the protocol, but have their own release schedule. One official extension is MCP Apps, which allows the MCP to present the user with an interactive app, built in JavaScript, instead of just text or an image. MCP's Tasks feature, used for managing long-running operations, has been moved out of the core protocol and into an extension. In addition to officially recognized extensions, users can build their own, following the instructions and suggestions in the specification, Parra said. Features formally marked as deprecated will remain functional for at least 12 months, according to Stacklok's "Enterprise Readiness Guide for the July 2026 MCP Spec Update." Stacklok, which offers an MCP platform, warns that this is not a blanket guarantee of interoperability with legacy implementations. Servers using the 2026-07-28 revision may not work with older clients, and vice versa. "Compatibility requires both sides to share a supported protocol era, or for one side to implement deliberate fallback or translation," the report noted. MCP’s move to statelessness was a necessary one, in the view of Stacklok CEO (and co-creator of the very stateless Kubernetes), Craig McLuckie. “The stateful nature of MCP was really a by-product of its origin as a way to support developers using coding tools (that tend to run locally) to access things. The broader AI community is now embracing MCP as a mechanism to allow enterprises to intermediate access to production systems,” McLuckie told the Register. “This gives cyber teams a unified control point to apply agent aware policy and is delivered in a form factor that platform teams are comfortable with running.” ®

GitHub has decided that, if everyone with an AI chatbot can file a bug bounty report, it may as well stop paying them like seasoned security researchers. Starting July 27, the Microsoft-owned code forge is overhauling its bug bounty program with a two-tier system that cuts rewards for public submissions while dangling much fatter payouts to a new invite-only group of researchers with proven track records. At the same time, newcomers will find themselves capped on how many reports they can submit until they've demonstrated they can produce something worth reading. The Microsoft-owned biz says that the shake-up is a response to the flood of low-effort and AI-generated reports now accompanying many bug bounty programs. Rather than paying more people to file more reports, GitHub wants to spend more on researchers who've proved they can find the real thing. Cathering Cassell, product security engineer at GitHub. “These changes are about two things: reducing the noise so we can focus on the signal, and building a program that serious researchers find rewarding to participate in.” For researchers sticking with the public program, a low-severity finding that previously earned between $500 and $1,000 will now bring in $250. Medium bugs top out at $2,000 instead of $5,000, high-severity flaws have been cut from as much as $20,000 to $5,000, and the maximum reward for a critical vulnerability falls from $30,000 to $10,000. The highest rewards are now reserved for GitHub's new invite-only VIP program. There, low-severity findings are worth $1,000, medium bugs $7,500, high-severity issues $20,000, and critical vulnerabilities at least $30,000. Entry isn't open to everyone. GitHub says invitations will be based on a proven history of valid reports, with researchers needing anything from one accepted critical vuln to seven accepted low-severity findings to qualify. GitHubb is also enabling HackerOne's "signal requirement," limiting how many reports new researchers can submit before they've established a history of legitimate findings. It says genuine newcomers will still have up to four opportunities to prove themselves, while reports already sitting in the backlog will continue to be assessed under the previous payout structure. The overhaul follows changes GitHub introduced earlier this year that tightened report-quality requirements and warned researchers against flooding the platform with AI-assisted submissions. GitHub is betting that fewer reports, from researchers with a proven track record, will do more for security than an ever-growing pile of AI-assisted submissions waiting for someone to read them. ®

If there is a driving theme to The Java Story documentary, which debuted Friday on YouTube, it would be that even some of the most important and popular technologies come from humble beginnings. In this case, we're talking about a language that started life as a failed attempt at set-top box dominance and required a massive rewrite just days before its big conference debut. Today, Java consistently hovers near the top of the TIOBE programming language popularity index and remains widely used for large enterprise applications. But at one point in 1994, Sun Microsystems was just about to abandon the effort. Tim Lindholm, who was hired to polish up a virtual machine runtime for what would become Java, told The Register, “I was one of the last people hired before the whole thing fell apart.” It wouldn’t be the last time Java outlived its detractors. Java chronicled If the idea of a professionally produced documentary about a programming language sounds familiar, then you’ve probably seen the ones on C++, Python or React. These were the work of tech job site Honeypot.io, which funded the documentaries to build a user base. In 2019, Honeypot was acquired by XING (which rebranded as New Work SE). However, founder Emma Tracey was more interested in the documentary side of things and bought the production shop back from New Work, reuniting the original gang and rebranding their efforts as Cult.Repo (short for Culture Repository). The Java Story is the first product of the newly liberated media company. The documentary features many of Java’s prime movers, including creator James Gosling and senior Oracle Java architects Mark Reinhold and Brian Goetz. While it may have taken a Hollywood-style effort to construct a Hero’s Journey around the plodding progress of Python, Java is a veritable Love Island of dramas, some of which were this documentary captured. The project that almost wasn’t Lindholm strayed into the computing field only as a result of the brutally cold winter of Minnesota, where he was living in a tent. He realized he would need someplace warmer and so scored an internship at Argonne National Laboratory in Illinois. There, he gained early experience with virtual machines thanks to the lab’s use of Prolog. His goal was not to be a programmer, but a mathematician. “Computer science was for people who couldn't be real mathematicians,” he said. But he learned the craft of implementing Prolog. “I learned to write to very high-quality virtual machines with things like garbage collection and embeddability,” he said. The VM experience led him to subsequent jobs at Xerox PARC and eventually Sun. When Lindholm arrived 1994, it was to work for an experimental “spin-in” subsidiary called FirstPerson. At the time, Sun made bank selling high-end workstations to engineers, but it wanted to build software for devices outside the typical workstation and PC market. FirstPerson’s chief concern was a bid from Time Warner to provide the interactive video-on-demand software for television set top boxes. Gosling wrote a language and runtime for the project, called Oak. The contract ultimately went to late bidder Silicon Graphics – a Sun rival commonly known as SGI. In a lesson of not always getting what you want, the Time Warner project struggled for a few years before the plug was pulled in 1997, which didn’t do the already-struggling SGI any financial favors. But at the time, Sun took the defeat hard, laying off most of the FirstPerson staff. Lindholm had been there for only a month and wasn’t overly invested in the set top box. “I'll do whatever comes next,” he recalled. Sun kept only 12 engineers to work on Oak, including Gosling and project manager Kim Polese. But for Lindholm, the future didn’t look promising. “We were like refugees in a bombed-out bunker,” he said. Those who were laid off tossed their office gear out into the hallways. Lindholm felt like “dead meat” at the Sun office, just waiting to get laid off himself. Pivot to the Web It was purely serendipitous that the project moved to the then-nascent web. One of the surviving engineers had been playing with the recently released Mosaic browser and suggested the World Wide Web should be Oak’s next target. This was a year before Windows 95 brought the internet and web browsing to the masses. The team built a Mosaic clone called WebRunner on Oak that would run animations. It would be the precursor to what would become Java applets. After that, events moved quickly, Lindholm recalled. Oak was renamed Java in early 1995, supposedly as a nod to the engineering team’s coffee consumption. “It took off like a friggin’ rocket. It was just crazy. We were all stressed,” he said. An early wave of web developers was rapidly discovering the limits of creating web pages using HTML, which, after all, is a markup language. Gosling and the crew had assembled a rough prototype, but it fell to Lindholm, alongside fellow new hire and Lisp expert Frank Yellin “to make this thing actually work.” The pair were in charge of the commercial grade implementation, ensuring that the advanced concepts Gosling had outlined, such as threading and garbage collection, functioned in the real world. Lindholm and Yellin later co-authored the original JVM specification. Threading at the time was particularly new. There were no libraries they could use to implement the idea, and Lindholm knew relatively little about the concept. The company planned to introduce Java at the 1995 SunWorld convention, the precursor to JavaOne. But the runtime was crashing badly. After much sleuthing, Lindholm figured out Java’s threading model was “fundamentally broken. It was totally screwed up,” he said. The problem was that system interrupts were being issued while the SPARC processor was executing an instruction. This proved disastrous because the system could not recover the state that had been flushed from memory and would therefore “die horribly.” Lindholm realized you could only have the interrupts happen at certain points. So, three days before the conference, he rewrote the entire threads package. At the conference, when then Sun CEO Scott McNealy showed off Java, Lindholm sat in the audience dreading the worst. Thankfully, the rewrite worked. Before open source Lindholm was also in charge of the language’s first attempt at open source, years before Eric Raymond made the term common. The company offered the binary Java runtime as a free download, but the company gave away “the sources,” as Lindholm put it, to anyone who requested it. Thousands did. The documentary retells a story that the Java Internet domain was getting so much traffic – more than Sun.com itself – that the Java team ran a pirate T3 line into the office. Such were the days before the cloud. At the time, Lindholm viewed giving away the source as a good career move. Should he ever get the ax, perhaps some other company would pick up the code and run with it. They also found outsiders could fix bugs and even extend the software to other platforms. The “source” program wasn’t formalized, however. Sun did have Richard Stallman come to talk, but he seemed “too radical” for the Sun execs, Lindholm recalled. Sun would not actually decide to officially release Java as open source for another decade. Ironically enough, Java applets were only modestly adopted for the web, as other technologies such as ColdFusion and Netscape’s JavaScript project ended up doing the heavy lifting for Web programmers. But applets were a gateway to the real action, namely powering the back-end servers. The evil empire Then, Microsoft started paying attention. It saw the runtime as a potential threat to Windows itself, particularly for the fledgling Windows NT, which was starting to make headway into the enterprise. For today’s younger generation of IT pros, it is hard to overstate how aggressive and hyper-competent Microsoft could be at that time. In 1996, the company licensed Java for Windows, but then added some additional APIs and declined to support a few others (Anyone remember Microsoft’s J++?). Sun alleged that Microsoft’s changes were intended to undermine Java’s cross-platform compatibility and steer developers toward Microsoft’s Windows-specific implementation. The years-long court case zapped the development team's energy, diverting resources away from Java. “I spent days in deposition talking about this under oath,” Lindholm recalled. The disputes ended with Microsoft paying Sun nearly $2 billion through a series of settlements. “It was personal for us,” he said. A wild ride The documentary goes on to cover the following decades of the language’s growth through to the present day, including the over-engineered era of J2EE and Java EE 5, the glimmer of hope provided by the Spring framework, Sun’s implosion and subsequent acquisition by Oracle, and the flourishing of JVM languages following the release of OpenJDK. Java continued to be a success for Sun, even as its chief business of selling SPARC-based Internet servers fizzled thanks to the influx of low-cost Linux x86 boxes. Lindholm noted that the Java team grew so large that it took over Sun’s headquarters and eventually had to move into the old Apple headquarters. But Lindholm’s passion for Java evaporated by the early 2000s, swamped by the increasingly corporate environment, and so he left for Google, where he would spend the next 20 years until his retirement earlier this year. Looking back to his early involvement, Lindholm admitted “it was kind of a random thing. You can never tell what parts of your life will end up being really significant for whatever reason." Others agreed that Java has been a wild ride. As Java creator James Gosling said in the doc, “What excites me most about the future is the unknown. Lots of things happen, and mostly the interesting ones are the ones you could never predict." ®

Another day, another programming language feels the heat from AI. A prominent Haskell-based software platform is shifting new development to Python, with its founder arguing that Haskell's tooling and ecosystem have been slow to adapt to AI-assisted development. “Haskell is in real danger,” warned Scarf founder Avi Press, in a post entitled “After 7 years in production, Scarf has reluctantly moved away from Haskell.” “AI is here to stay. The people and ecosystems that use it well are going to move much faster than the people and ecosystems that do not.” Press’ post set off a firestorm of controversy within the Haskell community, which is small but vocal, and likely felt the sting of one of its most prominent users defecting to the comparatively toy-like Python to better serve the needs of agents. “Trying to change the language to work better for some metric of ‘better’ with AI is foolish for many many reasons,” wrote one user on Reddit. “It's foolish to try to change to LLMs in a kneejerk fashion because no one knows what's on the horizon.” Putting the fun into functional programming Haskell, a functional programming language that debuted in 1990, may not appeal to fast-moving startups. It ranks No. 46 in the latest TIOBE index of programming language popularity, with a rating of less than half a percent. Favoring recursion and immutable data over conventional imperative loops and mutable state, the language's mathematical underpinnings can intimidate even experienced developers. Nevertheless, it has attracted a highly dedicated following, particularly within academia. Press has been one of Haskell’s most vocal proponents, and has even served on the language’s foundation board. “Learning it made me a much better programmer,” he admitted. Press used Haskell to build Scarf, which provides usage analytics for open source software. In a 2023 talk entitled “Why Haskell is a Terrible Choice for Startups (and why we picked it anyway),” Press admitted it was difficult to find Haskell programmers, yet the language’s rigorous type safety comes with other benefits. Refactoring is a cinch, which is valuable as business priorities change. Also, documents can be auto-generated from data types. Plus, once you get the hang of it, programming in Haskell is downright fun, Press argued. Because AI But going forward, Scarf’s new features will be added in Python instead. “At Scarf, we started doing all new API work in Python,” he wrote. “New API routes go into Python, existing Haskell code keeps running, and over time the new server becomes the main path and our Haskell footprint will shrink.” Press said Python plays better with AI, which is the direction he sees development heading. A huge part of the problem is Haskell's sluggish compilation times. “If an LLM can produce a working implementation in a few minutes, but your compile step takes dramatically longer, then your language and build system have become a bottleneck in the development loop,” he wrote. Long compilation times, once a minor annoyance, become prohibitive when running multiple coding agents at once. Caching can help, but incurs its own overhead to manage. “I want to spin up multiple worktrees, fork off different lines of work, let agents try things, review the results, and keep the useful ones. In that world, cold start time matters a lot,” Press wrote. Rigor for runtime Using Python with AI practices immediately improved the Scarf production team’s workflows, allowing them to fix bugs with minimal oversight, Press noted. In some cases, AI can fix a bug “before I get off the call with a customer,” he noted. “Resisting this kind of productivity is not an option anymore,” Press wrote. Yet, Press doesn’t feel that the Haskell ecosystem is addressing the shift to agentic-led development. Many of the language’s maintainers focus more on restricting the use of AI, or restricting its use on Haskell entirely, rather than looking for ways Haskell can better serve AI, or vice versa, he argued. Agents have different bottlenecks than human code jockeys, he noted. “They are cheap at generating code and expensive when blocked. They benefit from fast feedback, clear examples, low setup friction, and errors that help them repair the code quickly,” he wrote. Press listed ways Haskell could be made easier for agents to use: Better documentation with actual copy-and-paste industry-targeted examples (rather than “beautiful types”), more informative error messages, and – most importantly – faster build times. Optimize and chill Press’ missive set off a firestorm of discussion across Hacker News, X, Reddit and Haskell’s own message boards. Many questioned the move from Haskell to Python, given Python’s own arguably inferior typing. They also questioned whether it would have been a simpler move to optimize the Haskell compiler for faster builds than switching languages altogether. Other Haskell fans voiced more philosophical concerns. It was as if they were taking the language’s tongue-in-cheek motto, “Avoid success at all costs," seriously. Longtime UK-based Haskell programmer Chris Done questioned the motivation of making Haskell more AI-friendly, given that production use is only one way that people use Haskell. “I don’t subscribe to this growth mindset anymore,” he wrote. “I’ve come to accept Haskell on its own terms. If it dies out and becomes irrelevant like Elm or PureScript, I’ll be fine and still enjoy it.” “It leaves a bitter taste in my mouth,” wrote another contributor on the Haskell forum about Press’ post. “I don’t feel like you take our concerns about the harm of AI seriously at all.” Another accused Press of having a financial stake in AI companies (to which Press replied, “Nope”). Haskell Foundation Executive Director José Manuel Calderón Trilla urged folks to chill in an X message. Haskell is a community that prides itself on doing things “the right way,” he noted, but that shouldn’t “let that blind you into thinking that your way is the only ‘right’ way, and then attacking someone for violating your idea of what the party line is.” ®

An AI rewrite of a popular Anthropic-owned JavaScript runtime and toolchain has sparked praise for the speed of its execution, but also criticism of the coding practices behind the project itself. Last week, Bun creator Jarred Sumner announced that he ported Bun from the Zig programming language to Rust in only 11 days, using a fleet of Claude agents running in parallel. The work cost an estimated $165,000 at API pricing, suggesting that software revisions previously considered too large to undertake could actually be feasible now with AI. Sumner said the port was necessary given the growing number of bugs Bun users were finding, including one implicated in the recent Claude Code source leak. But the creator of Zig, Andrew Kelley, didn’t want his project to be seen as the culprit behind Bun’s woes, which he blames on Sumner’s bad programming practices. For Kelley, the move to Rust was not about the feature differences between the two languages, or even the use of AI, but rather “the diverging value systems of the two projects,” he wrote. Bun in the oven Bun is a JavaScript suite consisting of a runtime, package manager, bundler and test runner. Some developers like it because it is a fast one-stop shop that plays well with Node.js. To make Bun speedy, Sumner used Apple's low-memory fast-start WebKit JavaScriptCore (JSC) engine, rather than Google’s stock V8 engine. He used the up-and-coming Zig because he appreciated its performance and low-level control. Anthropic acquired Bun in December 2025. The company built its core state machine on Bun. By then, Sumner had also grown to appreciate AI’s coding abilities, and was using it heavily in the upkeep of Bun. By the time of acquisition, a Claude Bot called RoboBun had been doing a lot of the heavy lifting in the Bun repo. It supplied the most merged PRs of any contributor, fixing bugs and remediating test failures. But as Bun’s user base grew, more cracks started appearing in the code. Users found issues across the software. Anthropic’s 512,000-line code leak in March? That was Bun’s fault, thanks to a bug in the bundler that generated source maps during builds even when told not to, NodeSource reported. All these bugs weren’t Zig’s fault, Sumner explained in a blog post last week detailing the migration. Bun’s architecture mixed garbage collection and application-driven memory management. Sumner admitted that Zig wasn’t designed for that task. Rust was just better at automating memory management. The Rustification of Bun Rewriting 500,000 lines of Zig into another language would be a gargantuan undertaking if done by hand. “A rewrite in another language would take a small team of engineers a full year. It would mean freezing bugfixes, security fixes or feature development for that time,” Sumner wrote. Instead, Sumner went with Claude. He spun up about 50 dynamic Claude Code workflows, reaching a peak of about 1,300 lines of code per minute and generating over a million lines of Rust code. The job took 11 days and cost about $165,000 at API pricing. Claude Fable did most of the heavy lifting. The Rust-based Bun was then subjected to Bun's exhaustive test suite of more than one million assertions. According to Sumner, it passed 100 percent of those tests across all supported platforms without skipping or deleting any. “There’s absolutely no way an engineer with that salary would’ve been able to achieve the milestones Claude did in 11 days,” an impressed HashiCorp co-founder Mitchell Hashimoto noted on X. Zig zags But does Bun’s speed of execution betray the core tenets of good software development? One person not impressed has been Zig’s Kelley, who shared his misgivings in an impassioned post entitled “My Thoughts on the Bun Rust Rewrite." Even before the Anthropic acquisition, “we became increasingly horrified at the programming practices we saw in Bun's codebase,” Kelley wrote. Bun was one of the largest and highest profile projects using Zig and, up until the Anthropic acquisition, a regular financial contributor to The Zig Software Foundation. In Kelley’s view, the project aggressively released new features, resulting in piled-up bugs, bad error-handling code, and technical debt. Sumner “was already writing slop well before he had access to LLMs,” Kelley quipped. He speculated that Sumner may have been under pressure to meet business objectives rather than technical ones, a pressure that increased with Anthropic’s acquisition. In fact, Bun’s codebase had grown so suspect in Kelley’s estimation that Bun parting with Zig was good news. As he put it, no longer would “the publicly presumed poster child for Zig programming language actually [be] the prime example of How Not To Write Zig Code,” he wrote. The Bun team also tried to upstream some of its AI-assisted work to Zig, to no avail. Leading up to the Bun rewrite, the team maintained a fork of Zig that it said improved debug compilation speed fourfold, as eagle-eyed Reg reporter Tim Anderson revealed in May. But the Zig project would not accept Bun’s changes, citing a policy of not accepting AI-based contributions. Zig had been getting an influx of LLM-generated submissions, most of dubious quality. This lack of engineering oversight around AI-generated code would lead to countless problems down the road, Kelley reasoned. Kelley pointed out that if Bun’s tests missed these bugs in Zig, how would they be caught in unsupervised Rust code? “The argument for shipping all the million lines of unreviewed code is that the test suite is good enough to catch everything,” he wrote. “It's not sufficient to catch bugs in Zig code but it is sufficient to catch bugs in [a] million lines of unreviewed slop?” ®