60 posts tagged with “coding”

Product designer and UX Planet editor-in-chief Nick Babich describes software development shifting from production to direction. The design version is familiar by now: as interface production gets cheaper, the work beyond the artifact is defining the right problem, directing agents, evaluating output, and owning the result. Babich traces the same shift in software:

Software development as manual code production is dying.

Software development as translating detailed tickets into predictable implementation is dying.

Software development as a protected technical craft that non-programmers cannot access is dying.

But software engineering is evolving into something broader:

Problem definition + architecture + agent orchestration + verification + product judgment + accountability

This changes the role of the developer.

The most valuable skill is no longer the ability to write code.

It is the ability to define the right problem, provide agents with the right context, evaluate their decisions, and verify that the final result actually works.

Software developers are becoming software creators.

I agree. Replace code with interface production and developer with designer, and Babich could be describing our profession. But there’s a problem both fields share: judgment is built by doing the low-stakes work AI now handles.

Junior developers were historically hired to complete simple implementation tasks such as:

• Build a basic interface;
• Write repetitive tests;
• Fix small bugs;

and these tasks allow them to learn from experienced colleagues and grow professionally.

But in 2026, these tasks are precisely the tasks coding agents handle best.

The loop engineering theme explained how to replace turn-by-turn prompting with a system that discovers work, assigns it, checks the result, and remembers what comes next. AI engineering writer and former Google engineering leader Addy Osmani scales that idea into a software factory and adds the governing constraint: the work can move only as fast as humans can review it.

A software factory is many harnessed loops running at once, fed by a queue of work and drained through a review gate into production, with humans owning the whole thing from above. It is not a bigger agent; it is an org chart made of loops.

Osmani follows that definition through the factory’s wiring diagram:

By and large, every box in this diagram is almost zero cost: generation, tests, scanning. They all run at scale for negligible cost. There is only one expensive box that proves stubbornly resistant to scaling, and that’s the review gate. That shiny amber box is “judgment”, and where the crux of the argument about whether we can make development faster and more frequent resides.

For Osmani, the review gate sets the pace. More generation only helps when verification scales with it; otherwise the factory manufactures a queue of code no one has the attention to understand. Imagine a conveyor belt of products being assembled together, only to pile up at the end, waiting for a poor human quality checker.

Osmani turns that constraint into architecture:

You might be thinking that all sounds unglamorous. You’re right. The safety net is made up of perfectly ordinary architectural practices we’ve always known about and mostly ignored: good types and method signatures so that mistakes are caught by the compiler instead of in production; test seams where we can pin behavior and make change observable; laying out the code so the next reader, human or model, knows where to find the thing they care about; keeping call stacks short and legible; keeping component boundaries well defined so a change doesn’t have a huge blast radius; and dependency injection so we can swap out one piece for another. None of it is new. We’ve always said we care about good architecture. But now that we’re using automated coding agents, that architecture is finally doing a second job as a cheap and hard-to-fake safety net against the mistakes the agent will make.

Put plainly, structure the work so mistakes are easy to spot and changing one thing doesn’t break everything else.

For designers, that means clear rules for each component, documented states, testable prototypes, and explicit review criteria. Build loops that can keep moving without you, but let them move only as far as those checks can prove the work is sound.

Laura Summers, writing for the Pydantic blog, describes the strange math of coding agents: the work can run in parallel, but our attention can’t.

Marcelo, another Pydantic colleague, when asked about his Claude Code session freezing said: “just open 5 claude sessions. You’ll never notice because you’re busy giving feedback to the others.” He was joking. I think. But it captures something true about the current moment. The parallelism is exhilarating and kind of feral. The number of things you can start has dramatically increased. The number of things you can thoughtfully finish hasn’t changed at all, because that part still requires the one resource we can’t parallelise: your brain.

The design version is easy to recognize: an agent can generate dozens of screens and states while one brain still has to judge the product intent and every edge case. You may spend less time drawing the interface, but every state still demands a decision.

Summers calls the emotional cost “the human reward function problem”:

Here’s a term for what I think is happening: the human reward function problem. In machine learning, a reward function tells an agent what good looks like. Writing code by hand was never easy, but it was full of small rewards. Solving a problem in your head. Understanding a gnarly bit of logic. Watching the code compile. The feeling of control. LLM-assisted programming has automated much of the work that generated those dopamine hits and replaced it with the cognitive load of review and supervision. The satisfying part shrank. The exhausting part grew. And there are no new rewards to fill the gap.

If you’re feeling like your work is simultaneously more productive and less satisfying, you’re not broken. The feedback loop is broken. And I think we need to start treating that as an engineering problem in its own right, not a personal failure.

Jihoon Jeong asks the question: if the model starts fresh each cycle, what actually compounds? He uses software developer Geoffrey Huntley’s Ralph Wiggum loop to illustrate:

If the loop’s power came from looping — from persistence of effort, from the agent grinding away at the problem — then the longer you could keep one agent going, the better it should get. The opposite is true, and every practitioner knows it. A long agentic session curdles as its window fills with dead ends and stale state; the agent gets worse with continuity, not better. The winning configuration, rediscovered by everyone who runs loops at any scale, is maximum discontinuity: kill the agent every iteration, resurrect it blank, and let it inherit nothing except what the last iteration wrote to disk. Huntley’s design wasn’t naive. It was surgical. Discard the mind, keep the files.

Fresh context is only useful if the loop can tell progress from activity. Jeong puts that burden on the verifier:

Second, one of the five decisions is load-bearing in a way the others aren’t. The verifier is the wall the whole structure hangs on. A loop repeats whatever its verifier accepts; if the verifier is strong — tests, compilers, benchmarks, anything with teeth — the loop compounds progress, and if the verifier is weak, the loop compounds output. Every experienced loop practitioner converges on the same rule: the loop is exactly as good as its stopping test. A loop with a weak verifier isn’t an autonomous engineer. It’s an expensive random walk with excellent posture.

Jeong’s answer is that the model starts each cycle from scratch, while plans, tests, commits, and code preserve progress for the next one:

The loop works, and the skeptics are right about why its working is strange. It adds no intelligence. It makes no model smarter. It rents the same brilliance every cycle at full price, extracts what it can, and throws the brilliant thing away — keeping only the residue on disk, because the residue is the only part that compounds. It works better than it has any right to, exactly as I said last time. And its characteristic failure mode is now visible at scale too, and it is not a crash. It’s a flatline. The loop keeps turning, the tokens keep burning, and the density of correct answers stays wherever the verifier pinned it — because nothing inside the system learns from one cycle to the next. The agent that finishes iteration forty is precisely as capable as the one that started iteration one. Only the pile of files has grown.

After Addy Osmani’s introduction to loop engineering, Robert Ross, writing at The Thought Drop, opens up the machinery. What looks like one agent loop is really three nested loops:

Agent loops are often oversimplified. They’re presented as a single loop, when really it’s three loops in a trench coat that make up an “agentic” experience for a customer. I’m here to write (yes, I wrote this, insane right?) yet-another-blog about agent loops. The example code blocks are also pseudo-code and for illustrating these ideas. Also I’ve omitted streaming, which complicates the post but the shape of these stays the same.

Those are the inference loop, which manages model calls and conversation history; the tool loop, which turns model output into actions; and the human loop, which approves, rejects, or redirects consequential work.

Ross’s “brain in a jar” analogy explains why the tool loop changes a model into an agent:

LLMs are brains in a jar. They provide no functional value on their own. The tools you give an LLM are what make it an agent.

When you tell a model “here are the tools you have” in your outer inference loop, the model may try to “use” them in its inference (response). This is the same thing as a brain sending an electrical signal telling your index finger to hover over the enter key of the email you desperately want to send Laney. Tom, we need to set boundaries my man.

The separate tool definitions you include in your API request are usually serialized into the system prompt field of the token stream the model processes. And it may infer the usage of multiple tools in one turn. (Hence: Tool Loop).

The human loop is the final layer—and the hardest to build:

The Human Loop is arguably the hardest part to implement in agentic systems. You can’t have a piece of code block for hours. What if the server restarts? What if you have thousands of other requests coming in you need to respond to? The first two loops (inference and tool) are simple enough. The human loop ups the ante of difficulty. This is why durable execution frameworks exist, like Temporal.

But the human loop is necessary, because it’s the only thing stopping Tom from actually sending that message to Laney. IT WAS TWO YEARS AGO TOM, MOVE ON!

We’ve heard about prompt engineering and then context engineering, and now it’s loop engineering. Googler Addy Osmani offers a clear introduction to it, beginning with a simple definition:

Loop engineering is replacing yourself as the person who prompts the agent. You design the system that does it instead. A loop here can be thought of a recursive goal where you define a purpose and the AI iterates until complete.

What changes is who keeps the work moving:

For like two years the way you got something out of a coding agent was you wrote a good prompt and shared enough context. You type a thing, you read what came back, you type the next thing. The agent is a tool and you are holding it the entire time, one turn after the other. That part is kind of over, or at least some think it’s going to be.

Now you build a small system that finds the work, hands it out, checks it, writes down what is done and then decides the next thing, and you let that system poke the agents instead of you. I wrote before about the cousin of this, agent harness engineering, which is making the environment one single agent runs inside and the factory model - the system that builds the software. Loop engineering sits one floor above the harness. The harness but it runs on a timer, it spawns little helpers, and it feeds itself.

And the loop itself has a recognizable anatomy:

A loop needs five things and then one place to remember stuff. Let me list it first and then map it.

1. Automations that go off on a schedule and do discovery and triage by themselves.
2. Worktrees so two agents working in paralell dont step on each other.
3. Skills to write down the project knowledge the agent would otherwise just guess.
4. Plugins and connectors to plug the agent into the tools you already use.
5. Sub-agents so one of them has the idea and a different one checks it.

Then the sixth thing, the memory. A markdown file, or a Linear board, anything that lives outside the single conversation and holds what’s done and what is next. Sounds too dumb to matter. But it’s the same trick every long running agent depends on and I went into it in long-running agents, the model forgets everything between runs so the memory has to be on disk and not in the context. The agent forgets, the repo doesnt.

Karo Zieminski and Dheeraj Sharma recommend starting with a critic: one recurring job, one explicit standard, and a loop that stops before autonomy outruns our ability to inspect it. Their example reviews PRDs, but the pattern fits any creative work whose quality we can describe clearly enough to test. Sharma grounds that advice in the 30-plus agents he has built for his content operation:

I have built 30+ agents that now keep a real content operation running across my newsletter and YouTube channels. You’d be surprised how modest the useful ones look. If you start with an agent that “runs your whole business”, you’ll most likely build something fragile. OpenAI’s advice is to maximize a single agent’s capabilities first before even thinking about multiple agents. Anthropic’s rule is even stricter: add complexity only when it demonstrably improves outcomes. One agent, one job, one loop.

The rubric is the consequential design artifact. It turns tacit judgment into criteria the agent can apply consistently and the human can challenge. The retry limit matters for the same reason: repeated failure becomes evidence that the product thinking needs work, rather than an invitation to let the loop run forever.

A real critic checks whether the doc can do its job after engineering pokes holes in it. It needs to be forced to review every PRD through the same fixed format (every single time), and come back with a score, a diagnosis, and a concrete fix list. It also needs a retry limit. For PRDs, 2–3 rounds is usually enough. If it still fails after 3 loops, revisit the product thinking. And keep notes about every failure. Anthropic’s evals guidance treats every bug as a test case. The PRD your critic scored wrong last week is the exact document you re-test it against after every change.

For designers, this is a practical way to keep judgment inside the system. The agent can expose weak reasoning and carry the review process forward; deciding what deserves to ship remains a human responsibility.

I always come back to the same rule: agentize the tasks, not the craft.

Use your agents to move the PRDs to GitHub, but review them first.

Keep human decision gates at the moments where judgement matters.

Keep using the parts of your brain that make the work yours. Keep the joy you find in creating it.

Claire Vo, who built a bug-triage harness for her company ChatPRD, offers a usefully plain definition of an AI harness. The important part is that the intelligence does not live only in the model. Some of it lives in the surrounding code that prepares the work, limits what the agent can do, and decides what it must leave behind.

A harness is some code around an AI agent. Yes, you heard it here first. A harness is just code around an AI agent that makes it more effective. Can that code have AI in it? Sure. Does that code have to have AI in it? Not necessarily. What is the goal of a harness? To make the AI better. It is so simple, and I feel like the way that people have been talking about this has made it such a mystery that I wanted to make it very clear to you all. It is just writing more code around your AI to make it more useful for a specific use case.

Vo’s threshold for building one is equally practical: look for work where the setup and expected result recur.

So what are the parts of a harness? Well, a harness is going to have specific context. It’s going to be able to take specific actions, and it’s going to have a goal of specific outcomes. It’s just as simple as that. And I want to talk about when it makes sense to build a harness and when it doesn’t. I think you’ll want to build a harness when the same workflow needs the same setup and the same outcomes. It’s really when there is a combination of deterministic and non-deterministic workflow, step-by-step process, tools, and use cases you want your AI to follow to do a specific job.

That turns harness-building into a design problem. The work is choosing the job, shaping the workflow, narrowing the tools, specifying the artifacts, and creating an interface through which a person can direct and inspect the system.

I identified a specific workflow. I determined what the run against the task would look like. I made very opinionated calls to tools or data sources. I didn’t just say, “Use an MCP,” although that could be part of your harness. What I did is make adapters that made the calls to these external APIs and tools very specific. I thought about what the structured artifacts out of that workflow might be. I decided what rules and permissions I wanted to give this harness and which ones I didn’t. I decided whether I wanted to use Claude Code or Codex or a model router to actually run these things. And then I built a surface to interact with this agent. It could be a TUI. It could be a CLI. It could be a web app. But I built some way to interact with this.

The model supplies capability. The harness makes a repeatable workflow legible and enforceable.

Thariq Shihipar, a member of Anthropic’s technical staff, offers a field guide for finding the context an agent needs before and during implementation:

The difference between the map and the territory is what I call unknowns. When Claude runs into an unknown, it needs to make a decision based on its best guess of what I want. The more work being done, the more unknowns Claude might run into.

Claude Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns.

Importantly, just planning ahead isn’t always enough. You can find unknowns deep in implementation, or your unknowns may point you to the fact that you should actually be solving the problem in a different way altogether.

The design-specific version is tacit judgment: criteria that become visible only after there is something concrete to react to. Shihipar’s recommendation is to use prototypes to surface those criteria while changing direction is still cheap.

When I’m working in an area with a lot of unknown knowns, involving criteria I only know to define when I see it, I like to ask Claude to brainstorm and prototype with me.

It’s extremely valuable to identify and verbalize unknown knowns early during prototyping, because finding them out during implementation can be (relatively) expensive. Small changes in a feature or spec can cause drastically different implementations in code, and it can be more difficult for your agent to revert previous changes.

For example, you may just want to see how a button added to a frame looks without having to wire up a backend route or maintaining additional state in the frontend.

This makes exploration part of specifying the work. The prototype helps the designer discover what the brief could not yet contain, while implementation notes preserve the choices that emerge after the plan meets the code.

The better models get, the more you can achieve with the right approach. When a long-horizon task comes back wrong, it’s likely you need to spend more time defining your unknowns or creating an implementation plan that allows for you and Claude to adapt through them.

Every explainer, brainstorm, interview, prototype, and reference is a cheap way to find out what you didn’t know before it gets expensive to fix.

Drew Breunig, an analyst and developer who writes about AI infrastructure, has a name for the slow accumulation of fixes, workarounds, and escalating all-caps instructions that eventually choke an AI application: prompt debt.

The plain-English prompt that makes prototypes effortless turns out to be a poor way to specify how a system should behave, and the bill arrives slowly, disguised as ordinary progress, until the application can barely move. The problem is not any single prompt. It is that natural language was never meant to be a specification language for engineering, and treating it as one quietly caps what you can build.

Breunig’s model-lock-in evidence is the warning sign. A recent Datadog report shows GPT-4o is still the most-used model in observed traffic; Breunig also says multiple large inference providers put GPT-4o and similar-vintage models above 50% of all calls. His proposed escape hatch is to stop treating hand-written prompts as the durable layer:

Every mature engineering discipline eventually stops doing by hand the very thing it once prided itself on doing by hand. Assembly gave way to compilers, hand-tuned queries gave way to planners, and manual memory management gave way (mostly) to machines that do it better. Prompt-writing is no different.

Coaxing the model with exactly the right words is a real skill, and for one-off tasks it’s often optimal. But to build reliable, improvable, and portable systems we should not be hand-tuning prompts.

For designers, the useful warning is not that prompt craft goes away. It is that fragile prompt craft stops scaling once the AI behavior becomes part of the product. If the system has to survive a model upgrade, the design work has to move into measurements and typed specifications: schemas or contracts that constrain what the model can produce and give the next model something stable to inherit.

The first time I retrofitted a URL scheme onto an existing web app, it wasn’t easy and the engineers on my team were reluctant. The work itself looked like engineering cleanup, but the problem was design debt: the product had no shared model for what its pages, states, and resources were called.

Routes accumulate around backend data models and frontend file conventions rather than the resource hierarchy a user or linking system would recognize. Ownership fragments across teams; each team names things for its own context. By the time someone wants to clean it up, the redirects are locked in by downstream dependencies and analytics instrumentation is tangled around the old slugs. The retrofix was necessary groundwork for new features that needed stable, meaningful URLs to work at all. The real lesson was that we should have had this conversation at the start, not mid-build.

JSTools.Space explains why that cleanup is so expensive:

A URL is part navigation, part application state, and part public interface. Once users bookmark it, search engines index it, monitoring systems record it, and other applications link to it, changing that URL becomes an architectural decision rather than a cosmetic edit.

Good URL design is therefore less about making every address look pretty and more about making it predictable, stable, and unambiguous.

The decision framework should be a team contract from day one: path for identity, query for optional state, fragment for in-page location or client-only state. Inconsistent routes are what make a migration touch everything. Designers should care because this is information architecture in production, not just routing syntax.

Claire Vo on her How I AI podcast gives a plain-language walkthrough of agent loops in Claude Code and Codex. The episode is technical, but the useful translation for designers is familiar: define the job, give it tools, decide what good output looks like, and make the system prove it. Once an agent can run without you, the interface problem moves into instructions, permissions, and checkpoints.

And then a couple other foundational things that I think are helpful when you’re running loops. And why are these things helpful before we get into what they are? They just keep the work clean.

If you are going to be yolo-ing loops all over the place, you’re going to want some consistency in execution, you’re going to want clean workspaces, you’re going to want conflicts resolved and avoided. And so, all these things are really to make those loops effective.

And so, what are the things? They are work trees. I feel like this entire podcast could be Git 101. But work trees are just basically a way to isolate the work, especially the coding work of an agent away from other agents’ work in a sandbox. There are skills, repeated ways to do common tasks. We have a full episode on what skills are from earlier last year when they came out. Plugins and connectors, these are just the tools that your agent has access to. […] Sub agents, both Codex and Claude Code allow you to kick off sub agents. This is just a way to federate out work from the main thread, so that sub agents can do specific tasks, especially validation. And then there’s some way to track state. And essentially just think of this is like a to-do list.

The practical translation for agent orchestration: write the operating conditions around the work before asking for the artifact.

Calling it a loop makes it sound like automation plumbing. The design work is the brief: what the agent can touch, what tools it can use, and how it knows it is finished.

The employee comparison makes the loop feel less exotic:

Now, people are going to ask, “What should I use a loop for?” And when you’re designing loops or designing agents, I say this is the time for the manager. You are designing a job. And so, just imagine that you’re onboarding an employee. That employee could be an executive assistant. That employee could be a customer service agent. That employee could be a software engineer.

Every Friday, EA, I would like you to review my calendar, see who canceled on me, where I could have used my time more effectively, if there are any follow-ups, and send me a Slack to get this done. Um and I want you to do that every Friday. Guess what? You’ve just designed a loop for your executive assistant. […]

So, I really like to think about loops as designing workflows and designing jobs to be done for people. It just happens to be that you can put this intelligent agent against the loop, and then it’s ready to go.

For designers, that last sentence is the translation layer. A designer already knows this move from creative direction: clear constraints produce better work than a blank request. The only difference is that the worker now happens to be software.

A loop without success criteria is just a faster way to make someone review the same ambiguity at a higher token cost.

We all want our agents to work for us on a schedule whenever we want, doing work that we don’t want to do. It’s great. What are some of the problems? One, loops can get expensive. So, I just kicked off an automation that happens on a regular basis. It does wide-ranging work. It decides when to spin off sub agents.

And it does loop-based validation, which means it’s burning tokens until it hits a threshold that it decides is successful. If you do not write that loop well, or your validation criteria is too thin, guess what? Your agent is going to burn tokens. I think we’ve seen this with open claw in particular or some of these agent harnesses is they’re really good at loops. They’re very diligent. They get interesting work done, but man, do they love to burn tokens.

[…] Loop-based prompting is just its own thing. Goal-based prompting in specific is just its own thing because you have to be very precise about evaluation and success criteria. If you are not, you will be very disappointed and use a lot of tokens for not a lot of output.

Cash App product designer Brad Wrage on moving design from handoff to production ownership:

Across this project, I personally merged 25 pull requests across three codebases — Android (14 PRs), iOS (8 PRs), and Server (3 PRs). As a designer.

And zooming out further — over the last two months, I personally authored ~45 PRs merged across 5 repos. As a product designer:

Wrage stayed accountable for the experience after Figma, across Android, iOS, and server. That is where the delay in a traditional handoff becomes obvious. It maps to Cash App’s org-speed bottleneck: building faster only matters if approvals, reviews, and deployment move with it.

Wrage describes the operational core:

This is where the traditional dynamic flips. Instead of filing bugs and waiting for engineering to prioritize them, I lead the charge — logging issues, kicking off fixes, and drive them to completion.

The process: visual feedback and bugs drop into a dedicated Slack channel. Builderbot — which intimately knows our codebase — picks them up and posts rapid fixes, often within minutes.

[…]

I pull the code down, test on a real device, reference my Figma file via MCP, and approve or adjust until it’s right. Every PR still gets a human review.

The guardrail is in that last sentence: code review remains part of the process. The result is a tighter loop between taste, implementation, and product judgment without removing engineering accountability.

Wrage’s phrase for that distance:

This is the inflection point. The designer isn’t on the sidelines filing tickets anymore — the designer is in the driver’s seat, leading the last mile to ship.

The last mile. The difference between “shipped” and “crafted.”

Arpan Patel wrote a nice consolidated Claude Code reference: the directory layout, CLAUDE.md the way Anthropic’s Boris Cherny writes it, skills, subagents, MCPs, the underused commands. The whole guide turns on one shift:

Claude Code clicked for me once I quit treating it like ChatGPT in a terminal. The mental model flipped from “I need to write this code” to “I need to set Claude up to write this code well.” Setup is the work. Execution is verification.

If you use Claude Code daily, bookmark it.

Simon Willison thinks the AI labs have found product-market fit. Here’s his own monthly usage priced at API rates against the $200 he actually pays:

• $1,199.79 for Anthropic Claude Code
• $980.37 for OpenAI Codex

That’s $2,180.16 worth of tokens for $200—not bad at all! I’m a moderately heavy user of these tools, but I’m certainly not running agents every hour of the day and night.

That discount is gone: since April 2026 enterprises pay full API rates. Willison’s read:

Coding agents really did change everything. These are tools which burn vastly more tokens, but are also quickly becoming daily drivers for the work carried out by extremely well-compensated professionals. Right now that’s still mostly software engineers, but a coding agent is a tool that can automate anything you can do by typing commands into a computer… so they are clearly applicable to a much wider set of skilled knowledge workers.

Right now the bill falls on engineers. Designers may be next. Anthropic has already rolled out a separate usage meter for Claude Design. And Figma is charging for AI usage overages.

Felipe A. Carriço, a UX designer and AI product builder, turns accessibility guidance into context AI coding agents have to follow with A11Y.md:

A11Y.md is not a guideline. It is an accessibility validation protocol and a persistent context architecture for developing accessible software with AI. It is designed to integrate with AI agent systems and human review workflows to ensure certifiable compliance.

By adopting the mental model of Anthropic’s CLAUDE.md—which acts as a system prompt memory for code generation—A11Y.md translates this architecture into a universal, portable governance layer. Instead of generic coding rules, it forces any coding agent (Claude, Cursor, Copilot) to strictly adhere to WCAG 2.2 AA and ADA standards from the very first line of generated UI code.

I appreciate how operational this is. It pairs well with Joost de Valk’s Website Specification, which treats machine-readable standards as part of what a good site does. A11Y.md brings the same idea into the build process: the generator has to carry the accessibility context while it makes the UI. That matters because accessibility failures in generated code are rarely abstract. They show up as broken keyboard paths, silent error states, and interface logic that only works for the person who can see and click everything.

Carriço is blunt about the difference between reading and changing the workflow:

Reading about accessibility is the first step, injecting it into your code is the real goal. Do this right now in your project:

1. Download the Rules: Copy the A11Y.md file from docs/en/ to the root of your application’s repository.
2. Inject into the Prompt: If you use Cursor, GitHub Copilot, or Claude, add this to your global rules file (.cursorrules or Context system):

“Strictly follow the development rules defined in the A11Y.md file.”

3. Use as a Quality Gate: Before merging important PRs, use the checklist in docs/en/templates/REPORT.md.

If you do not perform the steps above, you are not changing your workflow — you are just reading about the subject.

That is the product here: wiring accessibility into the build process so it changes what gets generated.

Thirty-year veteran software engineer Christoph Mütze shipped a 25,000-parameter transformer that runs on a stock Commodore 64, complete with an exhaustive test harness and a stack of reference implementations that all have to agree before anything ships. He called it SoulPlayer. In return he got called a vibecoder. Same reflex as the Monet pile-on: label first, verdict next, evidence optional. His response is the takedown of the “vibecoded slop” accusation I’d been waiting for somebody to write, and it lands on a single question that nobody on the accusing side wants to answer:

If vibecoding is what you say it is, if AI does the hard part, if the human just prompts and ships, if expertise is no longer a moat, then the world should be drowning in proper software right now. Not slop. Real tools. The kind people pay for, depend on, use every day. Two years of access. Millions of people with the models. The barrier supposedly fell. …where is everything?

David Pierce, catalogued the bespoke micro-apps people are building for themselves: family budget trackers, fantasy baseball rank engines, migration logs with a total addressable market of one. That’s real, and it’s the right scale to celebrate. But Mütze is asking a different question: where is the vibecoded Photoshop? Where is the vibecoded Maya, the vibecoded Blender, the vibecoded compiler that compiles itself? If the prompt-and-ship cartoon were true, two years in we’d have an avalanche of sophisticated tools built by people who don’t know how to code. We don’t. The category is empty. Mütze’s diagnosis of why is the part I want every designer reading this to take in:

Level 1 is what the industry usually calls coding. The syntax, the loops, the years memorizing pointer arithmetic and which header file the function lives in. LeetCode-measurable. The job interview essence. The mechanical part. The typing.

Level 2 is flow. What you do with Level 1. Knowing the right data structure. Knowing which ugly pragmatic solution to ship instead of the beautiful academic one. Reading other people’s code. Taste and judgment. The reflex of rejecting solutions that almost work and shipping the ones that do. Debugging, unit testing, the quality-control part.

Level 3 is architecture. The macro decisions, made with full awareness of their consequences. What to build at all. Why this data structure and not that one. Why this trade-off and not the obvious one. Which design survives contact with the real world, and which one silently falls apart two years later. The deciding part.

The three have never been the same thing. The gate was never at Level 1. The gate was at Levels 2 and 3, where the work that holds together actually happens. AI lowered the cost of Level 1. It didn’t really touch Levels 2 or 3. The gate is exactly where it always was.

You can easily translate this framework from engineering to design. Level 1 in design is pushing pixels: the auto-layout setup, the icon nudging, the variant-matrix work in Figma that fills our days. Level 2 is the taste that picks which of the fifteen generated directions is actually worth shipping. Level 3 is deciding what to build at all, and for whom. AI is eating Level 1 in design the same way it has eaten Level 1 in code. The designers who panic about “vibecoded design” are panicking because Level 1 was the layer they could see, measure, and defend. The gate is somewhere else, and it always was.

The reason this gets so emotional is the part Christopher Butler has been pointing at for a while: AI doesn’t just replace tools, it renegotiates what made you worth hiring. Mütze says the same thing:

The accusers cannot see this. They are not at the gate. They were at Level 1. Level 1 was their identity, their hours, their proof of belonging, their reason to feel at home in this profession. When AI made Level 1 cheap, it did not threaten the gate. It threatened them. Because they bet their self-worth on the layer that just got rented out. So they call the work vibecoded. They have to.

Mütze could weaponize the accusation back. He has the receipts: the test harness, the reference implementations, thirty years on the demoscene. He refuses and ends with a call-to-action:

If you’ve been sitting on something you made with AI, ship it. Name your tools. Don’t apologize. The accusation is cheaper than the work. Yours is worth more.

Addy Osmani makes a clean separation that most of the “is AI making us dumber” discourse keeps glossing over. He reports on Anthropic’s randomized trial of engineers learning a new Python library:

Engineers who used AI to ask conceptual questions scored above 65%. Engineers who copy-pasted the generated code scored under 40%. The tool didn’t determine the outcome. The posture did.

Osmani is writing for engineers, but most of that translates to designers picking up Figma Make, Lovable, or v0. Ship-without-comprehension scales beautifully right up until the moment you have to debug, redesign, or defend a choice you didn’t really make.

He ends on a ritual any designer can adopt verbatim:

I’ve started ending coding sessions with a simple question: did I learn anything today, or did I just close tickets? Sometimes the honest answer is “I just closed issues” and that’s fine. If it becomes the answer for months in a row, cognitive debt is accumulating in the background. Ship and learn are two separate metrics.

Workslop is the companion failure mode: the cost goes to your coworkers, where skipped learning costs your future self.

Most agent-velocity hype rests on one premise: that writing code was the slow part. .txt, the team behind the structured-generation library, takes a saw to that assumption. The point goes back to two foundational software-engineering texts—Fred Brooks’s The Mythical Man-Month (1975) and Gerald Weinberg’s The Psychology of Computer Programming (1971)—and .txt puts it like this:

Software is what’s left over after a group of humans finishes negotiating with each other about what the system should do. The code matters, but it is the residue of the harder work, not the work itself.

Code as residue. That inversion reorganizes the whole conversation. The tools and processes we’ve built around software for fifty years—IDEs, wireframes, mockups, code review, even pair programming—have been about lowering the cost of producing the residue. Once that cost approaches zero, what’s left to slow you down is the negotiation underneath. And that negotiation has not gotten any cheaper.

What that layer actually consists of, in practice:

What slows down a team where agents do the implementation is the production of specifications precise enough for an agent to pick up and run. Roadmap, written down. Acceptance criteria, written down. The “what we actually want” forced into precision, be it via a test suite, a ticket, or a written design.

The bottleneck moves from people writing code to people deciding what code should exist. .txt calls that work management, and I’d put it a little wider; it’s also product, design, and anyone whose job description includes the phrase “what we’re building.” A spec precise enough for an agent is a falsifiable description of the outcome, with the trade-offs already made.

.txt on what runs underneath the spec:

Context is the commodity an organization runs on. It is the shared understanding of what we are building, why it matters, what has been tried, who decided what, what is load-bearing and what is vestigial. Humans on a team accrete it by osmosis. By being in the room, by reading the same Slack channel, by debugging the same outage at two in the morning. Most of it is never written down. When a senior engineer reviews a PR and says “this’ll break the migration,” they are drawing on context that has no document. Agents cannot do osmosis.

“Agents cannot do osmosis” is the line. Specs are the formal surface; context is what’s underneath, and teams absorb it without writing it down. The post closes here:

The companies that win the next decade will not necessarily have the best models or the best agent infrastructure. It will be the companies whose fifty people, then two hundred, then two thousand, can stay aligned on a shrinking set of decisions while shipping more output per head. They will be the ones that already knew, before agents arrived, that their hardest problem was coherence. That is a culture and management problem. Always has been.

Thariq Shehzad, on the Claude Code team at Anthropic, has switched from markdown to HTML as his default agent output format. The reasoning is more honest than a format-war argument would suggest, because it’s about what humans will actually read. He opens by acknowledging what markdown was for:

Markdown has become the dominant file format used by agents to communicate with us. It’s simple, portable, has some rich text capability and is easy for you to edit. Claude has even gotten surprisingly good at using ASCII to make diagrams inside of markdown files. But as agents have become more and more powerful, I have felt that markdown has become a restricting format.

Then the pivot:

As Claude is able to do more complex work, it is also writing larger and larger specs and plans. In practice, I’ve found I tend to not actually read more than a 100-line markdown file, and I certainly am not able to get anyone else in my organization to read it. But HTML documents are much easier to read, Claude can organize the structure visually to be ideal to navigate with tabs, illustrations, links, etc.

When the spec gets long enough that you stop reading it, you’ve quietly moved from review to rubber-stamp. Shehzad’s answer isn’t to ask Claude for shorter specs. It’s to make the artifact something a human will actually open, scroll, and share. A controllable, shareable artifact is most of what made personal computing legible in the first place; HTML is the format that already does it.

He puts the trade-off honestly when the obvious objection comes up:

While markdown often uses fewer tokens, I’ve found that the added expressiveness of HTML and the much higher likelihood of me reading it means I get overall better output. With the 1MM context window in Opus 4.7, the increased token usage is not really noticeable in the context window.

And the close is the real argument:

The real reason I use HTML is that I feel much more in the loop with Claude. I had begun to fear that because I had stopped reading plans in depth I would simply have to leave Claude to make its choices. But I am happy to say instead that I feel more in the loop than ever before when using HTML.

“Slop cannons” is Darragh Curran’s term for the fear that AI-generated code will degrade craft. The fear is real. The same fear runs through design: AI-generated interfaces will be derivative, generic, indistinguishable from each other. Curran is Intercom’s CTO, and he published a detailed report on what happened when Intercom went agent-first across their entire R&D org. The result: 3x productivity in 16 months, tracked across nine metrics. The code quality results were not what anyone expected.

Curran:

A legitimate worry with the use of coding Agents, is that they won’t write high-quality code and the craft we’ve fought to protect will be undermined by slop cannons. We have a system to rate the structural quality of code contributions using static analysis and various rules/heuristics. It’s clear that prior to agentic coding, this metric would oscillate up and down above the line. As we started to use AI for writing more and more of our code, the overall quality (by this measure) declined. My intuition was that this was inevitable in the short term, but correctable in the medium term, as models and harnesses get better. We are starting to see this and recently had possibly our first ever five-week streak of net positive code quality overall.

Quality did dip. He confirms it. The slop cannon fear describes a real phase: at 93.6% agent-driven PRs, when agent-generated code degrades, the whole org feels it. But there’s a second finding:

There is huge latent potential. Some people are really pushing the limit of what is possible, tokenmaxxing, doing really interesting things, while others have only really made incremental changes to how they’re working and don’t see much change in their personal throughput. Ultimately one of the biggest bottlenecks to progress is with humans; how we work together, how we change behavior, etc.

Intercom’s top 5% of contributors produce 6x the median PR throughput. Those are the people spending over $1,000 a month on tokens. That spread is the real finding from going agent-first. The slop cannon fear is about whether agents can execute well. The 6x gap is about who’s learned to orchestrate them, and Curran’s candid that most of his org is still finding out.

For design, we worry about going too fast, of solving the wrong problem, and building the wrong thing. Those are legitimate fears. Nonetheless, if you’re working in startupland as a designer, acceleration and automation are coming.

The designer’s role is widening at both ends of the product stack. Earlier, I linked to a post by Chad Johnson arguing designers gain influence by moving upstream: becoming orientation devices for the team, shaping the problem before it gets named. Daniel Mitev, writing for UX Collective, argues designers gain authorship by moving downstream, into the code:

The industry has been asking whether designers should code for over a decade. It was always the wrong question, or at least the wrong framing. It implied the barrier was technical: that designers lacked something fundamental, something that required years of study to acquire. Learn TypeScript. Understand the DOM. Earn your way across the divide. That wasn’t the barrier.

Mitev’s argument comes down to access. AI tooling compresses the translation layer and returns authorship to the designer:

What AI tooling gives back is authorship over the surface layer — the part users actually touch. A designer can now open the codebase, adjust how an element behaves, change how a transition feels, and verify the output against their own intent in real time. The easing curve gets set by the person who decided what it should feel like. The hover state gets defined by the person who thought through why it matters. That work no longer requires an interpreter.

He points at Alan’s “Everyone Can Build” initiative—283 pull requests shipped by non-engineers over two quarters, each merged after engineering review—as evidence it’s already happening.

Johnson and Mitev aren’t in conflict. They’re describing the same shift from opposite ends. The interpreters at the top of the product stack—PMs who owned problem framing and prioritization—are compressing. The interpreters at the bottom—frontend engineers translating intent into code—are compressing too. Both jobs return to the designer who understood the intent first.

The role widens. Some designers will gravitate to one end or the other. The designers who stretch the full range—orientation work and authorship—are working the widest version of the job.

Anthropic accidentally included a debug file in a recent update to Claude Code. That file let people reconstruct the entire internal codebase: roughly 500,000 lines of code across nearly 2,000 files. It wasn’t a hack or breach—it was a packaging mistake. Anthropic cited “human error.” No customer data or AI model secrets were exposed. What leaked was the scaffolding around the AI, the layer that decides how Claude Code thinks, acts, and talks to you.

The reconstructed code hit GitHub and became one of the fastest-starred repos in the platform’s history before Anthropic started issuing takedowns. People found an always-on background agent mode codenamed “KAIROS,” a “dream” mode for continuous ideation, and Tamagotchi-style pet behavior baked into the tool. (See for yourself! Type /buddy and see what happens.) Ars Technica has a good breakdown of what the code reveals about where Anthropic is headed.

A developer in France named Zack mapped the entire codebase and created this microsite to illustrate what happens when you send a message to Claude Code. Fascinating.

Most AI tools start with a blank chatbox. OK, maybe not completely blank. Often there is a gallery of examples right below the input. But it’s still hard to come up with something original when faced with a blinking cursor.

Brad Frost calls this moment “the Creative Infinite”:

Never before in human history has it been possible for anyone to simply ask for something to exist, and then it just…exists. Where the inputs can be anything, the outputs can be anything, and the whole process can be repeated, iterated, combined, translated, and chained together indefinitely.

He makes the case concrete with his 8-year-old daughter:

In 5 minutes, Ella vibe-coded a playable game (built in Three.js via Claude Cowork) running in the browser. That’s just bonkers. At no point in human history has it been possible to simply describe a game in words and then just… play it 5 minutes later.

A Michael McDonald (interesting taste for an 8 year-old!) penguin adventure, because she knew it would make her dad laugh. The capability is real and the story is delightful. But then Frost hedges:

Your existing creative fluency still matters, maybe even more than before? Just as being able to play piano puts you in a better spot to wield a synthesizer. Knowing how to design makes you better at prompting visual tools. Understanding code makes you better at architecting what you want to build with AI. Craft. Taste. Art. Authentic expression. Purpose.

Yes, creative fluency matters more. It absolutely does. The piano-to-synthesizer analogy is exactly right: the tool revolutions I’ve lived through have compounded on existing skill, not replaced it. A designer who understands visual hierarchy and restraint will direct AI better than someone who’s never thought about why one layout works and another doesn’t.

StrongDM built a system where humans never write code and never review code. The entire engineering workflow is delegated to AI agents. Ethan Mollick covers this in One Useful Thing:

A three-person team at StrongDM, a security software company focusing on access control, announced they had built a Software Factory — a way of working with AI agents that relied entirely on the AI to write, test, and ship production software without human involvement. The process included two (quite radical) rules: “Code must not be written by humans” and “Code must not be reviewed by humans.” To power the factory, each human engineer is expected to spend amounts equivalent to their salary on AI tokens, at least $1,000 a day.

$1,000 a day per engineer. The humans write the roadmap; coding agents build the software while testing agents spin up simulated customer environments and stress-test it. The agents loop until the results pass, then humans review the finished product, never the underlying code. Simon Willison and Dan Shapiro both observed the Factory in operation and wrote detailed accounts.

Mollick’s larger argument is that experiments like this matter beyond their specifics:

We can see the shape of the Thing now, but we can still influence the Thing itself, and what it means for all of us. We clearly don’t have rules or role models for how AI gets used at work, in schools, or in government. That’s a problem, but it also means that every organization figuring out a good way to use AI right now is setting a precedent for everyone else. The window to shape the Thing may not last long, but it is here now.

Design doesn’t have its rulebook for this yet either. Our time to define it is now.