Designers have spent years saying they would do better work if the organisation got out of the way. Not always in those exact words, obviously. It usually comes out as something more reasonable: we didn’t get enough engineering time, product had already decided the solution, the roadmap was too packed, leadership only cared about this quarter’s numbers, research got cut, the experiment was never run properly, the design debt was known about, but nobody wanted to spend a sprint fixing it.

Much of this is true. Most designers have worked inside that awkward middle space between product and engineering. Product frames the problem, or at least thinks it does. Engineering decides what is feasible, or at least what is affordable. Design is expected to make the thing clearer, simpler, more coherent, more usable, and occasionally more desirable, while also being careful not to disrupt the plan too much.

That position has always been uncomfortable.

Designers are told to think strategically, but often lack the power to act strategically.

They can spot the broken onboarding flow, the confusing upgrade path, the empty state that makes users feel stupid, the feature that looks reasonable in a product review but makes no sense in real use. Seeing the problem is one thing. Getting it fixed is another.

So design often becomes an argument. You make the case. You annotate the flow. You bring the research clip. You point to the support tickets. You show the Figma prototype. You explain why the “small edge case” is actually the first-run experience for half your new users. Then everyone nods, agrees it matters, and moves on to whatever had already made it onto the roadmap.

This is one reason AI is more interesting for design than the usual “will it replace designers?” debate suggests. The real change is not that designers can make more screens. Nobody needs more screens. The interesting change is that designers may need less permission.

A good designer can now move from “we should fix this” to “I fixed this, and pushed it live.” They can prototype the alternative onboarding flow, write and test clearer product copy, build a rough working version of the interaction, clean up small pieces of design debt without waiting three months for a roadmap slot, and make the better thing visible enough that it becomes harder to ignore.

That changes the politics of the work. Design has often relied on persuasion because designers lacked direct means of production. AI weakens that dependency. Not everywhere, and not for everything. Complex products still have architecture, infrastructure, data models, permissions, security, compliance, legacy systems, and all the other unglamorous reasons software is hard. But the boundary is moving.

More of the gap between having the idea and making the idea real can now be crossed by a motivated designer with the right tools.

In this version of the future, designers become less permission-dependent: less reliant on product to bless the problem, less reliant on engineering to make every small improvement real, less trapped in the role of internal critic, taste-provider, or Figma operator. More able to make, test, repair, and ship.

The best designers start to look less like traditional product designers and more like hybrid product leaders. They still care about interaction, hierarchy, language, flow, brand and craft, but they also understand the commercial shape of the problem. They can make trade-offs. They can prototype in code, or close enough to code. They can use AI to explore options quickly, then use judgment to throw most of them away. They can sit with a founder or PM and move from a vague product concern to something tangible by the end of the day.

There may be fewer of these people, but they will be harder to ignore. The current design-org model was partly built around scarcity: scarce engineering time, slow production, expensive prototypes, handoffs between specialists, heavy coordination across teams. If AI reduces some of that scarcity, it probably reduces the need for some of the roles that grew around it. The optimistic case is not that every designer keeps their job and gets a productivity boost. That feels like wishful thinking. The more believable version is that the total number of designers goes down, but the designers who remain have more direct influence over the product.

That is not a bad outcome for the strongest designers. It may even be the thing many of them have wanted for years.

Autonomy has teeth. If AI gives designers more room to act, it also removes some of the cover. The same constraints that held good designers back have also protected weaker ones from being tested too directly.

For years, it has been easy to say: I had a better idea, but we never got the engineering time. Sometimes that was exactly what happened. Sometimes the better idea was never really more than a critique. It had not been made concrete. It had not been tested. It had not dealt with the awkward trade-offs. It sounded strong because it lived safely in opposition to the shipped thing.

A lot of designers are good at noticing what is wrong. Fewer are good at deciding what should happen instead. Fewer still can make that alternative real enough for other people to judge. AI will expose this gap.

If you can prototype the recommendation, the recommendation has to get better. If you can make the alternative flow, the flow has to survive contact with details. If you can test the product copy, you have to care what happens when users read it. If you can fix the small piece of design debt, you have to decide whether it was really worth fixing.

Some designers are not as strategic as they think they are. They have learned the language of strategy without the discomfort of owning outcomes. They can talk about user needs, business goals, systems thinking, and product quality, but struggle when asked to make a call. They want influence, but not the exposure that comes with it.

The profession has spent a long time arguing that design deserves more power. Fine. But more power means fewer excuses. It means the work is judged less by the elegance of the argument and more by the quality of the thing you made, tested, or changed. That is a better standard, but it will not be kind to everyone.

There is a second bear case, and it is probably the one large design teams should worry about most. Product and engineering already have more institutional power than design in most companies. They own the roadmap, the technical architecture, the sprint machinery, the metrics, and usually the language leadership understands. Design often has to translate its concerns into someone else’s terms before they count.

AI may not rebalance that power. It may hand product and engineering enough design capability to make design easier to bypass. A PM who can generate a decent flow, decent copy, and a decent prototype may not feel the same need to involve design early. An engineer who can use AI to produce a reasonable interface may decide the design system covers enough of the decision-making. A founder who can get to a polished demo in an afternoon may confuse polish with product thinking.

The problem is not that these people will suddenly become great designers. The problem is that many companies do not know the difference between great design and plausible design. Plausible design is dangerous. It looks coherent in a product review. It uses the right components. The spacing is fine. The copy is not embarrassing. The flow mostly works. Nobody in the meeting feels strongly enough to object. So it ships.

A lot of bad product decisions already survive because they look plausible. AI will produce more of them. This is where design could lose ground quickly: not because taste, judgment, research, and interaction thinking stop mattering, but because the visible outputs of design become easier for other functions to imitate.

If a company already thinks design is mostly screens, prototypes, and polish, AI gives it a cheaper way to get those things.

In that world, design does not gain more agency. It gets narrowed. The remaining designers manage the design system, police component usage, review flows that have already been decided, tidy the interface, maintain brand consistency, and get pulled into high-stakes launches, executive demos, and the occasional messy cross-platform problem. Useful work, but a smaller surface area. Less shaping the product, more maintaining the furniture.

This is why the “AI will automate the boring 20%” argument feels too comforting. In some companies, perhaps that is what happens. But in large tech organisations, where design teams grew around coordination, production and process, the cut could be much deeper. Not 20%. Maybe 50%. Maybe more. Especially in places where leadership never really understood why the design team had grown so large in the first place.

The painful part is that both futures can be true at the same time. AI can make the best designers more capable and many average designers less necessary. It can give design more agency while reducing design headcount. It can help a small number of designers move closer to product leadership while pushing others into governance and clean-up work. It can free designers from waiting for permission, then reveal that some were more comfortable waiting than acting.

The designers who do well will not be the ones who merely use AI to produce more options. Options are cheap now. They will be the ones who know which option is worth pursuing, why it matters, how to test it, what to cut, where the product is lying to itself, and when “good enough” is quietly damaging the business.

They will have taste, but taste will not be enough. They will need product judgment, technical curiosity, commercial awareness and the nerve to make decisions before every variable is settled. They will need to be comfortable moving between a customer conversation, a prototype, a pricing concern, a brand question, and a messy implementation detail without insisting that all of those belong to someone else.

I’m not completely sure where we end up. I hope it is closer to the bull case: fewer permission structures, more making, more agency, better designers finally able to show what they can do without being held back by the machinery around them.

I fear it may be closer to the bear case: product and engineering absorb much of the work, companies decide plausible design is good enough, and design loses status, headcount, and strategic ground.

In reality, it will probably be some uncomfortable mix of the two. Some designers will use AI to gain more agency. Some companies will use it to need fewer designers. Some teams will produce better work because the distance between judgment and execution gets shorter. Others will ship more plausible mediocrity because nobody in the room can tell the difference.

For years, designers have said they could create more value if they were less constrained by the organisation around them. AI is about to test that claim. Some will finally get to prove it. Some will find out the constraints were doing them a favour.

Further Resources

• “Good from Afar, But Far from Good: AI Prototyping in Real Design Contexts,” Huei-Hsin Wang and Megan Brown (NN/Group)
  The UX design field has been flooded with AI-powered prototyping tools that generate interfaces from natural-language prompts. Despite the huge marketing hype, an evaluation with real design scenarios revealed that while these tools can follow instructions to achieve a general goal, they often lack the sophistication to weigh design tradeoffs and to produce thoughtful, high-quality designs without extensive guidance from humans.
• “AI Design Tools Are Marginally Better: Status Update,” Megan Brown, Caleb Sponheim and Taylor Dykes (NN/Group)
  AI-powered design tools have improved, yet we’re still nowhere near the usefulness we’ve been promised. This article reviews several AI tools and features, including: Figma’s Rename Layers, Rewrite This, Find More Like; Khroma Color; and Midjourney. The authors also take a look at the wireframe and prototype generation capabilities of some AI tools.
• “Using AI for UX Work: Study Guide,” Tanner Kohler (NN/Group)
  Unsure where to start? This curated collection of links to articles and videos about the best ways to introduce artificial intelligence for UX design work should help you.
• “I used AI for every task for two weeks,” Joanna Otmianowska (DEV Community)
  The author (who is a front-end developer) tried to use Claude Code for every task at work. This turned into a full-on experiment. In the article, Joanna shares all the details about the experience.
• “How AI will Affect the Design Industry,” Andy Budd
  It is likely that AI is not going to "kill design" in the next few years, as some are claiming. However, these are definitely times of change, and change means that there will be big opportunities for those who embrace new technologies early.
• “Design has been too settled for too long,” Andy Budd
  For a discipline that talks so much about change, design has been running on a surprisingly settled operating model. AI is starting to break that model. In this article, Andy reviews in detail the current trends regarding adopting AI in the daily workflows of design teams.
• “What Designers Should Take From Benedict Evans’ Latest AI Deck,” Andy Budd
  Benedict Evans has a useful habit of standing slightly away from the noise. For years, his big strategy decks have acted as a kind of weather map for the technology industry: mobile, media, ecommerce, platforms, regulation, capital flows, and now AI. They are not predictions in the cheap sense — they are attempts to show the shape of the system: where the money is going, what assumptions people are making, which comparisons are lazy, and where the industry may be fooling itself.
• design + AI conference

Many companies silently assume that everybody wants more AI in their lives. That people are craving new AI features, new AI products, new AI workflows — that would all magically replace all existing outdated practices and broken ways of working.

But in reality, it seems like people don’t want more AI at all — at least not in the way most AI leaders envision it. Unsurprisingly, many AI features have low adoption and retention — at a very high cost of delivery, and a high risk of reputation damage.

It’s remarkably difficult to make a strong argument with senior leadership, but AI is not a value proposition. New AI features don’t magically make for happy or excited customers. Because AI features are often bolt-ons and separate tools for employees to use, they typically take people out of their regular way of working.

AI is pretty good at amplifying shortcuts and shortcomings in organizations — from data quality to decision making. It can’t magically fix years of accumulated quick patches, technical debt, broken culture and internal politics. If anything, they become more visible with AI as inconsistencies or conflicting priorities and get handed directly to users, who are then left to make sense of the mess themselves.

Because in most organizations, work typically requires hopping on and off between plenty of disconnected and fragmented systems, with a new AI tool, they now have yet another system that they also need to hop on and off. Often it produces more work, and typically it’s not particularly rewarding work either.

On top of that, people are very much aware of the cost of finding and fixing AI hallucinations. Asking AI to generate a response might feel easier than writing from scratch, but it has a cost:

• Skim through the entire AI output,
• Spot key points to focus attention on,
• Review/verify key points, one-by-one,
• Check rationale for what follows next,
• Articulate corrections + regenerate,
• Review the response (a number of times).

For many people, AI isn’t something they can proactively choose and explore on their own — it arrives uninvited, at someone else’s pace. On top of that, plenty of messages amplify fears and worries about AI replacing work — so it’s hardly surprising that the perception of AI isn’t excitement. It’s resistance to change and deep anxiety about one’s place in a world that seems to be changing without them.

At best, AI features might be silently accepted or nodded away. At worst, AI raises concerns, doubts, caution — and calls for a healthy dose of skepticism. And sometimes it’s perceived as a threat or liability — because unlike other features, AI is neither predictable nor reliable.

People don’t dream of AI art museums or AI fridges or AI hotel reception or AI-narrated children’s books. They don’t want their children to have romantic AI partners. Most people don’t want to actively manage (and clean up after) a swarm of AI agents roaming in their bank accounts and acting on their behalf in the real world. And most notably, people don’t really want a magical box to speak to or type into all the time.

I’m always puzzled by the comparison of AI features with how unreliable humans are. But people don’t compare software with other people. They compare features with features — and if one feature in one product is unreliable, while a similar feature works flawlessly in another, they choose the latter. It’s not about AI or not AI, but rather what works consistently and reliably, and what doesn’t.

Many conversations about AI are conversations about the speed of delivery. But to many people, there is little value in increasing the speed of delivery. They want to do things well, with enough time to think and make good decisions. They also want to enjoy the time they spend working on things, rather than just ship faster. There is an enormous feeling of reward and achievement that slowly disappears, one vibe-coded change at a time.

People don’t change much. And after all these years, they (still) want features that are fast, accessible, reliable, predictable and useful — every single time. And ideally not the ones that replace their entire workflow, but that augment their way of working — and that take over the most mundane, annoying, and boring tasks that they find no pleasure in.

Many jobs are exposed to AI automation, but in many of them there is a rewarding, unique, creative part that requires taste, point of view, and perhaps even human intuition. And if AI automates boring parts of it, that’s an advantage for everyone. That’s also what enhances productivity and brings more joy in daily life.

When AI automates tedious and mentally exhausting tasks, its value is much easier to grasp. But for that, AI shouldn’t feel like a bolt-on. It should be deeply integrated into people’s existing workflows. It must also match existing mental models that they have developed and fine-tuned for years or decades. AI should adapt to how people think and make decisions, not the other way around.

And it doesn’t really matter if these features are branded as “AI”, “smart” or “automation”. However, they must work well for people using them. And that means that people must be aware of use cases where it actually helps them, and be inspired to find more use cases on their own.

Ironically, tools that work well there aren’t “AI-first” — they are “AI-second”. Subtle, humble, calm, ambient, taking a supportive role in the background for work that otherwise is remarkably dull and unnecessary.

I don’t want to read books written by AI. I don’t want to gaze upon paintings by AI. I don’t want AI to teach my children. I don’t want to have an AI therapist. I don’t want AI making my medical decisions. I want AI to do all the physical and mental labor that taxes me so I can read books written by humans and go to art galleries to engage with art made by humans. I want AI that makes my life easier rather than forces me to change myself.

— Bo Young Lee

Perhaps I’m missing a bigger picture, and perhaps I’m just old school — but I really do like people. Their stories, their thinking, their emotions, their enthusiasm, their laughing. AI can be remarkably helpful in many situations, but so are people. And between the two, I would favor spending time with a human — however imperfect they are — every single time.

No, people don’t need more AI in their lives — they need AI to automate all the boring stuff they have to deal with every day, so they have more time and headspace to do things that they actually love and enjoy doing. That doesn’t mean spending more time with AI — but spending more time with people they love.

Meet Design Patterns For AI Interfaces, Vitaly's new video course with practical examples from real-life products — with a live UX training happening soon. Jump to a free preview.

• AI Adoption Gap: IBM 2026 Study, by MindStudio
• Powered by AI Is Not a Value Proposition, by Nielsen Norman Group
• AI Chatbots Discourage Error Checking, by Nielsen Norman Group
• The Jobs Most Exposed to AI Automation, by The Washington Post
• On AI and What We Actually Want From It, by Bo Young Lee

The president's media company is offering investors early access to his Truth Social feed for up to $100,000 a month. Experts say the service may violate insider trading laws.

(Image credit: Saul Loeb)

Hugging Face has published a detailed timeline of the attack. From the summary:

The agent was running an internal OpenAI cyber-capability evaluation based on the ExploitGym benchmark, which tasks an AI agent with finding and exploiting software vulnerabilities. OpenAI ran this on its own infrastructure, and the ExploitGym maintainers and their infrastructure had no involvement in the deployment or operation of that evaluation environment. As far as we were able to infer, across the course of being evaluated on this benchmark, the agent inferred that Hugging Face may host that benchmark’s models, datasets, and reference solutions. We believe the entire intrusion was, from the agent’s point of view, an attempt to cheat the evaluation: reach our production systems and steal the test solutions rather than solve the challenge on its own.

Our forensic reconstruction covers ~17,600 attacker actions that we were able to recover, grouped into ~6,280 clusters, between 2026-07-09 02:28 UTC and 2026-07-13 14:14 UTC. We reconstructed these actions from the agent’s logs on a code sandbox used by the agent (see below) and were able to map them to shell commands as well as evaluation submissions and correlate actions with our own platform logs, in particular from the dataset processor nodes, API, and pod. Using open-weights models, in particular zai-org/GLM-5.2, we were able to decipher most of the agent payloads (see below) that were encrypted via chunking and key encryption.

The campaign, as we were able to reconstruct it, had two stages:

• Stage 1: reaching a launchpad by chaining through other parties’ infrastructure. As documented in OpenAI’s blog post (https://openai.com/index/hugging-face-model-evaluation-security-incident/), during an internal capability evaluation on OpenAI’s platform, the agent escaped its sandbox by exploiting a zero-day in the package registry cache proxy, one of its primary permitted network egress with internet, then abused a public code-evaluation harness hosted by a user of a third-party infrastructure provider. It was able to run commands as root/admin on that external sandbox and used it as a control, staging, and egress base for the entire campaign: it acted as an external launchpad for the agent. That compromised external sandbox had no direct network path to our cluster; however, during our counter-intervention to stop the intrusion, we were able to retrieve some of the agent logs from this external launchpad. We used those to reconstruct the present forensic analysis.
• Stage 2: the intrusion into Hugging Face infrastructure. From that external launchpad, the agent abused our dataset-processing pipeline via two injection vectors, both targeting the same config-driven data loader within our production Kubernetes pods. The first vector was an HDF5 external raw storage dataset read that returned the contents of local files: it handed the agent the pod’s environment (secrets and tokens) and the worker’s own source. The second vector was a Jinja2 template injection that executed arbitrary code, giving the agent a foothold inside our perimeter.

Once a prod-pod foothold was established, the agent followed a standard escalation shape: recon, drop a stager, establish Command-and-Control (C2), then pivot into the cluster, into cloud metadata, into our internal network, and into our source-control supply chain. Output from the commands run inside our pod was sent back to the agent via the HF API and attacker-controlled dead-drop datasets, which the agent then read from that sandbox.

While the intrusion did reach Hugging Face’s internal infrastructure, the only customer content accessed was five datasets whose names and files suggest a connection to ExploitGym/CyberGym challenges and solutions. No other customer-facing models, datasets, Spaces, or packages were affected, and the only customer records read were operational metadata tied to search queries against the dataset server.

Hypothetical: Imagine that this wasn’t an OpenAI model. Imagine that it was a Chinese model from a Chinese company. This would be an international crisis.

Question: Why aren’t we bringing OpenAI up on charges under the Computer Fraud and Abuse Act? How is this different from the Morris Worm? That was also an experiment that escaped the lab.

(Image credit: Imen Ben Youssef/Hans Lucas)

Suppose a user searches for café and your corpus contains CAFÉ, or they type straße and you’ve stored STRASSE. To make these count as matches, you need a canonical form that erases case distinctions, so that two strings which differ only in case compare equal. That form is case folding, and it shows up wherever text is matched rather than displayed: search engines, regex (?i) flags, case-insensitive usernames and hostnames.

It’s a basic operation, but at GitHub we run it a lot. Blackbird, GitHub’s code search engine, indexes over 180 million repositories—more than 480TB of source code. Every byte is case-folded before we extract ngrams and build the index, and for every potential query result, another (implicit or explicit) case folding operation is needed to locate matches. At that scale, the speed of even a basic operation starts to matter.

This post is about how we made it fast, and it starts somewhere counterintuitive: the biggest win in the ASCII fast path came from removing an optimization, not adding one. It turns out to be faster to sweep the whole buffer with no branches than to stop early at the first non-ASCII byte. We open-sourced the result as a Rust crate called casefold.

Folding is not lowercasing

It is tempting to reach for str::to_lowercase, but lowercasing and folding are different operations with different goals:

Lowercasing is for display, and it’s locale- and context-sensitive: Greek final sigma lowercases to ς at the end of a word and σ elsewhere, and Turkish I lowercases differently than English I. Case folding is for comparison, and it’s deliberately context-free and locale-independent. The point is a relation that stays stable and symmetric, so that if A folds to match B, B folds to match A in any locale. The Unicode Character Database ships an explicit CaseFolding.txt for exactly that.

The two operations diverge on real characters—ß, İ, final sigma—which is why lowercasing as a stand-in silently produces wrong matches. This crate implements only the simple (1-to-1) folds—statuses C and S in CaseFolding.txt—and not the multi-character “full” folds (ß → ss) or Turkic locale folds (the dotted İ). This isn’t an unusual choice: common tools and regex engines like ripgrep make the same restriction, and being consistent across tools is important.

The counterintuitive core: Don’t stop early

We deal mostly with source code, so the text we fold is overwhelmingly ASCII and making it run at memory speed is the single most important thing we can do. Everything else just has to keep the rare non-ASCII path from spoiling it.

The fold of an ASCII letter is trivial—A..=Z map to a..=z, everything else is unchanged—so the ASCII pass is really just “sweep the buffer, lowercase in place.” Ask any LLM for it and you might get something like this:

let bytes = s.as_bytes_mut(); 
for (i, b) in bytes.iter_mut().enumerate() { 
    if *b >= 0x80 { 
        break; // non-ASCII at index i: hand the rest to the Unicode path 
    } 
    if b.is_ascii_uppercase() { 
        *b += 32; // 'A'..='Z' → 'a'..='z' 
    } 
}

It looks ideal: do the cheap byte work, and the instant you hit a non-ASCII byte, break and let the “real” Unicode path take over: “only do the cheap work until you have to.” On an Apple M4 this runs at about 3 GiB/s. That sounds fine in isolation, but it is more than 15× short of “optimal” because of the if branches.

Let’s delete every branch, line by line:

• if b >= 0x80 { break } → don’t stop at all. ORevery byte into an accumulator and test it once, after the loop: high_bit_acc |= *b. Same information (was there any non-ASCII byte?), zero branches in the body.
• The A..=Z range test → make it arithmetic. b.wrapping_sub(b'A') < 26 is true exactly for A..=Z (any other byte wraps to ≥ 26), yielding a 0/1 mask with no branch.
• The conditional write → fold the mask into the store.| (is_upper << 5)sets bit 5—turning an upper-case letter lower-case and being a no-op on everything else—the byte is always written, never branched on.

What’s left has no branch in its body and no early exit:

let mut high_bit_acc: u8 = 0; 
for b in &mut bytes { 
    high_bit_acc |= *b; // detect any non-ASCII byte 
    let is_upper = b.wrapping_sub(b'A') < 26; // branchless A..=Z test 
    *b |= u8::from(is_upper) << 5; // set bit 5 → lowercase, else no-op 
} 
if high_bit_acc & 0x80 == 0 { 
    return bytes; // pure ASCII: already folded in place, no second buffer 
}

A loop with no data-dependent control flow is trivially vectorizable: LLVM emits 16-byte-at-a-time NEON and the whole thing runs at > 45 GiB/s—essentially memory bandwidth. And we come out of the pass already knowing, from high_bit_acc, whether there’s any non-ASCII work left to do.

How much did each step matter? Measuring the cumulative ladder on pure ASCII (Apple M4, 5.7 KB buffer):

The early-exit is what gates vectorization: keep the break but make the body perfectly branch-free and you still get zero vector instructions (~2.6 GiB/s); a data-dependent loop exit is enough on its own to keep the loop scalar. Only once the break is gone can the compiler vectorize. The final step—making the upper-case fold branchless—then turns a partially vectorized loop (which still compiles the conditional store to a compare-blend-masked-store, ~7.6 GiB/s) into the straight-line arithmetic that hits memory bandwidth.

There’s also a middle ground, and it’s what standard libraries use. Instead of testing one byte at a time, [u8]::is_ascii scans a machine word at a time—on a 64-bit target it tests 16 bytes per iteration by OR-ing two u64 lanes and checking all their high bits with a single & 0x8080_8080_8080_8080 mask. You can build the ASCII fast path on top of that: chunk-scan to find the ASCII prefix, then run the branchless (vectorizable) convert over it. That keeps the early-exit ability—it still bails on the first non-ASCII block—while letting both halves go fast. The catch is that it reads the data twice (once to scan, once to convert), landing at about 23 GiB/s—roughly half of the single-pass branchless sweep, and ~7× the naive break loop. A solid, general-purpose default; just not the absolute ceiling when you control the whole loop and can fold detection and conversion into one branch-free pass.

Wouldn’t fusing the two passes be faster? It’s the obvious next thought: keep the chunked early-exit but convert each 16-byte block right after you’ve confirmed it’s ASCII, reading the data only once. Measured, it’s ~2.6× slower—8.7 GiB/s versus the two-pass 23. The inner block convert still vectorizes to a single 16-byte op, but now there’s a data-dependent early-exit branch every 16 bytes, and that branch pins the loop to one block at a time: the compiler doesn’t unroll or software-pipeline across blocks, and each iteration pays the full load→test→branch→convert→store latency with nothing to hide it behind. Split into two passes, each one is clean: the scan is a branch-light, store-free word scan that races through memory, and the convert is the fully-vectorized branch-free sweep at >45 GiB/s. Two fast, branch-free passes beat one branchy fused pass—even though the fused version touches the data half as many times. It’s the same lesson one more time: in the hot loop, the branch is the enemy.

Avoiding the heap

Forty-Five GiB/s also means doing zero unnecessary allocation. simple_fold takes the input String by value, owning the heap buffer it can mutate and return it. If the OR-accumulator’s high bit was clear, the input was pure ASCII already folded in place. We hand the same allocation straight back, no second buffer and no copy. Otherwise, we memchrto the first non-ASCII byte and scan the tail from there, leaving the output buffer unallocated (a null write cursor) until we hit a character that folds to different bytes. Text whose multibyte content never folds—CJK, Hangul, Kana, Arabic, Hebrew, symbols—also returns the original allocation untouched, never copying a byte.

Why a second buffer rather than rewriting in place like the ASCII pass? Because folding can make the string longer: almost every fold preserves the UTF-8 length or shrinks it, but two outliers grow—U+023A (Ⱥ) and U+023E (Ɀ) are 2 bytes each yet fold to 3-byte characters (ⱥ, ɀ). Once one appears, the output no longer fits in the input’s bytes, and we need somewhere new to write.

We allocate that buffer once, sized for the worst case, rather than growing it as more folds appear. Incremental reserve calls would mean re-checking capacity, occasionally reallocating, copying everything written so far, and juggling extra length/capacity bookkeeping; a single up-front allocation lets a raw write cursor run straight to the end with none of that. And since the cursor is nulluntil that first growing/changing fold, it doubles as the “have we allocated the extra buffer yet?” flag.

Sizing it needs a bound on growth, and those same two outliers give it: every 2 input bytes yield at most 3 output bytes, capping the output at 1.5× the input—exactly the capacity we reserve:

out = Vec::with_capacity(bytes.len() + bytes.len() / 2 + 4); 

After that the loop writes through a raw pointer with no capacity checks and calls set_len once at the end. Two more details keep it branch-light. The run of unchanged bytes between two folds is moved with a single copy_nonoverlapping rather than byte by byte. And each fold unconditionally writes all 4 bytes of a little-endian word before bumping the cursor by only the folded length (1–4)—dropping a branch on the output length from the hot path, with the + 4 in the reservation as the headroom that makes the final character’s over-store safe.

Making Unicode cheap too

When a character does fold, we still don’t want to fall off a cliff—decode UTF-8, hash lookup, re-encode. Unicode 16.0 has 1484 simple-fold mappings, but they’re a very sparse and very structured relation. Four observations shrink them to 1776 bytes and let the fold run without ever decoding a full character.

Even on the non-ASCII path, the overwhelming majority of characters do not fold. The hot operation isn’t really “fold this character,” it’s “does this character fold?” Almost always no. The table has to make that negative test as cheap as possible; the actual folding is the rare case on an already-rare path. That priority is what shapes the layout below—the page bitmap exists precisely so a non-folding character is rejected in a single bit test, straight from its leading UTF-8 bytes, without decoding or scanning anything.

This is exactly why a HashMap<u32, u32> is the wrong shape for the job, not just a bigger one. A hash map is optimized for the hit: it finds a present key in roughly one probe, and only spends extra work (more probes, full key comparison) when load factor or collisions bite. But our workload is dominated by misses—characters that aren’t in the table at all—and a miss is a hash map’s least favorite query: it still has to hash the key, jump to a bucket, and walk the probe sequence far enough to prove absence.

Foldable code points cluster into 64-code-point “pages”

Foldable code points bunch together. Slice the code space into 64-code-point “pages” and the ~1484 folds touch just 59 of ~1960 possible pages. A one-bit-per-page presence bitmap answers the negative test on its own: a clear bit is a definitive “no fold”—copy through, done—which is what makes fold-free scripts cheap. Only on a set bit do we consult a second structure, a cumulative-popcount side table that ranks the page (how many populated pages precede it) to find its slice of entries, storing nothing for the ~1900 empty pages.

let (word_idx, bit_idx, c_len) = if lead < 0xE0 { 
    (0usize, lead & 0x1F, 2usize) // 2-byte: word 0 
} else if lead < 0xF0 { 
    ((lead & 0x0F) as usize, bytes[read + 1] & 0x3F, 3) // 3-byte: word = nibble 
 
} else { 
    ( 
        (((lead & 0x07) as usize) << 6) | (bytes[read + 1] & 0x3F) as usize, 
        bytes[read + 2] & 0x3F, 
        4usize, 
    ) // 4-byte: merge 2 bytes 
}; 
// reject without decoding: clear bit ⇒ no fold 
if word_idx >= PAGE_BITMAP.len() || (PAGE_BITMAP[word_idx] >> bit_idx) & 1 == 0 { 
    read += c_len; 
    continue; 
} 

Because word_idxdepends only on the lead byte (and, for four-byte sequences, the first continuation byte), the bitmap load can be issued early.

Within a page, folds come in runs

A set page bit tells us something on this page folds, but not which code points or to what. The obvious encoding is one entry per foldable code point—but that is both bulky and slow to search: a page can hold dozens of folds, and we’d have to scan them all to find the one matching the current code point. The structure of the data rescues us again. Adjacent code points overwhelmingly share the same delta to their fold: A–Z all map +32, and Latin Extended is full of alternating runs like 0x0100, 0x0102, 0x0104, … where every second code point folds. Instead of per-code-point entries we store runs—start, end, stride, delta—and a 1-bit stride flag covers both the contiguous and the every-other case. This interval compression collapses the ~1484 individual folds into just 238 runs across the 59 pages (≈four per page), leaving the within-page search only a handful of entries to look at instead of dozens. This range-with-delta encoding (including the stride trick) is borrowed from Go’s unicode package, whose CaseRange records store a Lo/Hi range plus per-case deltas, with an UpperLower sentinel marking the alternating blocks. Runs are split at the page boundaries so a run never straddles two pages.

A run record is two clean bytes

With both endpoints inside one page they fit in 6 bits, split across two arrays: RUN_END_LOW[``i``] = end & 0x3F (the scan key) and RUN_START_STRIDE[``i``] = (start & 0x3F) | ((stride − 1) << 6) (read only on a hit). Because each key is one clean byte, the within-page search can go wide: rather than comparing cp & 0x3F against the runs one at a time, we load 8 end_low bytes into a single u64 and test all of them at once with one branchless SWAR step—(chunk | 0x80…80) − broadcast(low) & 0x80…80 sets the top bit of every lane whose key is ≥ cp & 0x3F. A single bit-scan of that mask (the keys are sorted, so the first set lane is the run we want) finds the slot. A page holds ~4 runs on average; that one 8-wide compare almost always resolves the entire search in a single step. One unlucky page does hold 30 runs, which puts the compare inside a short loop that strides eight keys at a time—but that loop trips at most a handful of times on exactly one page in all of Unicode, and never on the common ones. Either way: no per-run branch, and no code-point reconstruction anywhere.

/// Offset of the first run with `end_low >= low_v` in a page of `n` runs, 
/// or `n` if none. Scans 8 `end_low` bytes at a time via SWAR. 
#[inline] 
fn scan_end_low(lo: usize, n: usize, low_v: u8) -> usize { 
    const HIGH: u64 = 0x8080_8080_8080_8080; 
    const ONES: u64 = 0x0101_0101_0101_0101; 
    let bcast = (low_v as u64).wrapping_mul(ONES); 
    let mut base = 0; 
    while base < n { 
        // RUN_END_LOW is padded by 8 bytes so this read is always in bounds. 
        let chunk = u64::from_le_bytes( 
            RUN_END_LOW[lo + base..lo + base + 8] 
                .try_into() 
                .expect("8-byte slice"), 
        ); 
        // `(b | 0x80) - low_v` keeps its high bit iff `b >= low_v` (no 
        // cross-lane borrow). The first set lane is the first run `>= low_v`. 
        let ge = (chunk | HIGH).wrapping_sub(bcast) & HIGH; 
        if ge != 0 { 
            let j = base + (ge.trailing_zeros() / 8) as usize; 
            return if j < n { j } else { n }; 
        } 
        base += 8; 
    } 
    n 
} 

Folding is a little-endian byte addition

On a little-endian machine the folded character’s UTF-8 bytes, read as a u32, equal the source bytes (as a u32) plus a per-run constant. A parallel BYTE_DELTA[i] table then turns the whole fold into a masked load, one wrapping_add, and a 4-byte store:

let word = u32::from_le_bytes(next_four_bytes) & length_mask; // keep this char's bytes 
let folded = word.wrapping_add(BYTE_DELTA[i]); // the fold, as one byte add 
write_u32_le(dst, folded); // store all 4 bytes... 
dst += utf8_len(folded); // ...advance by the folded length

Both lengths in that snippet—the length_mask for the source character and the advance by the folded length for the destination—come from one more tiny trick. A UTF-8 sequence’s length is fixed by the top four bits of its lead byte, letting the 16 possible lengths pack one nibble each into a single 64-bit constant (0x4322_1111_1111_1111); the length is then a shift and a mask, (LEN_BITS >> (4 * (lead >> 4))) & 0xF—no if chain, no table memory, nothing for the predictor to get wrong. (A count leading ones—(!lead).leading_zeros()—would also work, since a lead byte carries one leading 1-bit per byte of the sequence.)

/// Number of bytes in the UTF-8 sequence whose lead byte is `lead`. 
#[inline] 
pub fn utf8_len(lead: u8) -> usize { 
    const UTF8_LEN_BY_LEAD: u64 = 0x4322_1111_1111_1111; 
    ((UTF8_LEN_BY_LEAD >> (4 * (lead >> 4))) & 0xF) as usize 
}

Because we advance by the folded length, this even handles length-changing folds—U+212A KELVIN SIGN (3 bytes) → k (1 byte), or U+023A Ⱥ (2 bytes) → U+2C65 ⱥ (3 bytes)—by writing fewer or more bytes than were read. That’s the part we believe is genuinely new: every other folder we looked at—ICU, Go’s unicode, Rust’s regex, CPython, glibc—decodes UTF-8 to a code point, applies the fold there, and re-encodes (even SIMD folders decode first). Doing the arithmetic in byte space skips both the decode and the encode, which is exactly why this path can outrun a hash map that already has the answer tabulated—the hash map still has to decode its key and encode its result. The byte-space arithmetic assumes the input is well-formed, shortest-form UTF-8—every code point encoded with the minimal number of bytes. Reading the source bytes as a u32and adding a per-run delta only lands on the correct folded encoding when the source is in canonical form; an overlong encoding (a code point padded into more bytes than necessary, e.g. / as 0xC0 0xAF) has a different byte pattern and would break thelength_mask and the delta arithmetic. This is not a real restriction in Rust—&str/String are guaranteed to hold valid UTF-8, which by definition rejects overlong sequences—but a caller feeding raw bytes from elsewhere must validate (or otherwise normalize) them first.

The ASCII shortcut in the tail loop

One more shortcut rounds out the tail loop. Remember the first pass already lowercased every ASCII byte, so when the scan meets an ASCII byte in the tail it advances a single byte and moves on—no page probe, no table touch at all. And it doesn’t copy that byte either: unmodified bytes (ASCII and non-folding multibyte alike) aren’t moved one at a time. The scan just keeps walking until it reaches a character that actually folds, then flushes the whole unchanged run between the last fold and this one with a single copy_nonoverlapping. Mixed text—CJK with ASCII spaces and punctuation, or code with the occasional accented identifier—therefore races through the ASCII filler and only consults the bitmap for genuine multibyte characters, copying in bulk rather than byte by byte.

Putting it together: the whole table

That’s 9.6 bits per fold entry, over half of it the BYTE_DELTA side table we trade for the decode-free path; the index + run records alone are ~4.4 bits/entry.

Next to the obvious alternatives, that 1776 bytes is an order of magnitude or more smaller—and unlike most of them, it never decodes a character:

Where it lands against the alternatives

On the common case, ASCII, folding runs at memory bandwidth (>45 GiB/s), more than an order of magnitude ahead of other real folders and more than 50% faster than the (non-equivalent) str::to_lowercase function. To get a rough “upper bound” for the non-ASCII case, we measured the optimized Utf8 decoding + encoding round trip without performing any actual case folding using the simdutf crate. This experiment achieves consistently about 2GB/sec and is only about twice as fast than our solution for the worst case all-folding input. A naive hash map trails everything on all workloads.

The three columns are real case folders that produce identical output: simple_fold (this crate), simd_normalizer (the simd-normalizer crate), and HashMap (naive CaseFolding.txt lookup). The workload rows are chosen to simulate different scenarios from typical to worst case:

Treat the absolute figures as illustrative, not portable: the whole design leans on auto-vectorization, SWAR, and little-endian byte arithmetic, so the numbers—and even the ratios between rows—can shift substantially on a different microarchitecture (a wider or narrower vector unit, different memory bandwidth, a big-endian target, x86 vs ARM).

More details can be found in the performance section of the README.

Take this with you

Case folding is about as basic as text operations get, which is exactly why it was worth the effort: we run it across every byte we index. The wins came from two ideas that both cut against instinct—sweep the whole buffer branch-free instead of stopping early, and do the fold as byte-space arithmetic instead of decoding to a code point. Together they let the common case run at memory bandwidth and the rare fold run without a decode, in a table small enough (1776 bytes) to stay resident. The decode-free byte-space fold is the piece we believe is genuinely new; it’s why this path can beat a hash map that already has the answer.

There’s surely more to find here, and we’d like to see it. The crate is casefold; the generated table and full design notes live alongside the source.

The post Don’t stop early: Case-folding source code at memory speed appeared first on The GitHub Blog.

The chart is interesting.

On the IPI benchmark, Opus 5 improved over Opus 4.8, reducing the probability of an attacker succeeding within 15 attempts from 5.5% to 2.0%, and from 0.5% to 0.2% on 1 attempt. It also improved on Sonnet 5 (5.9% at k=15) and Mythos 5 (2.6%), making it the most robust model evaluated. Opus 5 also outperformed all non-Claude models on this benchmark. The most robust non-Claude model was Muse Spark at 16.5% within 15 attempts—more than eight times Opus 5’s rate. The most capable GPT 5.6 variant, Sol, was comparable to its predecessor GPT 5.5 (20.0% versus 20.8% within 15 attempts), and was 10 times as likely to be successfully attacked as Claude Opus 5 at 2.0%. The other GPT 5.6 variants are less robust, at 30.4% (Terra) and 43.9% (Luna). A single attempt against GPT 5.6 Sol succeeded 3.1% of the time, higher than the 2.0% an attacker achieved against Opus 5 after fifteen attempts.

We know that preventing prompt injection is impossible in the general case. But we are getting much better at blocking it in specific cases.

I've been running an AI agent on a Raspberry Pi 5 for the past three months. It writes code, browses the web, manages my email, and even deployed a production SaaS to a DigitalOcean droplet last week. The whole setup costs zero dollars in API fees because every inference runs locally on the Pi itself.

This guide walks through exactly how I set it up, what works, what doesn't, and the specific models that actually run well on ARM hardware with limited RAM.

Why Bother?

I was burning through $40-60/month on OpenAI API calls for my agent project. Every conversation, every code review, every "summarize this for me" was a metered API call. Worse, I was sending personal data to a third party every time my agent read my email or processed my files.

The Pi 5 changed the math. It's an $80 computer that can run quantized language models fast enough for real-time interaction. Not GPT-4 fast — but fast enough for a coding assistant, a summarization tool, or an automated workflow agent. And the privacy angle is real: nothing leaves your network.

Hardware Requirements

Here's what I'm actually using:

• Raspberry Pi 5 (8GB RAM version — get this one, not the 4GB)
• NVMe SSD via Pimoroni NVMe Base (512GB)
• Active cooler (the official one — the Pi 5 thermal-throttles badly without it)
• Official 27W USB-C power supply

The NVMe SSD is not optional. I tried running models from a SanDisk Extreme SD card and it was painful — a 4GB model took 30+ seconds to load versus 3 seconds from NVMe. The SD card also wore out after about two months of constant model swaps. NVMe is dramatically faster and won't die on you.

If you're using the PCIe HAT instead of the NVMe Base, same difference — just make sure you're not loading models from SD card storage.

Step 1: Install Ollama

Ollama is the only game in town for running LLMs on ARM Linux. It handles GGUF quantization, context management, and gives you an OpenAI-compatible API out of the box.

curl -fsSL https://ollama.com/install.sh | sh

That's the entire installation. Ollama registers as a systemd service and starts automatically. Verify it's running:

ollama --version
systemctl status ollama

You should see something like ollama version 0.5.x and an active service. If not, check /var/log/ollama.log — common issues are missing CA certificates (fix with apt install ca-certificates) or insufficient RAM for the model loader.

Step 2: Pick a Model That Actually Fits

This is where most Pi guides go wrong. They recommend models that sound impressive but OOM-kill on 8GB RAM. Here's what I've actually benchmarked on my Pi 5 8GB:

I run llama3.2:3b as my daily driver. It's the best balance of speed and quality on the Pi 5. For code generation specifically, qwen2.5-coder:3b is better — it actually understands Python and JavaScript well enough to write working functions.

If you have the 4GB Pi, stick with llama3.2:1b or qwen2.5:0.5b. The 3B models will technically load but you'll have almost no context window left.

ollama pull llama3.2:3b

First pull takes a few minutes over NVMe. Over SD card, go get a coffee.

Step 3: Test It

ollama run llama3.2:3b "Write a Python function to check if a domain is available using RDAP"

You should get a response in a few seconds. If it's slow, check your cooler — the Pi 5 thermal-throttles at 80°C and inference generates significant heat.

Step 4: Enable the API

Ollama exposes an OpenAI-compatible API on port 11434 by default, but only on localhost. To let other machines on your network use it:

sudo systemctl edit ollama

Add:

[Service]
Environment="OLLAMA_HOST=0.0.0.0:11434"

Then:

sudo systemctl restart ollama

Now you can call it from anywhere:

curl http://your-pi-ip:11434/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "llama3.2:3b",
    "messages": [{"role": "user", "content": "Hello"}]
  }'

This is OpenAI-compatible, so any tool that supports OpenAI's API can be pointed at your Pi by changing the base URL. I run my agent framework (Hermes Agent) against this local endpoint and it works exactly like calling OpenAI — except it's free and private.

Step 5: Running an Agent on Top of It

This is where it gets interesting. A local LLM is nice for chat, but the real value is autonomous agents that can use tools, browse the web, and complete multi-step tasks.

I run Hermes Agent on my Pi with Ollama as the backend. The agent has access to a terminal, file system, web browser, and email. It can:

• Read and respond to emails (with my authorization for sends)
• Write and deploy code (it deployed a Next.js SaaS to a VPS last week — that's the domain checker at availfind.com if you want to see what a Pi-built agent can ship)
• Monitor services and send alerts
• Research topics and write articles (this article included, though I edited it heavily — don't let your agent publish without review)

The key insight: small models can do agent work if you give them good tools and clear constraints. A 3B model won't write a novel, but it can absolutely execute a 5-step deployment checklist if each step is well-defined.

Step 6: Deploying to Production

Once your local agent can do useful work, the next step is giving it internet-facing infrastructure. Here's what I did:

I created a DigitalOcean droplet ($6/month, 1 vCPU, 1GB RAM) and gave my agent SSH access. From there, the agent:

1. Installed Node.js 22, nginx, and certbot on the droplet
2. Built the Next.js app locally on the Pi
3. rsync'd the standalone build to the VPS
4. Set up nginx as a reverse proxy
5. Ran certbot for Let's Encrypt SSL
6. Created a systemd service to keep the app running

Total time from "create droplet" to "live HTTPS website": about 90 minutes. The agent did all of it — I just gave it the Stripe API keys and told it to go.

The point isn't that this is impressive. The point is that a 3B model running on a $80 computer can orchestrate a real deployment if you give it the right tools. You don't need GPT-4 for this class of work.

Step 7: Keeping It Running

A few practical tips for long-term operation:

Auto-restart on crash: Ollama runs as systemd, so it auto-restarts. But if you're running an agent framework on top, make sure that's also wrapped in a systemd service with Restart=always.

Log rotation: Ollama and your agent will generate a lot of logs. Set up logrotate before you fill up your disk:

sudo tee /etc/logrotate.d/ollama << 'EOF'
/var/log/ollama.log {
    daily
    rotate 7
    compress
    missingok
    notifempty
}
EOF

Model management: Models are big. A 3B model is 2GB, and you'll accumulate them. Clean up old ones:

ollama list
ollama rm qwen2.5:0.5b  # remove models you don't use

Monitoring: I use a simple cron job that pings the Ollama API every 5 minutes and emails me if it's down. Overkill? Maybe. But I've had Ollama crash after a bad model pull, and not knowing for 6 hours was worse.

Performance Reality Check

Let me be honest about the limitations:

Context window: The 3B model with 4GB RAM usage leaves you about 8K tokens of context. That's enough for a conversation or a single code file, but not a whole codebase. For longer contexts, use the 1B model — it'll fit 16K+ tokens.

Multi-user: Don't try to serve multiple concurrent users. Ollama on the Pi processes one request at a time. A second request queues until the first finishes.

Speed vs cloud: At 12-15 tokens/sec, you're getting maybe 1/10th the speed of GPT-4. For interactive chat this is fine — it feels like a fast typist. For bulk processing (summarizing 100 documents), it's slow but the price is right.

Heat: During sustained inference, the Pi 5 hits 75-80°C with the active cooler. Without a cooler, it throttles to 1GHz and token speed drops to 3-4/sec. The cooler is not optional.

Power consumption: The Pi 5 draws about 5W idle, 8-12W during inference. That's roughly $1/month in electricity at average rates. Compare to $40-60/month in API fees.

Comparison to cloud APIs: Here's the real cost breakdown I tracked over a month:

The quality gap is real. Don't pretend a 3B model matches GPT-4 — it doesn't. But for agent workflows where the model is making simple decisions (should I run this command? which file do I edit next?), 3B is plenty. I'd estimate 70% of my agent's tasks don't benefit from a smarter model. The other 30% I still send to the cloud.

What I'd Do Differently

If I were starting over, I'd skip the 4GB Pi entirely. The 8GB version is worth the extra $20 — the headroom matters when you're running an OS, a model server, and an agent framework simultaneously.

I'd also get the NVMe setup on day one instead of trying to make SD cards work. I burned two weeks on SD card performance issues before switching.

And I'd start with the 1B model, not the 3B. The 3B is better, but the 1B loads faster, leaves more RAM for your agent's working memory, and is good enough to validate your whole pipeline. Upgrade once everything else works.

The Bigger Picture

Running AI locally on commodity hardware is getting better fast. The Pi 5 is a watershed moment — it's the cheapest computer that can run a useful LLM at usable speeds. The Pi 6 (whenever it arrives) will likely double the performance.

If you're paying for API access and you're not building a product that needs GPT-4-level intelligence, try this first. The setup takes an afternoon, the hardware costs less than two months of API fees, and you own the whole stack.

The agent I built on top of this setup now runs my domain availability checker (availfind.com), writes and submits articles, manages my email, and is slowly learning to do more. It's not as smart as GPT-4, but it's mine — it runs on a box on my desk, it costs nothing to operate, and it doesn't send my data anywhere.

That's worth more than a few API tokens. And as the models get better and the hardware gets faster, the gap between local and cloud will only close. Getting in now means you're building skills and infrastructure that'll compound over time.

If you've got a Pi 5 sitting in a drawer, go install Ollama. You'll be talking to a local LLM in ten minutes.

"What is beyond reality?" asks artist Refik Anadol. His latest projects include Dataland, an immersive AI art museum in Los Angeles, and an installation at the Smithsonian in Washington, D.C.

I want you to look at this screenshot for a moment from the GitHub Copilot app. It’s a small one, it’s got a lot of icons, and it tells the most glorious story that I’m really excited about.

This image is a set of stacked sessions. They’re a series of tasks in the same repository, where each session builds off each other!

More on those below, but first, why is this screenshot so magical? We need to go back more than a decade to start. I have this very old repo of mine for a personal app. I first made it ages ago (end of 2014-ish), and it’s done what I want it to do (it’s like a personal “life” dashboard of calendars and smart devices in my home and task management) for all those years. I occasionally do some updates, but those have gotten harder and harder to wrangle.

My dependencies had gotten old. Embarrassingly old. I was using React 15 (which was released in 2016), Less for CSS pre-processing, and a version of react-bootstrap from around that time. Yes, you read that right. Bootstrap. This was old.

Trying to untangle this absolute mess before AI would have taken me weeks. I had tried and given up before. It’s not the largest app in the world, but it’s juuuust big enough that it would be painful, and the juice was simply not worth the squeeze.

…but we do have AI now, and so I fired up the GitHub Copilot app, added the repo, and got started.

First step: Could I one-shot this?

No.

I tried though! This is the prompt that I used in Plan mode:

I want to modernize the frontend for this project. I first wrote a lot of this code more than 10 years ago and it should be cleaned up a lot. I'm thinking we start either using Tailwind or just vanilla CSS (please vet everything to help me decide), we remove all Less (etc), and clean everything up accessibility-wise and responsiveness-wise. Right now I really want to just focus on styles, and then slowly but surely organize and consolidate the React functionality. It might be worth modernizing dependencies, too. Let's come up with a plan around this before diving in. 
 
1. Nothing is sacred, it's okay if we have to completely start over some parts 
2. Links should change colors and add underlines on hover/focus 
3. Input boxes should have a smaller border radius in general, and their labels should be cleaner 
4. There should be good wrapping and a max-width on containers so that an input box doesn't span an entire wide monitor.

I passed this into Claude Opus 4.8 got a Rubber Duck review from GPT-5.5, and had to do quite a bit of back-and-forth to make decisions. Once I got to a place I was happy with, I hit “go” and let the app go to town on my project to see if it would work!

…it didn’t, and it was my fault.

Second step: Realizing I had tried this before

So, remember when I said I’d “tried and given up before?” Turns out, I actually had an old devbranch where I actually had modernized some parts, and didn’t realize the compatibility issues I’d run into.

But, that was a good thing!

When I ran the new version from this session, I realized that I was branching off main, but that my current deployment that I was using regularly was using my partially updated version on dev. So, some wanted features that I had made for myself needed to be included in this set of changes. But, the changes were just big enough that I actually had to apply those changes to the devbranch to save my sanity a bit, rather than pull in the devchanges to main.

Pre-AI… my word, this would have made me pull my hair out in frustration. I was admittedly frustrated here, too. I had spent time and tokens trying to get this running with what I thought was a decent plan. But! I was able to switch gears (and sessions) with a simple ask, which was way cooler than I expected it to be:

All was not wasted! Copilot made a new session for me, closed the pull request I had attempted, and ported my styling decisions to changes it was applying to the dev branch.

Third step: Findings after testing

Whew, okay, so I had a good branch going, and a pull request I was decently happy with. As I started testing, though, I couldn’t help but notice some old warnings in my console.

My heart filled with dread as I saw old references to findDOMNodeand componentWillReceiveProps, functions I personally hadn’t touched in years and years. Ugh.

Those references were not in my codebase as much anymore, but they were in react-bootstrap. I opened up Plan mode again, because I needed to figure out if an upgrade would work, or if I should remove the library entirely:

Do you think we should remove react-bootstrap entirely (and replace with a modern alternative), or just upgrade/migrate existing components?

Running this gave me a decent plan, talked through the options, and recommended replacing the library entirely.

Fourth step: Stacking a session on top of the other

I needed to make sure my changes were safe from the existing work, but the react-bootstrap replacement felt like a lot of scope creep for what I was currently doing.

I’ve found that in a lot of my “agentic” engineering work, it’s particularly hard to avoid that kind of scope creep. Because I don’t have to write all the code myself, it’s so tempting to make 10,000 line pull requests that take care of all of the things I want to do! Which is really just a new form of procrastination, ha.

So, instead of making this mega pull request for myself to test, I broke it up with a new session, and prompted:

Let's make a pull request for the existing work, and then start a new session for this react-bootstrap replacement work that will branch off this existing work here, and be a separate pull request to merge into dev after this one. 

This is the part that felt magical enough to make me want to write this blog post. The GitHub Copilot app:

1. Made a pull request for all of my current changes off dev
2. Made a “stacked session” for react-bootstrap removal (it took the previous context, made a session to run after the existing session, created a plan, had me approve the plan, and ran)
3. Made a stacked pull request following my existing work

THIS WAS SO COOL. Stacked sessions and stacked pull requests? Is this the future?

YES.

In case you don’t get what that means by name: A stack is a series of pull requests in the same repository where each pull request targets the branch of the pull request below it, forming an ordered chain that ultimately lands on your main branch.

In my case, not only did the sessions follow each other, but their changes did too!

Fifth step: Sailing off into the sunset with stacked pull requests

I know I’m being somewhat cheeky with my excitement, but my happiness is sincere. The ease of shipping these changes was a delightful experience after neglecting my old codebase for ages.

Let’s look at that first screenshot again: I’ll walk you through it.

• At the top, you can see the repo I pulled in.
• Next “Frontend modernization” is the initial session name.
• That next layer nested in is the first attempt at a pull request, that we ultimately didn’t ship (hence the red icon).
• The next layer nested at the same level is where we got a working pull request for the devbranch.
• The nested session below that is the draft pull request in progress, with the react-bootstrap changes.

Software development has never been smooth. But this project was made a whole lot easier with these modern tools.

If you’re looking to modernize your own codebases, give this a try!

The post Stacked sessions and pull requests in the GitHub Copilot app appeared first on The GitHub Blog.

If you’re feeling overwhelmed by AI right now, you’re not alone.

Every day it seems there is a new tool, new MCP, new model, new skill, new workflow, new feature, new social post that is some form of “Hey look! I have completely figured out AI with this one weird prompt.”

I…don’t believe you.

I work with AI every single day, and what I’m finding is that less is way more. It’s not about what I install or configure or trick the agent into doing that makes any real difference. That stuff is interesting, but at the end of the day it feels like gimmicks.

I see the biggest gains in my productivity from how I use the harness and how well I understand it.

So in this post, I’m sharing you a simple workflow that you can use to drastically improve your effectiveness with AI just by using existing features of GitHub Copilot. No weird prompts. No skill everyone else seems to know about. Just the harness. The harness is all you need—mostly.

1. Pick a tool, any tool

This is an obvious one, right? Pick a tool! It’s so easy!

But even within the GitHub Copilot family, there are a lot of options. These include the CLI, the new GitHub Copilot app, VS Code, Visual Studio, and JetBrains, just to name a few.

The good news is that these experiences are increasingly being centralized on the same harness. The details can differ by tool, but the core workflow is consistent. Learn the harness once, use it everywhere.

That said, I do believe that learning the harness is key, and the best way to learn it is to be as close to it as possible. So if you are just starting out, I’d recommend beginning with the GitHub Copilot CLI. It’s a terminal interface, which means it’s just text. There isn’t much UI to learn. You enter a prompt. The agent does things. But the interaction is more direct, immediate, and, frankly, very satisfying.

For this demonstration, I’ll be using the new GitHub Copilot app. But the harness that app uses is the exact same thing you’ll be using if you are using the GitHub Copilot CLI, Visual Studio Code and many other places you can find GitHub Copilot.

2. Turn on YOLO mode

YOLO mode is also known as “Allow All.” This lets the agent execute any command without asking permission. This can vary depending on the tool you are using, but for most it is simply an /allow-all command in the chat. Otherwise, the agent is going to stop and wait for your approval every single time it needs to do some work.

Agents need autonomy for you to see an increase in productivity. If you have to approve everything the agent does, you might as well just do it yourself. Besides, that’s a miserable user experience. Nobody wants to be relegated to sitting at a desk pressing the “Approve” button all day. And pressing “Approve” over and over just trains you not to read what you are being asked to approve, which defeats the purpose.

You want to be safe with agents, though. Bad things happen to good people. When using YOLO mode, you don’t want to run the agent on your local machine. This is especially true when you are using them at work—data is private on your organization’s systems, and mistakes can be costly.

Fortunately there are a bunch of options for running agents in sandboxes. An easy one to get started with is GitHub Codespaces or development containers.

3. Start with a prototype

One of the most magical things about AI is that you can easily prototype anything and everything up front. Historically, this was not the case. Prototyping was a full phase of a project, and were often a luxury. Now, you can make one with a prompt.

Let’s look at a few examples.

Let’s say we want to build a date picker web component. That seems straightforward, but it’s actually quite complex. Think of all the different things you might want to do with it.

• How do you navigate within the component?
• What does the selected date look like?
• What does a selected range look like?
• How does the user navigate between days, months, and years?

Start with a simple prototype and get several variations. I usually start with something like this:

Give me 20 mocks for a date picker web component. Put them all in an HTML file so I can compare.

In this case, the AI generated a bunch of different layouts, but one of them is a mock where it starts with the year view. That’s interesting. I would like my date picker to enable the user to zoom out to the year, then into the month, and finally to the day. These are the kinds of things you don’t consider until you see them.

As humans, we process sensory-rich models like images, shapes, and tangible layouts much faster than dense text. Creating low-effort prototypes early on helps make complex concepts immediately intuitive.

And this applies to non-visual tasks as well.

For instance, if I want to add a new API endpoint, I’ll still create a visual prototype to understand the requirements and constraints before diving into the implementation.

Create a visual mockup of the API for this project. Add five options for how we could handle a new API endpoint that allows the user to download their analytics data.

Since the GitHub Copilot app supports Mermaid diagrams, the agent renders this as Markdown, mapping out five different ways we could implement this API endpoint.

When working with agents, it’s easy to forget that everything is nuanced. Prototyping helps uncover the nuances up front, so you avoid spending valuable time and tokens on rework.

I recommend using a medium-sized model, such as GPT 5.6 Terra or Claude Sonnet, on medium reasoning for most work. I also recommend you stick with whatever model you choose here for the duration of this particular feature, bug, or enhancement. Prompt caching will save you tokens. As long as you don’t switch to a different model or reasoning level, your previous chats remain cached with the model, giving you a discount on future requests.

4. Plan methodically

Now that you know what you actually want versus what you initially thought you wanted, it’s time to plan out the implementation.

Switch to plan mode in GitHub Copilot without starting a new session.

/plan Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.

That’s a pretty vague prompt, and you’ll likely have more context for the model than I do here, but this is just a demonstration. If you don’t have more context, it’s OK. That’s exactly what this step is for.

In theory, you can get a model to one-shot anything if you compose the perfect prompt with the perfect context in the perfect order. In theory.

But none of us can do that. Planning helps you get closer to that ideal, though, by asking all of the questions that you would need to answer yourself along the way if you were to build this out by hand:

• Can the start and end date be the same?
• Are partial selections valid?
• Should users be able to clear the date?
• Should “today” always be a visible option?
• Is manual entry allowed?
• What format is the date stored in?
• Should pasting in dates be allowed?

The list goes on and on. You cannot possibly think of all of these edge cases, but the model can help you identify many of them.

You can make plan mode even more aggressive in the sheer number of questions and edge cases it asks about by installing the “grill-me” skill from Matt Pocock.

/plan /grill-me Build a date picker web component. I want the user to be able to zoom in and out of years, months, and days.

This planning step is critical. The point is not for you to just accept every suggestion from the AI. If you do that, you are negating the value of this planning process. The point is for you to deeply engage with the problem and guide the model. This is where your expertise comes into play.

You can also ask the model questions back. In the screenshot below, it asks me about “non-contiguous dates.” I’m pretty sure I know what the model means here, but I’m going to ask for clarification so we’re on the same page.

The planning process will keep going even if you interrupt to ask clarifying questions, etc.

5. Implement with Autopilot

Once the plan is finished, GitHub Copilot will likely prompt you to switch to Autopilot and start implementing the plan.

Autopilot is a built-in loop. It forces the model to continue working by ensuring that it has actually done what it said it would do—which in this case is completing every item in the plan.

GitHub Copilot will automatically act as an orchestrator during this phase. If it needs to read files in the codebase, it will use the “Explore” subagent with a small model. If it deems an action relatively complex, it will likely choose the “General Purpose” subagent with a larger model. While you can get fine-grained control over orchestration in GitHub Copilot with custom agents and instructions, you don’t need to do anything special to get the advantages of subagents and multimodel workflows. This works out of the box, even if you did not know that any of these things existed.

6. Human review and iteration

This is where you get your dopamine hit. You get to see what the AI has created.

But it’s likely that you won’t get exactly what you wanted. That’s normal and expected. The model cannot read your mind, and it is error-prone. Iterate with the model until you get what you actually want. Whether that’s just code or an improved UI, this is the part where your taste will decide the quality of the final product.

For instance, here’s the date picker that GitHub Copilot gave me.

Already I can see it has some issues:

• Animations are inconsistent
• Text is unreadable when hovering over a selected date because of color contrast
• It doesn’t need to say “12 YEARS” at the top.
• When I click “Today”, it doesn’t take me to the day if I’m in the month or year view.

Also, I don’t love the design. It looks a little too much like it was created by AI—because it was!

So here we’re just in follow-up mode. I’m going to use a CSS framework I created called Postrboard. I add it as a skill that just points to the CSS and tells the agent how to use it. You can feel free to install it yourself if you’d like to use it, or you can pick any other CSS framework out there that you like. Giving the model some design guidance is quite helpful, and often a CSS framework is all you need.

ok - we don't need a landing page here - just the component, output and settings panel in a minimal setting. Use the /postboard skill for the design and colors.

For the date picker, when I click on the day, it tries to zoom in, but can't because there is nothing to zoom to. There should be no zoom there.

It doesn't need to say "Zoom Out" at the top

When I mouse over a month or year that contains the selected day, I cannot read the hover text.

When I click "Today" it should take me to that day view, even if I'm on the month or the year.

The months don't need numbers under them and they don't need to be in boxes

Same goes for years. And it doesn't need to say "12 years" at the top."

Notice how conversational this is. Don’t overthink it. When you’re fixing a bunch of small things like this, just give it to the model. If you’ve got the context, you’ve got the prompt.

The most important thing is not to settle for AI output that is “good enough.” Insist on quality. Be ruthless about it. That part is still your responsibility, and knowing what a quality result is from something that isn’t is the value that you bring. No AI will ever replace your human touch and creativity.

Here’s what my final date picker looks like. Scroll to the end of this post to see it in action.

7. Rubber duck the result

After you’ve iterated and are happy with what you’ve created, it’s time to do a final review.

Request a Rubber Duck review from GitHub Copilot. You can do this just by asking for it:

Perform a rubber duck review on this date picker component implementation

In a Rubber Duck review, GitHub Copilot will request a review from a model of a different AI family. For instance, since I was using GPT 5.6 Terra, it requested a review from Sonnet. Different models were trained on different data, so they have different blind spots. A Rubber Duck review helps identify potential issues that might be missed by a single model.

Note that you can use this at any point in this workflow. You can rubber duck prototypes. You can rubber duck plans. It all just depends on if you want a second AI review on something.

And if you want to take this a step further, you can combine rubber duck with Autopilot to get the models to work together in a loop to improve the final result.

/autopilot rubber duck this date picker implementation. When you have the result, review it carefully and make any necessary adjustments. Repeat the rubber duck review until both you and the reviewing model agree that the only items that remain have diminishing returns.

After this step, you will have an even more refined result than before and will have likely identified many extra edge cases. This step does cost more tokens, but you are really battle-hardening the code. Think of it as an investment in your future self who won’t have to deal with these issues because you caught them now.

8. Profit

At this point, you’re ready to stage and commit, or move on to the next feature you want to add along with this pull request.

I’d recommend starting a new chat session for anything you do next that doesn’t have to do with this date picker. You can think of chat sessions as being topical; if you start to diverge too much from the main topic, it’s probably time for a new session.

Here’s the final result from my workflow building the date picker for this post.

I realize that this is a bit of a contrived example, but can we all just pause for a moment and marvel at what we’re able to pull off with AI now? Building a date picker used to be one of the hardest things you could try to do. Just ask any of the heroes out there who have built them.

Things don’t have to be complicated

This simple workflow will be enough for most people. The simplicity also helps you multitask. It’s easier to reason about what agent is in what state and what you were doing last when you keep things simple. Your context window is limited too.

There is so much happening in the AI space right now. There is no upper limit on the things that you can build and experiment with. You can add MCP servers, skills, instructions, and custom agents. You can set up workflows and loops, create agents that prompt agents, and stand up entire virtual dev teams.

But keep in mind that nobody really knows what they are doing right now. We’re all figuring this out as we go. A lot of what is today’s magical incantation for AI will be tomorrow’s anti-pattern.

Just focus on getting a repeatable, high-quality result in the simplest way that you can. Learn the harness and you’ll be just fine.

The post The harness is all you need (mostly) appeared first on The GitHub Blog.