Process servers spend their day driving to addresses and trying to hand legal papers to people, and every attempt gets logged in a form. Operators back at the desk build work orders field by field. We could have put a sparkle on both. Most people think adopting AI means adding it to the work you already do, but I now think that’s only adoption, and it’s the easy part. Transformation starts when you ask which steps should still exist once a model can do some of the work, and that question turns out to be where AI governance begins too.

The feature reflex

“Where can we add AI?” is the default question for a reason. Roadmaps are written in features, demos are judged by what appears on screen, and stakeholders want something they can point at. A sparkle on an existing button is cheap, visible and quick to ship. It also asks nothing difficult of the business, because the workflow underneath stays exactly as it was. That is why it feels like progress.

The feeling is misleading, and it’s easy to see why once you look closely. A sparkle can sit on top of a workflow for months without changing what anyone actually does. The form still gets filled in, the work order still gets built field by field, and the person doing it now has one more button to ignore or double-check. Usage goes up while nothing underneath moves. Most teams aren’t short of AI. They’re short of work that has been redesigned to use it.

A form that shouldn’t exist

Once the question changed, the ideas changed with it. Instead of a smarter attempt form, we started designing toward voice logging, where a server simply says what happened from their phone or through CarPlay and the system turns that into a structured record. Instead of an operator filling out a work order field by field, the model drafts it and the operator reviews it. Instead of an operator hopping between screens, the workspace starts from a conversation. None of these make the old step faster. Each one asks whether the old step should be done by a person at all, and moves the human to the part that actually needs judgment.

I’ve started thinking of this as the difference between decorating a step and removing it. A decorated step stays exactly where it was, with a model placed on top as a helper you have to go and visit. The form still exists, the screens are the same, and the AI is one more thing to click. A removed step leaves the person’s hands entirely: the model does it, and the person does the deciding. Decorating is adoption and removing is transformation, and you can usually tell them apart with one question: if you took the AI out tomorrow, would the workflow still make sense? If the step was only decorated, it would, which tells you the AI was never really part of it.

The connections you can’t see

Removing a step is harder than it sounds, and I learned why the uncomfortable way. Earlier on this same platform, I jumped straight into design and development without fully understanding how the different modules connected. On paper, the services looked separate. In practice, a process service job can include a home inspection, so a work order created for one service may need to link to another. I found that out after the screens were drawn, which is the most expensive moment to find anything out.

That lesson matters even more with AI. If a model is going to draft work orders, it has to understand those links, or it will produce something that looks complete and quietly misses half the job. Dropping AI into one module means it inherits every dependency nobody wrote down. On this platform there are no paralegals between the people who define the work and the people who do it, so the real map of the workflow lives in the users’ heads. Getting it onto paper before redesigning anything is not a nice-to-have. It is the first step of transformation, and it is the step that adoption gets to skip.

The case for starting small

There is a good argument for decorating first, and I want to give it its due. Adding a helper to an existing screen is cheap and reversible. It doesn’t ask people to change habits they’ve built over years, which matters a lot in legal work, where a missed detail can have real consequences. It lets a team learn what the model gets wrong before handing it anything important. And it builds trust slowly, which is often the only way trust gets built. If I were a cautious operations lead, I’d probably argue for exactly this.

The trouble is where it stops. A smarter form is still a form, and the gains tend to stay with the individual, a few minutes saved here and there, rather than changing how the business runs. Starting small is right, but small should mean one workflow rebuilt properly, not AI sprinkled lightly across ten. On our platform, rebuilding just the attempt log would change more for a server than any number of helpers on the old screens, because it removes a step instead of decorating it. The caution is sound. It’s the shape of the first step that needs rethinking.

Tools that disappear

The clearest way I’ve found to think about this comes from an unlikely place. In Being and Time, published in 1927, Martin Heidegger describes using a hammer. When you’re hammering well, you don’t notice the hammer at all. Your attention is on the nail and the wood, and the tool withdraws into the work. He called this being ready-to-hand. The hammer only becomes an object you stare at when something goes wrong, when it’s too heavy or it breaks, and then it shows up as present-at-hand, a thing to inspect rather than a thing to use.

A decorated step keeps the AI permanently present-at-hand. It’s a button you notice, a panel you open, a chatbot you have to remember is there. You end up thinking about the AI instead of the work, which is the opposite of what a good tool does. When the step is removed, the AI has a chance to become ready-to-hand. The server talks about what happened at the address, not about the software, and the record simply appears. Heidegger also insisted that a tool never exists alone. It always sits inside a whole network of other tools and purposes. That is the same lesson the interlinked services taught me, written nearly a century earlier: you can’t understand the tool without understanding the web of work it belongs to.

Where governance actually begins

This is the first piece in a series on AI governance, so it’s worth saying why I started here rather than with policies or frameworks. You can’t govern AI you’ve only sprinkled around. Decoration spreads quietly, one helper here and one summary button there, and soon nobody can say where the model makes decisions and where it merely suggests. Add the personal AI tools people use at work without telling anyone, and the picture gets blurrier still. Governance in that world becomes a chase after features that were never designed to be governed.

Removing steps forces those decisions early, because you can’t redraw a workflow without deciding where the model acts, where a person reviews, what gets logged and who answers when it’s wrong. I’ve spent the past few weeks building a small AI governance register for Jira, and the thing I keep running into is that a register is only as useful as your answer to a simpler question: where does AI actually live in your work? So I turned the lessons from both projects into a small loop I’ve started using, which I call the decision loop.

The idea underneath it is simple: govern the decision, not the feature. A sparkle button is a feature. What actually needs governing is the decision the AI has quietly taken over from a person, like what a work order contains or whether an attempt counts as completed. So every step in the loop asks two questions at the same moment, one about the product and one about governance. They belong in the same conversation, not in two different meetings held months apart.

Find it. The product question is where AI already lives in our work, and the governance question is which of those places we actually know about. That list has to include the official features, the sparkle buttons someone shipped last quarter and the personal tools people use without telling anyone. You can’t govern AI that isn’t on the list, and in most teams the list is shorter than reality.

Name the decision. For each workflow, ask whether a step should still exist once a model can do part of it. Then ask which decision the AI is now making that a person used to make, and write it down as a decision rather than a feature. “Decides what goes into a work order” tells you far more about the risk than “AI drafting” ever will.

Trace where a mistake travels. Map how the workflow connects to others, with the people who actually do the work. Then ask the governance version: if the AI gets this wrong, where does the error end up? On our platform a bad work order would not stay in one module. It would flow into a linked service, and someone downstream would act on it without knowing where it came from.

Draw the line. Decide what the model does and what a person does. Then name who is accountable when it goes wrong and how a person overrides it. That has to be a role with a name attached, not “the team” or “the system”, because a decision nobody owns is a decision nobody will catch.

Write it before the code. Alongside the spec, write the governance entry: the decision, the data it uses, the owner, the failure path and what gets logged. This is exactly the kind of record I’ve been building a register for. The rule I’m holding myself to is that if you can’t fill in that entry, the feature isn’t ready to build, however good the demo looks.

Watch it live. Once it ships, keep asking two things together: is it working for the people using it, and are they overriding it, working around it or trusting it too much? Overrides are useful data here, because each one is a person telling you where the model’s decision and theirs part ways. Any change to the workflow or the model sends you back to naming the decision, which is why this is a loop and not a checklist you finish once.

That’s six steps, but they come down to one habit: every time AI takes over a step, find the decision hiding inside it and give it an owner before it ships. The rest of this series walks through the loop one piece at a time. The next article starts at the beginning, with the question most organisations can’t yet answer: before you govern AI, do you even know where it exists?

I keep coming back to that sparkle icon. In the version of the workflow we’re designing toward, the server never sees one. They walk back from a door with the engine running and the next address waiting, say what happened, and the record is drafted for a person to check. Nobody fills in a form, and nobody clicks a sparkle to get help with it. The best AI in that workflow is the one nobody has to open.

We’re thinking about AI transformation all wrong was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

You make more decisions than you think.

Some of them never appear on your agenda. Some are never discussed. Some are never even recognised as decisions.

And some of the most expensive ones are the ones you never make.

You are in a meeting. A decision is being made. Two options are on the table: Option A. Option B.

Everyone is discussing the pros and cons. The conversation moves back and forth. The arguments are good on both sides. The group is trying to decide.

But no one is talking about Option C. The option of doing nothing. The option of waiting. The option of saying, let us think about it.

Option C is not on the agenda. It is not being discussed. It is not even being considered.

But it is still a decision.

And it might be the most expensive one of all.

We tend to believe that decisions are about what we do. That choosing is an active process. That the real question is: which option should we choose?

But that is not how decisions work.

Every choice is also a refusal. Every “yes” is also a “no.” Every action also means not taking another action and the cost of what you do not choose is often invisible.

This is the cost of opportunity. Not a number on a spreadsheet. Not a line in a budget. It is the gap between what you could have achieved and what you actually achieve. It is the price of not deciding. It is the cost of doing nothing.

Every yes is also a no and every no has a cost.

Let us look at how this works.

When you choose Option A, you are not just saying yes to A. You are saying no to B, to C and to everything else that might have been possible.

The cost of saying yes to A is not just the resources you spend on A. It is the value you could have created with B. The opportunities you could have pursued with C. The potential you could have unlocked with D.

This is the invisible cost of every decision. It is not the cost of what you do. It is the cost of what you do not do.

The most expensive decisions are often the ones you do not make.

This is why inaction is not neutral.

When you decide to wait, you are still deciding. When you decide to postpone, you are still choosing. When you decide to do nothing, you are still making a choice.

And that choice has consequences.

The client who waits too long loses the opportunity. The team that delays loses momentum. The professional who avoids a difficult conversation loses trust. The organisation that hesitates loses market share.

These costs are not immediate. They are not visible. They do not appear on any dashboard. But they are real and they accumulate.

Inaction is not neutral. It is a decision with a cost.

Let us look at where this plays out.

A client is considering hiring you. They like your work. They trust you. They have the budget. But they are not sure. They want to think about it. They want to compare options. They want to wait.

They do not say no. They say not yet.

But not yet is still a decision and the cost of that decision is the opportunity to work with you. The value you could have created. The problems you could have solved. The outcomes you could have delivered.

Eventually, the opportunity passes. The budget is spent elsewhere. The need is filled by someone else.

They did not say no. But the outcome is the same.

Not yet is often a more expensive decision than no.

This is the mechanism that most people misunderstand.

They believe that waiting is safe. That hesitation is prudent. That doing nothing is not a decision.

But in a world of limited time, limited resources and limited attention, every moment you spend not deciding is a moment you are losing.

The cost of opportunity is not just about money. It is about momentum. It is about trust. It is about reputation. It is about the relationships you build or fail to build. It is about the value you create or fail to create.

The cost of opportunity is not a number. It is the accumulated weight of what you did not do.

There is a second layer to this, one that is even more subtle.

What you do not do also signals what you value.

When you say yes to something, you communicate what matters to you. When you say no, you communicate what does not. When you do nothing, you communicate something else.

You communicate that you are not sure. That you are not committed. That you are not willing to take a stand. That you are not ready to make a choice.

And that signal is received. Not consciously. But it is received. People notice hesitation. They notice avoidance. They notice the absence of a decision. And they draw conclusions from it.

Inaction is not silent. It is a signal.

This is why the most successful people and organisations are not the ones who make the fewest mistakes. They are the ones who make the most decisions.

Not because they are reckless. Because they understand that the cost of indecision is often greater than the cost of a wrong decision.

A wrong decision can be corrected. A missed opportunity cannot be recovered. A moment of hesitation cannot be reclaimed. A decision not made is a decision made by default and the default is rarely the best option.

The cost of a wrong decision can be visible. The cost of no decision often remains invisible until it is too late.

Let us look at what you can do about it.

The first step is to recognise that inaction is a decision. When you are hesitating, ask yourself: am I deciding to wait? Am I deciding to do nothing? And if so, what is the cost of that decision?

The second step is to ask a different question. Not “what is the risk of doing this?” But “what is the risk of not doing this?” Because the risk of inaction is often greater than the risk of action.

The third step is to remember that every decision has a cost. But the cost of indecision is often the highest cost of all. Not because it is immediate. Because it accumulates. Day after day. Week after week. Year after year.

The most expensive decision is often the one you did not realise you were making.

You are still in that meeting. Option A. Option B. Option C.

Everyone is still talking. The arguments are still good on both sides. The group is still trying to decide.

But now you know something you did not know before.

You know that not deciding is also a decision. That waiting is also a choice. That doing nothing is also an action.

And you know that the cost of that decision is real.

So you say something. You say: What is the cost of not deciding?

The room goes quiet. No one had asked that question. No one had thought about Option C. But now they are thinking about it and the conversation changes.

Every yes is also a no. And every no has a cost. The question is whether you are aware of it before you pay it.

What you are not doing is your most expensive decision was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

Unlike software, design frameworks do not announce when they have become outdated; there is no warning or deprecation notice. Nevertheless, they continue to be cited and referenced without necessarily being appropriate.

This tension became clear to us when we used the Value-Sensitive Conversational Agent (VSCA) Framework and Toolkit (Sadek et al., 2025) at the International Positive Psychology Association’s AI and the Future of Wellbeing Summit. We ran two workshops to support a group of 18 psychologists and related wellbeing experts in designing LLM-powered chatbot prototypes.

The VSCA framework was introduced as a practical way to help conversational AI creators and users collaboratively design value-sensitive systems through three activities that generate three design artefacts. The first activity involves creators brainstorming technical capabilities and opportunities available to them, while users brainstorm use-cases and scenarios. Groups then combine to match up the two together. The second activity involves creators drafting design requirements for the pairs from the first activity while users explicitly name relevant and important values to consider for each pair. The group then comes together to refine the requirements based on the values and prioritise them. The final activity then involves prototyping conversations focusing on derived requirements and values through flowchart design and roleplaying. This is all achieved through a toolkit made up of a guidebook, canvases, cards, and information sheets.

Importantly, VSCA was developed to be used by a mix of technical practitioners, non-technical practitioners and users, and was created just as LLMs were taking off in early 2023. Our underlying question was therefore: What happens when a design framework built just before the LLM boom is brought into a room shaped by it?

What we found was that some parts of the framework held up remarkably well, while others needed revisiting. The framework had aged in very specific ways due to changes in conversational technology and due to changes in who now gets to design it.

Our framework aged in two ways

The first obvious shift we observed was in relation to technological capabilities. Many conversational design frameworks were developed for rule-based systems and task-oriented bots. Even with the use of machine learning models, the system was still comparatively stable, and capabilities could be defined within a somewhat narrow scope.

This has now changed with LLM-based conversational systems whose underlying mechanism is generation rather than routing or retrieval. This new capability introduced several layers of complexity. All of a sudden, conversational systems could feign both warmth and empathy, or confidence and authority, without the underlying content meriting resulting trust and attachment. Design decisions now span much broader considerations ranging from disclosure and safety to hallucination mitigation. The resulting user experience is now also dictated by things like prompts and mechanisms for memory and retrieval, not just by buttons, flowcharts or personas.

The second shift we noticed was social. LLMs democratised conversational AI design such that it is no longer only accessible to specialist technical teams. The practical barriers to participation in the design process have largely been dismantled and non-technical stakeholders such as domain experts and users can now shape these systems through approaches such as prompting. The population of people who can meaningfully design a conversational system has expanded. Nevertheless, the majority of existing design frameworks still carry a fairly stable image of participatory design within the conversational AI design context where there is a technical team on one side, nontechnical stakeholders on the other, and the framework helps them to meet in the middle.

The workshops we ran flipped the conventional setting, whereby participants were only non-technical domain experts (psychologists). These participants had the full authority to imagine an application from scratch, articulate the values at stake, and then shape the system’s requirements and interactions, as opposed to just reacting to someone else’s concept or validating a finished direction.

What we had to change

Overall, we adapted the framework in three major ways. The first change was to add a step ‘zero’. When the framework was used with both practitioners and external stakeholders, the team already arrived with a domain, an application idea, and a general implementation strategy. Working with just domain experts allowed us to start further upstream and introduce human values into questions such as ‘who is this for?’, ‘what exactly should be built?’, and ‘what kind of moment in a person’s life would make a chatbot useful?’.

Given that LLMs now make the prototyping phase much more accessible and immediate, it was incredibly positive to see participants spending more time deciding what proposed applications were meaningful and what exactly was needed, given important contextual values, before turning to prototyping and implementation.

The second change was to reconsider what VSCA introduced as ‘technical’ considerations. We had to convey the fact that capabilities are no longer simply tied to modifying a fixed script, but rather nudging and shaping a probabilistic agent. This led to conversations about hallucinations, overconfidence cues, and longitudinal drift, rather than just discussing what a system can or cannot perform.

The last change came from the fact that there was no technical team in the room, and so the toolkit materials themselves had to do more work. That changed the role that the information sheets and prompts played during the workshop. Previously, non-technical participants had treated technical considerations as something they could discuss later with the technical team. Here, the materials became stand-ins for those absent collaborators and so the participants consulted them much more heavily to scaffold discussions, gauge plausibility and anticipate implementation requirements.

Instead of bridging between groups of participants, the toolkit materials acted as a substitute for one group in this instance. This shift suggests that a collaborative design toolkit needs to support participants in reasoning across disciplinary boundaries when one group of participants is absent.

What still held up

Most importantly, the workshop showed us that working with human values still remained at the centre of resulting conversation design work. Participants were able to clearly articulate what matters to them, showcasing even more expansive and generative values than in the original workshops where the framework and toolkit were used. Participants introduced new values beyond the examples provided (something that original participants had not done) and those values were highly experiential and relational in nature.

For example, participants introduced the value of ‘vulnerability’ as a user state. Participants were concerned about users feeling vulnerable or emotionally exposed while approaching the system or using it, and how to design for those states. This example is significant because it shows participants thinking of broader, human-centric values rooted in domain expertise and not often considered by technical teams. It also translates into interesting design decisions around not punishing hesitation or making requesting help feel performative.

The second activity around prioritising resulting values and requirements was helpful to mediate tensions across participants. When considering the value of ‘efficiency’, some participants argued from the perspective of end-users, while others considered the potential opinions of a technical team. This led to an enriching discussion on why technical teams might favour efficiency, while it might actually be counter-productive to users who might feel rushed and dismissed. It was interesting to see how a mono-disciplinary group surfaced value tensions in this way, not because it emerged across the group members themselves, but because they were trying to anticipate the perspectives of other groups absent from the workshop.

That was a useful reminder that workshops do not contain only the people in the room. The prioritisation activity gave an effective platform to surface echoes of institutional/professional/user-based perspectives without letting them dominate.

Finally, the workshop also confirmed the usefulness of tangible design materials. As participants did not have technical colleagues to discuss or translate certain concepts later (such as ensuring that ideas were feasible), the physical scaffolds provided were more heavily used. The cards, canvases and prompt sheets allowed participants to structure discussions, providing shared objects through which different opinions can travel.

What became harder

Participants reported that working so explicitly with human values was harder than thinking about user needs, use-cases or design requirements. In the second activity where participants had to explicitly name relevant and important values, they found it easier to discuss what the chatbot should do rather than which values should guide that behaviour. This suggests that value-sensitive design rests on conscious and guided effort rather than just intention or care alone. This was also the case with the original workshops, but became more pronounced here as participants were trying to think of values, features, behaviour, feasibility, and so on, all at the same time, with no support from collaborators with technical or design experience.

One clear example was a conversation around the value of ‘authenticity’. Participants went back and forth debating whether authenticity was rooted in honesty or self-expression, how to avoid authenticity becoming fake and manufactured, and what authenticity means when it is attributed to a user versus a chatbot. The toolkit helped to make visible the fact that values can be composited and layered, but these discussions also highlighted that, with LLMs’ increased language and social capabilities, these values may need more decomposition and deliberation.

Another area of tension was when participants only began considering technical features and requirements during the final prototyping phase. If technical practitioners had been present, this would have happened much earlier. Instead, here it only surfaced when people had started envisioning dialogues and interactions through roleplaying, leading to many pivots back and changes in previous decisions.

This was valuable to note as it suggests that, for non-technical participants, implementation decisions can become easier to grasp and comprehend when they are attached to concrete conversations and interactions. When participants experienced chats for themselves, they could then begin to specify when the chatbot needed to change its tone, disclose information, communicate uncertainty and so on. Given that LLMs have closed the distance between initial ideas and prototyping or implementation, frameworks should loosen the boundary between both.

Framework maintenance as an important part of design research

HCI is very good at producing frameworks. It is much less good at revisiting them.

Very commonly, after a framework is published, it enters a sort of limbo. Others cite it, use fragments of it, perhaps adapt it informally, but relatively little of that maintenance work comes back into view as a contribution in its own right. We reward the introduction of a new framework much more so than the updating or adapting of an existing one (Fang et al., 2026). This simply will not work for conversational AI design.

Frameworks should be expected to age as technologies advance. This reflects the fast-paced developments occurring across the entire technology design process, from technical constraints to user expectations to even team compositions, and does not point to a weakness or poor design within frameworks themselves.

This experience with adapting and re-using the VSCA framework and toolkit has shown that while frameworks’ core mechanisms and insights can remain relevant (i.e., VSCA still enabled a team to work towards value-sensitivity effectively), they can become much more actionable when they are updated to better fit current contextual realities. In the case of VSCA, this meant adaptations such as adding a step ‘zero’ for defining the application and users in the first place, adding technically oriented materials to scaffold discussions beyond just capabilities, and allowing non-technical participants to envision and shape implementation logic.

None of that invalidates the original framework; it demonstrates why returning to a good framework can be so productive. A design framework ages because the field progressed and systems or participants have changed, and so the work we ask design frameworks to do has changed with them. This is not a sign of its failure, and the HCI community should not pretend otherwise. We should revisit our frameworks as living artefacts and maintain them openly. More papers need to say, “here’s what we changed, and why,” in order for us to reshape the field into one that updates its frameworks and methods as willingly as it updates its tech and tools. If we do that, frameworks stop being static contributions and become something much more useful.

References

Fang, S., Yatani, K. & Hornbæk, K. (2026). What We Talk About When We Talk About Frameworks in HCI. In Proceedings of the 2026 CHI Conference on Human Factors in Computing Systems (CHI ’26), April 13–17, 2026, Barcelona, Spain. ACM, New York, NY, USA, 25 pages. https://doi.org/10.1145/3772318.3791400

Sadek, M., Calvo, R. A., & Mougenot, C. (2025). The Value-Sensitive Conversational Agent Co-Design Framework. International Journal of Human–Computer Interaction, 41(15), 9533–9564. https://doi.org/10.1080/10447318.2024.2426737

Do our design frameworks age? was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

95.7% of a my AI generated code was shipped on a client build, untouched. So why is it still not my default workflow?

A year ago, I watched a Figma Make codebase become the foundation of a real client build.

Not ‘prototype good’. Actually usable. The sort of thing an engineer would have been pleased to receive from a real person. Created entirely by a designer who didn’t write — even review — a single line of it .

That was the moment the penny dropped.

This wasn’t a ‘good enough’ build. We have a high reputation to maintain as a leading AI consultancy, and pushing out sloppy codebases will inevitably tarnish that. The code was still some way off the mark, but it saved a sizeable amount of engineering setup time, which was the first chip at the barrier between design and engineering.

It left me with a question I’ve spent the past year considering. What’s preventing AI assisted (or ‘vibe coding’) from replacing human-led coding?

95.7% untouched

Fast forward to now, and I’ve made significant progress.

To emphasise, I’m a Product Designer, not an engineer. Last month, I built the front end for a client’s internal platform. The real thing, including governance rules in the repo, a running decision log and an automated accessibility report. It landed in GitHub across four branches and a stack of pull requests. The engineering team were deep in infrastructure at the time, and would pick it up a few days after my handover.

Eleven days later, I read their repository to see what had survived. Nobody involved knew I was measuring it, which is the only honest way to run it.

Asking an engineer whether your code was any good is like asking someone whether they enjoyed the dinner you cooked. Reading the git history is like checking the bin.

I’d delivered 93 files of UI code. 89 went into production byte-identical. Total modification to the whole front end: nine lines added, two removed. The engineer’s own commit message was "feat: move frontend files to real webapp". No rebuild to be seen.

Sixteen days after delivery, I asked for their feedback directly, still not knowing I’d measured the code base. That feedback included the line“FE was work done as well as, if not better, as we would have done it.”

Before anyone reads that as permission

There’s a mood in our industry I’d call ‘blind vibes’: generating interfaces and shipping them with no real setup, no checks, and little thought around what happens afterwards. Out of the box Claude Code, Codex, Cursor being used to generate interfaces to be shipped to a client. A number like that 95.7% is exactly what gets quoted in the defence of these workflows.

We made sure to follow a robust workflow.

The Make project was set up alongside an engineer to make sure it followed best practice. I developed a prioritised feature list and user stories. I started with wireframes, explored multiple options per screen rather than taking the first thing that appeared, settled on directions, then rebuilt the low fidelity properly as a high fidelity prototype.

Then an experimental step, I used the Make codebase as a reference for Cursor, not as the thing to ship. Audited it, read it properly, and worked with Cursor to decide screen by screen whether to port it across or refactor code first. To my surprise, a lot of it was strong enough to go over as it was. Cursor refactored the rest.

Slow. Detailed. Considered.

That 95.7% doesn’t measure Figma Make or Cursor. It measures my workflow. Take the tools, skip the workflow, and you’d be very unlikely to produce 89 files an engineer leaves alone. There’s no reliability that the codebase is any good, or would save engineers significant time.

So why isn’t this my standard workflow?

There are four major reasons. Each has something attached that would change my mind.

Nobody has iterated on it

The build was small, and then it stopped. Nobody put a round of design changes through it afterwards. What I have evidence for is the first version reaching production. What happens on the fourth round of changes — whether the design tokens hold, the components stay solid, our accessibility work survives — I don’t know. It’s the question I care most about, but have the least evidence for.

What could change my mind: multiple rounds of real design change through that same build, recording what degrades.

It arrived into an empty room

That team had no front end of their own, just page skeletons. Nothing of mine had to displace anything of theirs, and nobody had to concede that the designer’s version was better than the one they’d started.

What could change my mind: the same measurement somewhere the delivered code has something to compete with.

The variable might be me

I knew that product domain deeply. Every dangerous thing I caught was because I understood what the users needed. The defensible claim isn’t “designers can ship front ends now”. It’s that a designer who already understands the product shipped one an engineering team chose to keep.

What could change my mind: someone without that domain knowledge running the same process and getting the same result.

The process became expensive

Rules, then audit agents to check the rules, then decision logs, then compliance checks running against the compliance checks… The goal was to increase speed and reduce cost, but how well did we achieve that goal?

What could change my mind: measuring the process honestly against the engineering time it replaced.

Reflections, and what you can take away

I’d assumed the comparison was my AI-assisted build against a hand-written front end. The reality was different. My engineer told me what they’d have done instead: the same AI tooling, but without a design perspective.

Both sides are using AI. The variable was having a designer lead the build. The trade-off here is understanding the code well enough to review it.

This article is a case study with measurable outcomes and my honest reflections. It shouldn’t be seen as a ‘how-to’ for repeatable results.

There is little measured evidence in this space and a great deal of assertion, and I only have a number because I went and looked at something I could easily have left alone.

If you’ve handed AI-assisted work to an engineering team, your version of this process is sitting in a repository you (hopefully) already have access to. Diff what you delivered locally against main and count what's left.

That shows you what survived into production. It’s only worth something if your engineers hold a high bar, but if they do, nothing reaches main that they'd be uncomfortable putting their name to. Their reputation is on the line as much as yours. So what they kept, they kept on purpose.

That’s your first honest marker to judge your workflow against.

Cracking the 'design-to-code' workflow, and why I still don't trust it was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

A few years ago, wrapping up a project meant handing over a tidy package: a design system, a brand book with logo variations, a color palette, and a set of static mockups with red arrows pointing to where users should click.

It was safe. It was static. And frankly, it was the standard.

But if you’ve been awake for the last 12 months, you know that the ground is shifting beneath our feet. Every single day, we wake up to a new AI tool that has learned a new skill, often a skill that used to take a human designer hours to master.

I love this. I thrive on it. But it has fundamentally changed how I approach my work.

What Companies Expected vs. What AI Changed

Let’s rewind for a second. The old way of hiring and working was a mess. If you were a designer, you felt the pressure.

I can’t count the number of interviews I sat through where I was rejected because I didn’t have five years of experience in a hyper-specific domain. “You’re great, but you haven’t designed for FDA-regulated clinical trial onboarding software before.” It felt like you had to be a specialist in everything.

On the flip side, companies expected one designer to do it all: UX research, UI design, branding, motion graphics, and maybe even a bit of front-end code. We called them “Unicorns,” and we chased that mythical ideal.

AI has effectively killed the need for the traditional unicorn, but it has birthed something more interesting: The Synthetic Designer.

How My Deliverables Changed

I realized that to stay relevant (and to have fun), I had to stop relying on humans to interpret my static screens and start relying on AI to help execute the vision.

My deliverables have completely transformed.

Example 1: The “It Looked Different in Figma” Problem

Before: I’d hand off a Figma file with 50 static screens. The developer would look at a button that says “Click to Submit” and have to guess the hover state, the error state, and the loading animation. It was a game of telephone that usually ended in a broken UI.

Now: I deliver Interactive Iterations. If I am designing an interface, I don’t just show you a picture of it. I build it. I deliver prototypes with a live code base.

I tell my clients, “Don’t just look at it. Use it.” Because I’ve integrated AI into my workflow, I can spin up multiple interactive iterations in the time it used to take me to draw one static frame. The team doesn’t have to imagine the experience; they can feel it.

Example 2: The “It’s Somewhere in the PDF” Problem

Before: I’d spend weeks writing a 100-page brand guideline. Fonts, colors, spacing. It was a dead tree. Six months later, a new junior designer or an agency would get it wrong, and the brand would drift.

Now: When I revamped a brand identity recently, I still delivered the visual assets, but I added something new: A design.md file and a Prompt Library.

I create the assets you need before you generate anything. I provide a prompt file that can be fed into an image generator or a coding agent. I give the AI the instructions, the boundaries, and the rules.

This makes the work uniform. I’m not just designing for the human team; I’m designing for the tools that will help the human team build the future.

How to Stay Relevant

So, how do you survive in this rapidly changing landscape? You stop being a static worker.

1. Be a Collaborator, Not a Hero
I’ve found that the best way to learn now is to collaborate with people (and their AI agents). I don’t need to know everything about a specific domain anymore. I need to know how to use the tools to gather that expertise. If I don’t know how to code a specific animation, I collaborate with an AI coding assistant to bridge the gap.

2. Be the “Asset Creator”
AI is fantastic at generating stuff. But it needs a skeleton. I create the skeletons. I build the skills and assets you need to put in before generating anything. This is the key to keeping output consistent. Without my input, the AI is just hallucinating. With my input, it’s a production-ready asset.

3. Everything is Possible (If You Try)
Earlier, if I didn’t know a tool, it was a blocker. Now, if I don’t know a tool, I just ask AI how to use it. “Nothing is impossible” sounds like a cliché, but in the design world right now, it’s the literal truth. The barrier to entry for creating high-fidelity, functional products has vanished. All you need is effort.

The Future is Fluid, Design is Changing

We are moving away from a world of “static deliverables” to a world of “dynamic systems.”

I still give my clients the logo and the color palette. But I also give them the instructions to rebuild the brand in a generative world. I give them the design.md so their AI agents can read it and build a website that matches the brand perfectly without me having to manually resize every button.

It’s a terrifying and exciting time to be a designer. If you cling to the static handoff, you’ll get left behind. But if you embrace the chaos, bend with the requirements, and start designing for the machines as well as the humans, you’ll find that the possibilities are limitless.

The days of the static handoff are gone now. The era of the active system is here.

Your Turn

So here’s my question for you: what are you building? I’m open for work and collaborations right now, fully remote and always excited to learn what others are working on. Whether it’s a website redesign, a brand refresh, or something I haven’t even thought of yet, I’d love to hear about it. Drop me a message. Let’s talk.
Portfolio: https://www.yutivora.com/

Is the Static Design Handoff Dead? Here’s What I Deliver Instead. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

There is something rather extraordinary happening in the design industry: capitalism has entered its empathy era, and people laid off on LinkedIn are praising companies as the good guys simply because the layoffs could have been worse.

Apparently, we have forgotten that these companies aren’t necessarily going broke or doing us a favour. They’re still protecting their bottom line. They’re just being a little gentler than others while showing us the door.

And yet, increasingly, we find ourselves admiring some of them because they have done it nicely.

I understand why. Losing your job is difficult enough without having to deal with an organisation that treats you as an administrative inconvenience. A decent severance package, a thoughtful conversation and a little time to figure out what comes next can make a real difference. People who receive those things have every right to appreciate them.

But there’s something uncomfortable about the fact that we have reached a point where this feels extraordinary.

We seem to have reached a point where workers are expected to thank the lord for a merciful beating instead of getting furious as collective society. Apparently, a kinder master is now considered a good employer, one who feels compelled to reassure everyone that the execution was conducted with excellent manners.

The guillotine, presumably, had been recently serviced.

And perhaps the strangest thing is that the people being dismissed sometimes feel compelled to defend the executioner. Not because they’re foolish, or because their feelings aren’t genuine, but because the industry has become so precarious that being treated decently feels like something worth holding on to.

That should tell us something.

The Lord has discovered empathy

Isn’t something almost medieval about this relationship ?

In the twelfth century, Bernart de Ventadorn wrote of a love so absolute that he no longer belonged to himself: “I have never had power over myself, nor have I belonged to myself.” In the language of courtly love, the poet was the vassal and the beloved was his lord. He could be rejected, humiliated and left waiting, yet his devotion remained intact. It was poetry, of course, not an employment contract. But sometimes I wonder whether we have brought that medieval relationship back into the workplace, only replacing the unattainable lady with a corporation, the court with LinkedIn, and the troubadour’s songs of devotion with public thank-you posts written after redundancy

We call it: Master and servant ( It’s a lot! Like life)

Way before the famous pop song from DM, Étienne de La Boétie was already asking an uncomfortable question in his Discourse on Voluntary Servitude: how does power become so deeply embedded in people’s lives that they end up sustaining the very system that subordinates them?

La Boétie was writing about political domination, not employment contracts. But his question has an uncomfortable resonance in a professional culture where workers increasingly participate in the public celebration of the institutions that have just made them redundant.

The master has not even needed to demand gratitude. The servants have started providing it voluntarily.

And perhaps the most curious part is that the ritual is no longer confined to the workplace. It takes place in public, on LinkedIn, in carefully composed paragraphs about leadership, compassion and the importance of doing difficult things in the right way.

The company announces the layoffs. The employees announce how grateful they are for the company’s humanity.

Everyone gets a personal brand moment.

My master I want to make you rich

There is an old Italian popular song whose title seems almost too perfectly suited to this situation: Padrone mio ti voglio arricchire.

A rough English translation of the verses goes:

My master, I want to make you rich,
I’ll work for you like a dog,

And when I make a mistake, just beat me,
I’d rather die than be cast away.

The song’s voice is almost painfully submissive: the worker offers labour, accepts punishment and, above all, begs not to be dismissed. The relationship is expressed in its most grotesque form: the master’s wealth is the servant’s purpose, and the servant’s greatest fear is losing the privilege of serving.

I wouldn’t pretend that a popular song and a modern redundancy programme are the same historical phenomenon. But the irony is difficult to ignore.

And now the master has a People & Culture department, a communications strategy and a beautifully designed PDF explaining that the decision was made with the greatest empathy.

Around the world ( A-rou-nd-the-woo-oorld)

Let’s be clear: layoffs are sometimes unavoidable. Businesses change, markets contract, strategies fail and organisations have to make decisions about costs, it is happening all around the globe. Not every redundancy is evidence of corporate malice, and not every manager involved in a layoff is a villain.

But language matters.

When a company describes redundancies as an exercise in empathy, thoughtfulness and humanity, it is presenting the manner of the decision as part of its moral achievement.

It shifts attention from the fact that people are losing their jobs to the quality of the experience provided by the organisation making that decision. This is a remarkably convenient narrative.

It allows the company to remain the protagonist of its own story: courageous, compassionate, responsible and emotionally intelligent.

The employees become supporting characters in a case study about good leadership.

And the better the severance package, the more convincing the story becomes. That additional support matters, because it can genuinely help people rebuild their lives, but it does not transform a redundancy into a gift.

There is a difference between being treated humanely and being treated generously. There is also a difference between appreciating the people who handled a difficult situation well and celebrating the organisation that created the situation in the first place.

We should be able to hold both thoughts at once.

The empathy economy

Perhaps this is the final achievement of contemporary corporate culture: it has managed to turn the absence of cruelty into a competitive advantage.

The comparison is no longer between a company that lays people off and one that doesn’t. It is between a company that lays people off brutally and one that does so with a decent package, a sympathetic email and a farewell message.

And the second company gets to be the hero.

I don’t want to take away anyone’s gratitude for a decent severance package. If a company has treated people fairly, that deserves to be acknowledged. People who have just lost their jobs do not owe the rest of us a performance of anger, either.

But the design industry has spent years talking about empathy, human-centred design and putting people first. It is a little ironic that, when it comes to the people who actually work in it, we seem to have lowered our expectations so dramatically.

Maybe the problem is not that some companies are being kind during layoffs. They should be. The problem is that we have started treating kindness as evidence that the system itself is kind.

And that is a much more convenient story for the people at the top than for the people being shown the door.

The master has discovered empathy.
The servant has learned to write LinkedIn recommendations.
And the shareholders, as ever, are doing rather well.

References

1. Bernart de Ventadorn, Can vei la lauzeta mover, 12th century. Original Occitan troubadour lyric. See the Rialto database of troubadour poetry: https://trobar.org/
2. Étienne de La Boétie, The Politics of Obedience: The Discourse of Voluntary Servitude, originally written c. 1576. English translation: https://theanarchistlibrary.org/library/etienne-de-la-boetie-the-politics-of-obedience
3. Karl Marx, Capital, Volume I, Chapter 25, “The General Law of Capitalist Accumulation” (1867): https://www.marxists.org/archive/marx/works/1867-c1/ch25.htm
4. George Orwell, Animal Farm (1945). Boxer’s recurring statements, “I will work harder” and “Napoleon is always right”: https://www.orwellfoundation.com/the-orwell-foundation/orwell/books-by-orwell/animal-farm/
5. Giovanni Boccaccio, The Decameron, Fourth Day, First Tale: Tancredi and Ghismunda. English edition: https://www.gutenberg.org/ebooks/23700
6. Popular Italian song, Padrone mio ti voglio arricchire. Lyrics supplied by the author; English translation by the author.

Getting laid off is fine and apparently, we should be grateful now. was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

From the Dialogic Laboratory to the Domestic Sanctuary

In my previous article, Beyond the pixel: Designing the future before coding it, I established a foundational premise of my studio’s practice: I understand computing not as a sequence of two-dimensional screens, but as an active, inhabited habitat. By exploring the Architecture of Invisible Information and Interactivity (AIX) and diegetic prototypes like the iHand operating over the rWWWs (Real World Wide Web Secure) network, we mapped how technology can fold into natural human movement like a biomechanical second skin to interact with the exterior world.

Yet, when that technological dance crosses the threshold of our front door and enters the intimacy of the home, the current paradigm fails spectacularly.

We are experiencing a profound psychosocial dissonance in the domestic sphere. The tech industry has sold us the chimera of the “Smart Home” and the commercial phygital environment under the promise of effortless techno-magic: hyper-connected houses that supposedly “think for us” to free us from daily chores. Empirical reality tells the exact opposite story. Instead of emancipation, we have filled our refuge with digital friction, planned obsolescence, opaque corporate ecosystems that hijack our privacy, and a proliferation of cold screens that colonize our attention.

Before we continue automating the home, we must introduce a reflective pause and redesign it from its anthropological, architectural, and spiritual first principles.

Why Nothing Works: An Anthropological Counter-Briefing of Vertical Living

To diagnose the failure of contemporary home automation, speculative design must lean on materialist anthropology. In his lucid work Why Nothing Works: The Anthropology of Daily Life, American anthropologist Marvin Harris demonstrated that societal innovations and structures do not fail by chance; they collapse when they collide directly with the material, energetic, and biological economy of everyday human life.

If we apply a strategic counter-briefing to the modern home through Harris’s lens, we discover that the Smart Home fails because it attempts to patch an architectural root defect with invasive software: the tyranny of vertical housing.

The great modernist axiom that form follows function has been perverted by urban speculation. Contemporary vertical housing blocks are not designed for the function of dwelling, but for the function of storing labor force and passive consumption units. This vertical stacking completely nullifies the idiosyncrasy of a conscious, creative life. By compressing human beings into standardized, thermally inefficient concrete boxes, we destroy the sacred ecosystem required for total art: the ability to take joy in our daily actions, from reflective study and audiovisual creation to the slow, alchemical act of cooking with real ingredients for our family.

The tech industry attempts to compensate for the hostility of these vertical boxes by saturating them with sensors, “smart” thermostats, and voice assistants. It is an anthropological fallacy: we do not need homes that do things for us, turning us into passive spectators of our own existence; we need habitats that assist our sovereignty to make, create, and dwell with dignity.

Subtractive Architecture and the Vernacular Bone Structure

The home of the future does not need to accumulate more artifacts; it requires subtraction. It needs its bone and muscular structure to assume the thermodynamic and spatial functions that we currently delegate clumsily to machines.

To project forward, we must look back with scientific humility. Pioneering ethnographer Margaret Mead taught us that true human advancement is born from deep listening and the willingness to learn from other cultures and communities that have already solved our contemporary dilemmas. When we cross Mead’s ethnographic gaze with the ethics of William Morris and the Arts and Crafts movement — which championed material honesty and the home as a workshop of artisanal dignity against industrial alienation — we find the answer in vernacular architecture.

For millennia, civilizations developed structures that regulated climate and fostered human cohesion through pure constructive physics, without consuming a single digital watt:

• Ancient Egyptian Dwellings (Thermal Inertia and Passive Convection): Built with Nile mudbrick, they possessed extraordinary thermal mass capable of absorbing scorching daytime heat and releasing it gently during the cold desert night. Through malqaf (north-facing windcatchers) and interior courtyards, they generated continuous natural air conditioning. Today, this bone structure can be updated through 3D printing with local geopolymers and translucent aerogels, allowing the building’s own skin to breathe without artificial HVAC systems.
• First Nations Tipis (Conical Aerodynamics and the Venturi Effect): Far from being a simple tent, the tipi is a high-precision thermodynamic machine. Its tilted cone withstands gusting plains winds, while its interior liner (ozan) and adjustable top flaps apply the Venturi effect to extract smoke and renew air without losing radiant floor heat. Updated today with tensioned mycelium biocomposites, the tipi also offers an invaluable spatial lesson: all family life is articulated in a circle around a central fire.
• Mongolian Yurts (Ger) and Living Spherical Efficiency: The yurt is a marvel of tension and compression engineering: an expandable wooden lattice (khana) crowned by the toono, the zenithal ring through which sunlight enters and the structure breathes. By eliminating the dead corners of orthogonal architecture, heat and acoustics flow unhindered. This is not a theoretical utopia: this exact physical wisdom is tangibly demonstrated today in the community wooden structure featuring a spherical coffered ceiling located at Plaza Santa Ana in Pamplona. Its enveloping geometry proves empirically that when spherical form and the nobility of wood work together, thermal and energetic efficiency is so absolute that conventional heating becomes entirely unnecessary.

In an updated vernacular architecture, the zenithal oculus filters sunlight during the day under the Japanese principle of Komorebi explored in my first article, synchronizing our circadian rhythms. But what happens when night falls and physical architecture must intertwine with the digital ecosystem?

Impact and Commercial Advantage: The convergence between parametric vernacular architecture and subtractive digital design inaugurates the regenerative habitat market. Brands and institutions that integrate passive structural efficiency with invisible interfaces (AIX) will lead the ecological and technological transition, drastically reducing the energy footprint of both servers and domestic climate control.

Diegetic Prototyping II: The iCandle and the Domestic Altar

When the home’s bone structure resolves physical habitability on its own, technology is liberated from banal tasks and can reclaim its true anthropological place: the domestic altar.

Every conscious civilization has structured its house around an altar (a deep wisdom still preserved in traditional Mexican homes). This does not necessarily imply religious dogma — though it fully honors families who practice it — but rather a spiritual altar for the spirit of the house. A home stripped of a spiritual center, a materially “atheistic” house, ultimately denies human transcendence itself.

Originally, that sacred center was the focus (the hearth): the family fire around which the tribe gathered to share warmth, nourishment, and the living word. However, the twentieth century brought a silent and devastating usurpation. As philosopher and essayist Enrique Lynch masterfully analyzes in his book La televisión: El espejo del reino (Television: The Mirror of the Kingdom), the television set colonized the central space of the house, usurping the exact place of the ancient family hearth. Television erected itself as a false altar: a “cold fire” of unidirectional cathode light that, far from summoning internal family dialogue, projects an external “mirror of the kingdom” that hypnotizes, fragments intimacy, and turns inhabitants into passive subjects of the spectacle. Meanwhile, the true brain of the contemporary digital house — the router — was relegated to an unsightly plastic box with blinking LED lights hidden shamefully behind a piece of furniture.

It is time to dethrone the false television mirror and reconcile the spiritual center of the home with the heart of our digital sovereignty. From my speculative divergence laboratories, the iCandle is born.

The iCandle Ecosystem: The Unbreachable Diegetic Router

Against the opacity of current domestic gadgets, I reclaim the etymology of the English word candle, which shares its Indo-European root (cand-, to shine, to glow) with words like incandescent and candid (that which is pure, transparent, honest, and free of malice).

The iCandle is the new brain of the home within the rWWWs (Real World Wide Web Secure) architecture:

• Biomimetic Lattice and Real Fire: Enclosed within a hollow hemispherical structure crafted with the exact same geometric wooden mesh as the home’s coffered ceiling, the iCandle does not simulate a flame through pixels; its core holds real organic wax and true physical fire. It displaces the cold screen to restore thermodynamics, natural scent, and the living presence of the ancestral flame to the domestic altar.
• Synchronized Intimate Holography: Powered by thermoelectric conversion and a biosynthetic base, the heat and light spectrum of the real flame act as a catalyst and physical key to project a serene, high-density holographic interface weaving delicately through the wooden lattice.
• Unbreachable Physico-Chemical Cybersecurity: A live flame is chaotic and unrepeatable in every microsecond. The iCandle uses the real physical entropy of its own fire as a quantum-physical encryption key generator. No external agent can hack or breach the home server because the cryptographic key is the physical flame burning on the family altar itself. Domestic privacy becomes sacred once again.
• Synergy with the iHand and Conscious Demand: The iCandle governs data flows under the principles of Qualitity (the rigor, depth, and entity of the digital object) and Conscious Demand established in my previous article. It remains silent, illuminating family rest or dinner with real fire. Only when a household member approaches with their iHand wristband and declares an active intention does the iCandle deploy its Deep Discursive Dialogue (DCC), transferring encrypted data packets through warm light filaments to prepare for the exterior world or assist in domestic creation.

Impact and Commercial Advantage: The iCandle transforms an invisible, despised technical commodity (the home router and local server) into an object of emotional, aesthetic, and high-security biometric value. For the tech and telecommunications industry, prototyping under this philosophy means leading the Privacy by Design and Calm Technology paradigms, building deep loyalty with users who demand sovereignty over their data and attention.

Designing the Light That Unites Us

The future of habitability and ubiquitous computing does not belong to algorithms that seek to replace us in our kitchens, in our design studios, or in the raising of our children. It belongs to a holistic vision capable of uniting the millennial wisdom of earth and wood with the ethical vanguard of clean code.

By restoring the home’s vernacular structure and placing the iCandle on its central altar, technology ceases to be a cold surveillance device or an alienating mirror, becoming a candid presence that safeguards our creative freedom. Because ultimately, beyond pixels, spatial networks, and data architectures, there is an undeniable anthropological and spiritual truth that sustains every living being: we are united by the light (nos une la luz). And as designers, our highest responsibility is to protect the fire that keeps it burning.

Author’s note: The core concepts, methodologies, and strategic vision presented in this article are my original intellectual property. I utilized AI tools (Google Gemini) strictly as an editorial assistant for translation, structural refinement, and conceptual sparring.

Beyond the Smart Home: Designing the Domestic Sanctuary Before Automating It was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.

“Today a website is valuable because it drives human traffic. Tomorrow it may be valuable because it saves work for AI agents.”

This sentence, deceptively simple, conceals one of the deepest economic transformations the web could undergo in the next decade.

I’m not talking about SEO for ChatGPT. I’m talking about something structurally different: a market for semantic quality, where the value of a piece of content is no longer measured in clicks, sessions, or bounce rates, but in computational efficiency for the AI systems that use it to answer users’ questions.

In this article I want to do three things: formalize this idea with a mathematical model precise enough to be tested, debated, and — if wrong — refuted; address the sharpest theoretical objections head-on; and propose a concrete piece of infrastructure — agentic crawlers and domain benchmark sets — that could make the whole system operational today, with tools that already exist.

The starting point: how web value works today

The current web has a well-defined and fairly straightforward economic logic:

1. A site publishes content.
2. Google indexes and ranks it by relevance to human users.
3. Users click, land on the site, generate traffic.
4. Traffic is monetized through ads, leads, conversions, or subscriptions.

PageRank — at its core — rewards relative popularity: how many authoritative sites link to you? How many people read you? The metric is always human, always tied to the attention of a living reader.

Now imagine a world where most questions are filtered through AI agents before ever reaching a link. This isn’t a distant hypothesis: it’s already the direction of Google AI Overviews, LLM-powered search engines, browser-integrated assistants, and the retrieval APIs used by foundation models.

In that world, the unit of value changes.

It no longer matters how many humans land on your site. What matters is how much your site reduces the computational cost of getting the right answer.

A concrete example before the math

Before diving into formulas, consider this scenario.

An AI agent needs to answer: “What is the precise impact of the new EU banking directive on Tier 1 capital ratios for mid-size lenders?”

Path A: the agent scans 50 loosely worded blog posts, runs multiple clarification passes, and spends 100,000 tokens in reasoning to arrive at a probably-correct answer.

Path B: the agent hits a single well-documented API that exposes the exact formula, edge cases, and regulatory citations as structured JSON. Query resolved in 500 tokens.

The value of that JSON endpoint is not the traffic it generates. It’s the 99,500 tokens it saved the system — plus the reduction in hallucination risk, the avoided legal exposure, and the latency cut. That is the unit of value this model is trying to measure.

Formalizing the intuition: the cost of inference

Given an agent responding to query Q using a set of sources S = {s₁, s₂, …, sₙ}, we define the total inference cost function:

C(Q, S) = α · τ(Q,S) + β · ρ(Q,S) + γ · ε(Q,S) + δ · λ(Q,S)

Where:

Variable Meaning τ(Q, S) Tokens consumed to read, interpret, and synthesize the sources ρ(Q, S) Number of retrieval calls (searches, crawls, tool calls) ε(Q, S) Probability of error or hallucination in the final answer λ(Q, S) Total inference latency α, β, γ, δ Relative weights — not fixed constants, but market-reflective parameters

All terms are normalized to a common unit (equivalent computational cost in USD).

The declining token cost paradox — and why the model survives it

A sharp critic will immediately object: with increasingly specialized models, dedicated hardware, and architectures like Mixture of Experts (MoE), the raw computational cost of tokens is collapsing toward near-zero. If τ becomes trivially cheap, does the whole model break?

No — and here is why. The weights α, β, γ, δ are not constants. They reflect the dominant cost structure of the market at a given moment.

Today, α (token cost) carries real weight. Tomorrow, as inference becomes commoditized, γ — the cost of error, hallucination, and legal liability — becomes the dominant term. A financial services firm using an AI agent that confidently hallucinates regulatory figures faces a compliance nightmare worth orders of magnitude more than any saved compute budget.

The model doesn’t just hold as costs shift — it becomes more interesting. The scarce resource transitions from compute to verified truth. Sources that guarantee accuracy in high-stakes domains (law, medicine, finance, engineering) become structurally more valuable than those that merely save tokens. The incentive to reward semantic quality only strengthens as inference cheapens.

The baseline cost

We define the baseline cost as the cost of answering query Q using only the model’s parametric knowledge, without any retrieval:

C₀(Q) = C(Q, ∅)

If a source doesn’t meaningfully lower C₀(Q) — or raises ε by introducing unreliable information — it contributes negative value.

Marginal Semantic Value (MSV)

The Marginal Semantic Value of source sᵢ with respect to query Q and the current source set S is:

MSV(sᵢ, Q, S) = C(Q, S \ {sᵢ}) − C(Q, S)

How much worse does the answer get if you remove that source from the set? The more it degrades, the more it was contributing.

A high MSV means the site reduced tokens needed, avoided additional retrieval calls, lowered hallucination risk, or reduced legal exposure. A low or negative MSV means it added noise, not signal.

The multiple attribution problem: the Shapley solution

In practice, an answer is almost always the product of multiple combined sources. How do you correctly attribute value when sᵢ, sⱼ, and sₖ all contributed to the same answer?

This is exactly the problem that cooperative game theory solves with the Shapley Value — a mathematically fair framework for distributing value among players in a cooperative game.

For a single query Q over a set of n sources N = {s₁, …, sₙ}, the Shapley attribution for source sᵢ is:

φ(sᵢ, Q) = Σ_{T ⊆ N\{sᵢ}} [ |T|! · (n−|T|−1)! / n! ] · [ C(Q, T) − C(Q, T ∪ {sᵢ}) ]

This computes the average marginal contribution of sᵢ across all possible coalitions, guaranteeing three properties:

• Efficiency: the sum of all Shapley attributions equals total savings versus baseline.
• Symmetry: identical contributions receive identical attribution.
• Monotonicity: a source that increases cost receives no positive attribution.

Exact computation is NP-hard for large sets, but efficient sampling-based estimators — KernelSHAP, Shapley-SVR — are already standard in ML explainability pipelines.

Semantic Retrieval Value (SRV): the core metric

Aggregating over a query distribution D representing the typical traffic in a semantic domain:

SRV(sᵢ, D) = 𝔼_{Q ~ D} [ φ(sᵢ, Q) ]

A high SRV means that source consistently reduces inference cost across its domain. Three properties worth noting:

• Domain-specific: a source can have high SRV in “regulatory compliance” and near-zero SRV in “marketing copy.”
• Temporally unstable: outdated or inaccurate data degrades SRV — the agent uses the source less, or uses it with costly corrective passes.
• Compositional: two complementary sources have a combined SRV greater than the sum of their individual SRVs.

AgentRank: an authority metric for machines

PageRank measures transitive authority through explicit links — a conscious act by a content creator pointing to another. AgentRank is structurally different, and the distinction matters.

In the agent web, there are no explicit links between sources. The combination of sources is decided by the LLM’s retrieval algorithm, not by the content creators. If site sⱼ and site sᵢ are consistently used together, the relationship isn’t directional in the PageRank sense — it emerges from semantic co-occurrence within resolutive coalitions.

The directed edge in the AgentRank graph is not a hyperlink. It is a logical-semantic dependency detected by the model during synthesis: if sᵢ consistently validates, extends, or corrects the output of sⱼ in Shapley coalitions — meaning sⱼ’s Shapley contribution measurably increases when sᵢ is present — then authority flows from the coalition toward sᵢ.

With this clarification, the recursive formula:

AR(sᵢ) = (1−d) / N + d · Σ_{sⱼ ∈ Dep(sᵢ)} [ AR(sⱼ) · φ(sᵢ, Q) / Σ_{sₖ ∈ S} φ(sₖ, Q) ]

Where Dep(sᵢ) is the set of sources whose Shapley contribution measurably increases when sᵢ is present — a dependency relation derived from retrieval logs and coalition analysis, not from explicit linking.

Unlike PageRank:

• It cannot be gamed with artificial backlinks — what counts is measured impact on inference quality.
• It degrades over time if content accuracy drops.
• It is experimentally measurable through controlled retrieval A/B testing.

The economic architecture: the Answer Efficiency Pool

A consortium of LLM providers establishes an Answer Efficiency Pool (AEP): a fund fed by a share of computational cost saved thanks to external sources.

The total pool value in period τ:

AEP(τ) = Σ_{Q ∈ Qτ} [ C₀(Q) − C(Q, S*(Q)) ] · v(Q)

Where v(Q) is the commercial weight of the query — a high-stakes legal or financial query carries higher weight than a generic one — and S*(Q) is the optimal source set actually used.

The royalty for source sᵢ in period τ:

R(sᵢ, τ) = λ · Σ_{Q ∈ Qτ} φ(sᵢ, Q) · v(Q)

Where λ is the monetization rate, negotiated within the consortium. The sum of all royalties equals the pool — guaranteed by the efficiency property of Shapley.

The five pillars for making it work

1. Open measurement standards

If SRV and AgentRank calculations are proprietary to a single vendor, the system becomes a measurement monopoly: the vendor controls both who gets paid and how much. Open standards are necessary — a W3C equivalent for semantic retrieval — with independent audits and open protocols, so sites optimize for genuine quality rather than for one company’s algorithm.

2. Robust, verifiable attribution

Tracking which sources contributed to a final answer, with what weight and in which coalition, is an engineering problem — not a mathematical impossibility. Structured retrieval logs, evidence tracing through attention patterns, and systematic A/B tests on source inclusion and exclusion all make this tractable at scale.

3. Structural anti-gaming — including semantic cartels

If compensation depends on Shapley value within coalitions, a sophisticated adversary will attempt to exploit the mechanism. Beyond simple markup inflation, the most subtle attack is the semantic cartel.

Suppose a publisher controls two apparently independent sites, sA and sB. Instead of publishing complete information on one site, they deliberately split essential data: half on sA, half on sB, engineered so that an agent must query both to avoid hallucinating. Neither site answers the query alone. Together, they maximize their combined MSV — and royalties — at the expense of a third independent site that offered the complete answer in one place.

This is structural fragmentation for economic gain, and the hardest gaming vector to detect. Defenses require dedicated Semantic Cartel Prevention:

• Completeness scoring: a source that consistently requires a specific partner to close the answer is flagged for audit.
• Ownership graph analysis: sources with shared registration or hosting patterns showing suspiciously high mutual dependency trigger automatic review.
• Long temporal windows: artificial dependencies are brittle — they degrade when not actively maintained. Genuine complementarity is structurally stable over time.
• False-positive penalties: if a source is used but increases ε(Q,S), its SRV drops regardless of markup quality.

4. Open/premium equilibrium

Not everything can become paywalled. A mixed model — freely indexable content with baseline SRV, certified premium sources with higher royalties — mirrors freemium structures we already understand, applied to semantic quality rather than to access control.

5. The measurement infrastructure: agentic crawlers and domain benchmarks

This is the piece that could make everything operational — and it is largely buildable today.

The theoretical model works only if SRV can actually be measured, at scale, across the open web. The proposal: a layer of agentic crawlers that do not collect HTML, but instead simulate real agent queries against a site and measure the cost of extracting a correct answer.

A crawler visiting a cardiology site doesn’t index page titles. It asks: “What is the standard warfarin dosage for a 70kg patient with atrial fibrillation and no prior anticoagulation?” — and measures the cost of getting there: tokens consumed, retrieval calls made, ambiguity in the result, hallucination risk. That cost measurement is the site’s SRV on that query.

To do this at scale and make scores comparable across sites and over time, each semantic domain needs a standardized benchmark set: a curated collection of 50–200 questions with verified ground-truth answers, maintained by domain experts and updated periodically.

Think of it as MMLU — the standard LLM knowledge benchmark — but applied to websites rather than models. A cardiology benchmark. A regulatory compliance benchmark. A financial instruments benchmark. Each set probes the domain systematically, covering common queries, edge cases, and ambiguous formulations.

The crawler runs these benchmarks against candidate sites, computes per-domain SRV scores, and publishes the results as a Semantic Quality Index (SQI): a meta-directory that retrieval agents consult before deciding where to search. A pre-screening layer that gives every downstream agent a head start.

The market effect of this infrastructure is significant. If the SQI exists and is used by retrieval agents as a routing signal, publishers have an immediate incentive to optimize for it — exactly as sites optimized for PageRank, but with a metric that genuinely rewards structural content quality rather than link popularity.

The technology to build this exists today. Playwright or Puppeteer for crawling. LangChain or LlamaIndex for simulating agentic queries. RAGAS or DeepEval for measuring faithfulness, answer relevancy, and context precision. The missing piece is not engineering — it is governance: a consortium that defines benchmark sets by domain, maintains ground-truth answer databases, publishes scores, and sets the rules for preventing benchmark overfitting.

Benchmark overfitting is the obvious risk. Sites will optimize for the 200 standard questions without improving quality on the long tail. The mitigation, borrowed from standardized testing: rotate a portion of benchmark questions periodically, keep a set of unpublished “canary” queries that are never disclosed publicly, and weight recent crawl results more heavily than older ones to discourage static optimization.

The deeper governance risk is who writes the questions. A committee that decides how to phrase a benchmark query holds enormous power — framing a question one way rather than another can structurally favor one publisher over a competitor. Centralized, static benchmark management is therefore incompatible with a trustworthy SQI.

The more credible architecture is domain-specific independent commissions — analogous to medical or legal standards bodies — where benchmark sets are authored by rotating panels of domain experts with declared conflicts of interest, reviewed openly, and subject to public challenge periods before adoption. More radically, benchmark questions could be generated synthetically and validated through multi-model cryptographic consensus: a question earns a place in the benchmark only when a quorum of independent models — trained by different organizations, with no shared fine-tuning — agrees on the ground-truth answer and its unambiguity. No single actor controls the question set. The benchmark becomes a protocol, not a product.

What this means for anyone building digital products today

For publishers and media organizations: High-SRV content is precise, structured, and verifiable. It’s not just about “writing well” — it needs to be queryable: schema markup, structured data, traceable citation chains, systematic updates. These are assets worth building now, before the market prices them.

For developers and architects: Declarative APIs, machine-readable formats, LLM-friendly documentation — these are no longer just good engineering practice. They are potential economic assets. How you expose your data today could determine your domain SRV score tomorrow.

For product managers: “Organic traffic” may become an incomplete KPI. The questions to ask today: how structured is our knowledge base? How easily can an agent find the right answer in our content? What is our AgentRank in our semantic domain? Are we optimizing for the SQI benchmark sets that will route agent traffic?

For infrastructure builders: The Semantic Quality Index does not yet exist. Someone will build it. The consortium model — where multiple LLM providers and publishers co-govern the benchmark sets — is the most credible governance structure, analogous to how SSL certificate authorities or domain registrars operate. The window to shape those standards is open now.

The strongest objection to the model

The most serious counterargument is the inverse incentive problem: if large LLM providers control both the query flow and the SRV measurement, they have a rational economic incentive to internalize the value — build high-SRV sources internally and pay nobody. Exactly what Google did progressively with featured snippets, knowledge graphs, and AI Overviews: extract value from publishers without redistributing it.

This risk is real. But there is a structural counter-pressure that doesn’t depend on provider generosity or regulatory intervention: the SLOP problem.

As AI-generated content floods the web — pages optimized for old-style SEO, produced at industrial scale, semantically worthless — the raw open web becomes increasingly toxic for retrieval systems. Crawling it indiscriminately means ingesting noise faster than signal. The computational cost of filtering, deduplicating, and hallucination-checking against a poisoned corpus grows without bound.

In this scenario, providers don’t fund the SQI out of altruism. They fund it because access to a clean, pre-validated index is worth more than the cost of contributing to it. The alternative — unrestricted scraping until antitrust law catches up — becomes technically unsustainable before it becomes legally impossible. The Answer Efficiency Pool emerges not from a values-driven consortium but from a survival calculation: pay into the index, or drown in generated garbage.

This is also why the cold-start problem is less severe than it appears. The first providers to adopt the SQI gain a measurable quality advantage in their retrieval pipelines. That advantage compounds. Laggards eventually face a choice between joining an established standard or building a competing one from scratch — at far greater cost.

The parallel with digital music is instructive: Spotify resisted paying decent royalties for years, then combined pressure from artists, labels, and regulators shifted the equilibrium. It wasn’t spontaneous market evolution — it was negotiation. The same dynamic will play out here. The question isn’t whether negotiation will happen. It is who will be at the table when it does — and whether the technical standards will already exist to make fair measurement possible.

Conclusion: making the web clearer for machines

The final thesis is simple to state, but non-trivial to implement:

Whoever makes the web more legible for machines may, tomorrow, be paid for doing so.

I’m not describing a science fiction future. I’m describing the logical direction of a system where costs are real and measurable, where quality sources demonstrably lower those costs, and where a rational economic incentive exists to compensate that contribution.

The mathematical model proposed here — the cost function C(Q,S), Marginal Semantic Value, Shapley attribution, SRV, AgentRank, and the Answer Efficiency Pool — is an attempt to formalize that direction precisely enough to be falsifiable, debated, and, if correct, implemented.

The agentic crawler infrastructure and domain benchmark sets are not theoretical additions. They are the operational layer that transforms this from an economic model into a deployable system, using tools — Playwright, LlamaIndex, RAGAS — that exist today.

Three blind spots remain open: the shift in dominant cost from compute to verified truth as inference commoditizes; the geometric nature of AgentRank as a dependency graph rather than a citation graph; and the semantic cartel problem as the most sophisticated gaming vector the model must resist.

These aren’t fatal objections. They are the places where the model needs the most work — and therefore the most interesting places to push.

The Semantic Quality Index does not yet exist. The benchmark sets do not yet exist. The consortium governance does not yet exist.

But the question is right. And the tools are already here.

If you found this useful or want to push back on the model, I’m on [LinkedIn]. Builders, researchers, and anyone thinking through this transition — I’d genuinely like to hear what’s missing or what doesn’t hold up.

The Agent Web: An Economic Model for Semantic Quality was originally published in Bootcamp on Medium, where people are continuing the conversation by highlighting and responding to this story.