February 9, 2026

The Real AI Risk Isn't the Robot. It's the Price Drop in tokens.

Most people are scared of the wrong thing.

When the conversation turns to AI danger, it gravitates towards familiar territory: sentient machines, mass job displacement, autonomous weapons, existential risk. These are good narratives. They have clear villains and dramatic stakes. They also largely miss what is actually happening.

The thing worth being concerned about is not what AI can do. It is what happens when running AI costs nearly nothing.

In March 2023, accessing GPT-4 cost $30 per million input tokens and $60 per million output tokens. By mid-2024, GPT-4o Mini had reduced that to $0.15 and $0.60 respectively. DeepSeek R1, released by a Chinese research lab, undercut the entire market at $0.55 per million tokens while delivering near-frontier reasoning capability. According to Epoch AI, achieving GPT-3.5-equivalent performance became 280 times cheaper between November 2022 and October 2024.

Andreessen Horowitz has documented the inference cost decline at approximately 10x per year — faster than Moore's Law and faster than the decline in internet bandwidth costs during the early web era. They called this "LLMflation."

This is not a projected trend. It has already happened. The cost floor has already moved. And the consequences of that move are only beginning to land.

William Stanley Jevons identified this dynamic in 1865 when he noticed that making steam engines more efficient did not reduce coal consumption. It increased it, because cheaper operation made previously uneconomical applications worth running. The same mechanic applies to AI.

Even as per-token costs collapsed, average monthly AI spending across organisations rose 36%, and the share of companies spending more than $100,000 per month on AI doubled. Agentic tasks and multi-step reasoning chains consume upwards of 100 times more tokens than simple queries. The cheaper each token becomes, the more tokens get burned.

This matters because it means the transition is not gradual. It is not a slow substitution of human work by machine work. It is a step change that occurs when the economic friction that previously kept humans in the loop disappears.

The concern is not that AI becomes powerful. The concern is that AI becomes ubiquitous because it becomes free.

Content at industrial scale becomes trivial. When generating a thousand articles, product descriptions, legal summaries, or social media posts costs a fraction of a penny, the economics of every information industry shift. The throttle on volume was always cost. Remove the throttle and volume becomes essentially unlimited.

Automated decision-making stops being a premium product. Hiring screening, loan assessment, medical triage, benefits administration — these processes have kept humans in the loop partly because of genuine regulatory requirements, but also because automation had a cost. As that cost approaches zero, the case for human review weakens not because anyone decided to remove it, but because the economic argument for keeping it evaporates.

Manipulation becomes industrialised. Political influence operations, social engineering, fraud, and targeted disinformation are not new problems. But cost has always been a natural throttle on their scale. A campaign that required a hundred people to run becomes a campaign that requires a budget line and an API key.

Power concentrates at the infrastructure layer. Training a frontier AI model costs hundreds of millions of dollars. Using one costs a fraction of a cent. This creates a specific and underappreciated asymmetry: the ability to build AI consolidates within a small number of well-capitalised organisations, while the ability to deploy AI becomes universal. The few who control the infrastructure determine the rules. The many who consume it do not.

The sci-fi risk narrative requires AI to have agency. To want something. To choose to harm. This is a useful story because it has a clear protagonist and antagonist, and because it suggests that alignment research is the key variable.

The economic risk requires none of that. It does not require AI to be sentient, or to have goals, or to defect from human instructions. It only requires AI to be cheap enough that the organisations and individuals deploying it no longer have a financial reason to include humans in the process.

The robots do not need to decide to take your job. They just need to make doing your job cost a fraction of a cent.

The questions that matter are not "is this AI smarter than me?" They are: what happens to the value of my cognitive output when producing an equivalent output costs nothing? Who controls the infrastructure on which all of this runs? What governance structures exist when the cost of deploying AI at scale drops below the threshold of meaningful decision-making?

OpenAI was reportedly on track to lose $5 billion in 2024. Anthropic expected to be $2.7 billion in the red by 2025. Prices this low are not sustainable without subsidy or consolidation. The current pricing is a land-grab. When consolidation happens and investor pressure for profitability forces a correction, whoever controls the infrastructure at that moment holds the leverage.

That is the risk worth watching. Not whether AI becomes conscious. Whether it becomes cheap enough that no one notices when it replaces the human in the loop, and powerful enough that the people who built it can name their price when the market matures.

February 1, 2026

Alignment Decay: How Teams Quietly Drift Apart Between Kickoff and Launch

Every team knows what misalignment looks like. It is the moment someone presents a feature nobody asked for, or a sprint review reveals that two squads built the same thing differently. That moment is dramatic. It gets a post-mortem. People talk about it.

But misalignment rarely arrives as a single event. It accumulates. Quietly. Over weeks. Between the kickoff where everyone nods in agreement and the launch where everyone realises they were agreeing to different things. That slow, invisible accumulation is what this article names and examines: alignment decay.

Alignment decay is the gradual divergence between a team's shared understanding at the start of a project and each member's operating understanding as the project progresses. It is not a disagreement. Disagreements are visible. Alignment decay is the slow replacement of shared context with individual assumptions, none of which feel like assumptions at the time.

At kickoff, the team occupies a shared mental model. The problem is defined. The scope is agreed. Roles are understood. But from that point forward, every conversation, every design decision, every technical trade-off subtly shifts each person's internal map. Without a mechanism to re-sync those maps, the team drifts. Not away from the goal, but away from each other's version of the goal.

Gallup's research shows that only 46% of employees clearly know what is expected of them at work, a figure that has dropped 10 percentage points since 2020. That is not a failure of kickoffs. It is a failure of maintenance.

One reason alignment decay goes undetected is that leaders and teams have fundamentally different views of how aligned they are. In 2024, 44% of leaders believed their employees were entirely aligned with organisational goals. Only 14% of employees agreed. That 30-point gap is not a communication problem. It is an observability problem.

Leaders see alignment through the lens of what was communicated. Teams experience alignment through the lens of what was understood, and those are different things.

Alignment decay follows a predictable pattern. In weeks one and two, the team operates from the kickoff's shared context. By weeks three and four, small interpretation differences emerge. A scope question gets answered in a Slack thread that three people miss. A design review surfaces a direction nobody explicitly agreed to, but nobody explicitly objects to either.

By the midpoint of a project, the accumulated drift becomes structural. Teams are no longer making decisions from the same base. They are making decisions from their own evolved understanding of the project, which has been shaped by dozens of small, undocumented adjustments.

The final phase is discovery, which usually arrives too late. Integration testing, stakeholder reviews, or launch preparation reveals that what each person built is technically correct but collectively incoherent. The project is not broken. It is fragmented.

McKinsey's research shows that companies whose top executive teams are aligned are almost twice as likely to achieve above-median financial performance. Enterprises with strong alignment deliver three times the shareholder returns of those with weaker execution.

Gallup's 2025 global workplace report quantifies the broader cost: global employee engagement fell to 21% in 2024, with an estimated $438 billion in lost productivity. When alignment decays, expectations become ambiguous by default.

The first step to addressing alignment decay is accepting that kickoffs do not create durable alignment. They create a snapshot. That snapshot has a half-life, and the half-life is shorter than most teams assume.

Three specific practices reduce alignment decay. First, limit active goals to three to five per team per cycle. Second, make assumptions explicit. Regular "assumption audits," where team members articulate what they believe is true about the project's direction, surface divergence before it compounds. Third, measure alignment directly. Ask team members independently what the project's top priority is. If the answers diverge, that is alignment decay made visible.

Alignment decay is not a failure of intention. Every team that kicks off a project intends to stay aligned. The decay happens not because people stop caring, but because the mechanisms that maintained alignment at the start naturally erode as a project progresses. The teams that ship well are not the ones that aligned once. They are the ones that realigned continuously.

February 26, 2026

Why the Lone Designer on a Cross-Functional Team Always Burns Out First

There is a kind of burnout that does not come with a dramatic exit. It does not surface in a meeting or a performance review. It builds slowly, in the space between what the role was supposed to be and what it has quietly become.

The lone designer on a cross-functional team knows this pattern well.

They joined to do meaningful product work. Within a few months, they are running every piece of design work for a squad of eight to fifteen engineers. They are the only person asking user questions, the only one thinking about interaction patterns, the only one pushing back when the product manager describes a feature that would confuse the people who will actually use it. They are doing everything because there is no one else to do it.

This is not an accident. It is a structural outcome that organisations have been building toward for years.

Nielsen Norman Group's staffing research puts the typical researcher-to-designer-to-developer ratio at 1:5:50. In squad-based organisations, the ratio often looks worse in practice: one designer embedded across a product team of eight to twelve engineers, with no dedicated researcher and no design lead with actual bandwidth to support them.

Peter Merholz, author of "Org Design for Design Orgs," has documented the consequences of this model in detail. When a designer is embedded alone into a cross-functional squad, organisations are asking a single person to deliver across an unrealistic range of capabilities: interaction design, visual design, content, user research, strategy, facilitation, stakeholder communication, and often, production-level execution at the same time.

Senior designers end up doing work far below their level because no one else is available to do it. Junior designers, without mentorship or peers, function effectively as production artists executing a product manager's specifications.

The pipeline collapses. Senior designers burn out and leave. Junior designers never develop. And the organisation keeps hiring for the mythical unicorn designer who can do it all, alone, indefinitely.

Cross-functional teams are optimised for engineering throughput. Sprints are set, tickets are written, and velocity is measured in shipped features. Design is expected to slot in around this cadence, delivering ahead of the engineering queue while also attending every planning session, every standup, and every stakeholder review.

The designer is, by default, the only person in the room who represents user thinking. That is not a small job. But because it has no equivalent in the engineering world, it is often invisible. There is no sprint point for "challenged a feature direction that would have created a confusing flow." There is no metric for the bad path that did not get built.

Memorisely's Burnout Curve analysis captures what happens next. After layoffs and team restructures, senior designers are left to cover every gap: research, strategy, prototyping, visual delivery, facilitation, mentoring, and sometimes even writing production copy or contributing to code. The breadth of responsibility does not plateau. It grows as the team contracts.

Gallup research puts 77% of employees at elevated burnout risk when they feel isolated. Being the only person in your discipline on a team is a structural form of isolation. There is no peer to pressure-test a decision with. No colleague who understands the trade-offs you navigated last week. No one who notices when the quality of your work is starting to slip because you are running at capacity and have been for months.

The most common mistake organisations make with lone designers is mistaking sustained output for sustainable capacity.

A designer who is producing work week after week looks fine from the outside. Tickets are being closed. Designs are being shipped. The machine is running. What is not visible is the cost of that output: the strategic work being deferred, the research that is not happening, the design debt accumulating because there is no time to revisit anything that shipped six months ago.

By the time burnout becomes visible, the designer has already decided to leave. The organisation then spends three to six months' salary replacing them, drops the problem back into the same structural conditions, and wonders why the new hire starts showing the same signs within a year.

This is a systemic problem, but it lands on individuals. If you are a lone designer on a cross-functional team, the most important thing you can do is make your capacity visible before it runs out.

Document the scope of what you are doing, not just the deliverables but the decisions, the unplanned requests, the work that never makes it into a ticket. Make this visible to your manager regularly. Not as a complaint, but as data. Organisations respond to data.

Set explicit boundaries around research and strategy time. If every hour is reactive, you are functioning as a production resource, not a designer. Those hours need to be scheduled and protected the same way engineering sprint capacity is.

Find external community. The isolation of being the only designer on a team is real. Design communities, peer groups, and mentorship networks do not fix the structural problem, but they close the peer gap enough to protect your thinking and your sanity.

Be honest with yourself about the trajectory. If the scope keeps expanding and the support does not, the situation is not going to improve on its own. That is not pessimism. It is pattern recognition.

None of this is solved by better self-care. The answer is not yoga or time management. It is organisational design.

Merholz argues that the team, not the individual designer, is the atomic unit of a design organisation. Designers need peers, mentors, craft community, and a shared identity beyond the squad they sit in. The embedded model has real advantages for collaboration and shipping velocity. But without a design discipline structure that supports people inside it, the model consumes its own practitioners.

The lone designer always burns out first because the conditions produce exactly that outcome. Until organisations redesign those conditions, the pattern will keep repeating.

January 10, 2026

The New UX/UI Era: Design Engineers

As we write this article, our team is in full swing redesigning our application, and one thing that came to mind from our previous MVP. We were focused solely on the old way of working and niched ourselves down to a way of working which we are now seeeing is becoming more and more obselete as each day goes. The role of UX & UI designers has changed, and we're hearing more about designers being involved in the development process than ever before.

Back in the day, a designer would also be involved in some form of coding or actually do it themselves. Those days were the Unicorn days, when employers hired designers who could take their designs to code, and they were better off for it, as the designers paid a lot of attention to the minor details that developers never paid much attention to. Then we moved into an era of specialisation, where designers focused solely on the design part. Yes, they would know some form of coding. Still, it wasn't necessary as employers were looking for people to specialise in a particular area so that other team members could focus on another speciality. Fast forward to today, and now the time of the unicorn has come back again, but this time it is with the help of AI. With so many tools out there that let designers turn designs into code in a short time, we are seeing that designers are being asked whether they can also code the designs. This offers many opportunities to people who have never done it before, but unlike the unicorn, where you had to have some knowledge of code, now you need to be able to write a prompt, but write it well. The quality in your output is how clear and concise your context is in your prompt, and not so much in the technical knowledge (though it does help when you get stuck in a rut with vibe coding tools). Still, the time to take something to production is getting shorter, in terms of the effort, time, and resources needed. This is where the Design Engineer position has come into full force, giving designers the chance to take their designs to code without needing another team or multiple alignment meetings to get them right.

We looked at this in detail when we revised our MVP because the old way of working in Figma and handing over designs is slowly becoming outdated, time-consuming and prone to multiple errors and rework. As companies shift ideas about where to cut resources and use as much agentic AI as possible, I think designers can still keep their jobs. The uptake is massive at the moment, with more and more designers moving to vibe-coding platforms and skipping the design-in-Figma process altogether. There will still be times when designers work in Figma. Still, the doors are opening up more and more, with a lot of work moving towards prompting, and designers are another area moving towards that space very fast, as development has done.

We think that with these new ways of working, workflows will change in organisations dramatically and will see a shift in ownership of each part of the digital product, which is what designers have always strived for. The question is, are designers now ready to move and shift towards this new role, or do they want to stay comfortable in the place where they know best? Designing on a digital canvas has been around since the Photoshop years, and it is still tedious to be a full AI designer. However, the question still boils down to the design team having to learn another skill set to keep alive in this ever-changing career.