rarouš.w3b

untitled

2026-06-21T18:45:46Z

Moving beyond hunch and silencing the sceptics. Over the years, Conway’s Law has resurfaced as a guiding principle to organise teams. Yet, many people still hesitate to accept the idea. Ultimately, it remains a hypothesis. Melvin Conway did not provide any proof when publishing the thesis. However, in the meantime, decades later, a good deal of academic research supports the thesis. Ultimately, Harvard and MIT researchers provided robust empirical validation for the hypothesis across the software industry, further confirmed by the CHAOS Report from the Standish Group, reinforcing The Mirroring Principle as an undeniable organisational reality.

Henderson and Clark observed in 1990 that established firms are unable to adopt architectural innovation because the architectural knowledge is embedded in the communication structures of the organisation, preventing them from adopting new designs.

We show that architectural innovations destroy the usefulness of the architectural knowledge of established firms, and that since architectural knowledge tends to become embedded in the structure and information-processing procedures of established organizations, this destruction is difficult for firms to recognize and hard to correct. Architectural innovation therefore presents established organizations with subtle challenges that may have significant competitive implications.

– Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms, Henderson and Clark, 1990

“Architectural innovation” is defined as innovations that change the way product components are linked together, while leaving the core design concepts — and thus the basic knowledge underlying the components — untouched. That does not mean that components remain untouched. Often, architectural innovation is triggered by a change in a component that triggers new interactions and connections with other components.

The study’s outcome is based on the analysis of 20 years of data (1962-1986) from the photolithographic alignment equipment industry, where four organisations subsequently took over market leadership because a competitor uncovered an architectural innovation that the previous leader was unable to detect due to its organisational structure.

There has been growing evidence of numerous technical innovations that involved apparent modest changes to existing technology, but that had dramatic competitive consequences. In the mid-1950s, RCA developed a prototype for a portable radio receiver. It utilised technology that RCA mastered well. Yet, they did not pursue the idea. Until Sony, a small, relatively new company, entered the US market with portable radio receivers. RCA remained a follower. The irony was that Sony produced radios during many years using RCA’s licensed technology. The case of Xerox, in the mid-1970s, although the inventor of the plain-paper copier, was, during eight years of strategic errors, unable to compete with competitors offering smaller, more reliable copiers. Xerox lost half of the market. For a more recent example, we look at the German car industry, which had trouble marketing electric cars until Tesla, and later the Chinese car manufacturers took over the market. Meanwhile, Audi closes its Belgian factory that produces the expensive electric SUV because of a market mismatch.

This inability to adopt architectural innovation happens because an organisation organises itself around the product’s key components that make up the “dominant design”. The “dominant design” is characterised by a general acceptance of a particular product architecture. It incorporates a range of basic design choices that are not revisited — think car platforms, or in software, a CRUD design. It results in communication channels between the design teams that reflect the organisation’s knowledge about the critical interactions between these components. Thus, an organisation’s communication channels embody the organisation’s architectural knowledge that is critical to effective design. From this moment on, organisations incline to focus only on “incremental innovation”, tending to reinforce the competitive positions of established firms as it builds on their core competencies.

As such, the architectural knowledge is a mirror of the communication structures organised around the product being designed. Somehow, this is the knowledge parallel of Conway’s thesis “[Any] organisation which designs systems is constrained to produce designs which are copies of the communication structures of the organisation”. If communication structures dictate design (Conway, 1968), they also dictate what an organisation is capable of knowing (Henderson and Clark, 1990).

Henderson and Clark establish that, given how knowledge is organised in firms, learning about changes in the product architecture is unlikely to happen. It requires explicit management, or even a different organisation. To counter this, the authors suggest cross-functional teams as a possible response to the danger of architectural knowledge becoming embedded within tacit communication lines.

Recently, I was front-seat observing an organisation unable to run only a simple experiment, which would let them eventually discover a potential innovation, merely because of the structures in place.

Because the communication channels are “frozen” around the old product architecture, the knowledge is also frozen; the organisation cannot distinguish or adjust to a possible new architecture reality, or even conceive a new design reality. This is Conway’s Law working back over time (more on this in Dynamics: Conway’s Time Component).

The Aircraft Engine/Automotive Validations (2004, 2007)

In 2004, Sosa et al. published a study that investigated the design process of a commercial aircraft jet engine, the PW4098, at Pratt & Whitney. They studied how design interfaces in the product architecture map onto communication patterns within the development organisation. More specifically, they explored whether organisational problems exist at the boundaries of the components inside the jet engine, i.e. whether a misalignment exists between the design team boundaries and system component interfaces.

According to Henderson and Clarke, architectural knowledge is embedded in the communication structures of organisations; therefore, organisations need to understand how they manage embedded knowledge. This is especially relevant when designing new products. In this context, system design interfaces are the primary sources of team interdependence, or at least, they should be. Meaning, when a specific team designs their own component with an interface to a neighboring component, there should be a corresponding technical interaction between the two respective teams. These are the expected cases. On the other hand, unmatched design interfaces and unmatched team interactions are unexpected. As it seems, these cases were largely ignored in previous research.

However, we believe that considering these cases is important because their existence would indicate that not all known product-related interdependences are addressed by direct technical communication, and that technical communication (where not expected) may uncover undocumented product-related interdependences.

– The Misalignment of Product Architecture and Organizational Structure in Complex Product Development, Sosa et al, 2004

Finally, the study concludes that …

… we provide empirical evidence that product ambiguity exists, and it is more likely to be present across organizational and system boundaries

– The Misalignment of Product Architecture and Organizational Structure in Complex Product Development, Sosa et al, 2004

Meaning, that there is a great likelihood that some of the system component interfaces are not covered by team interactions, which can lead to major setbacks involving significant rework that can be extremely costly. The paper, exactly, refers to two major setbacks during the design of that specific jet engine.

What they are essentially saying here is: If there is a misalignment between the organisation and the product architecture, there will be problems.

In 2007, Gokpinar et al. conducted a study examining the design of cars in the automotive industry.

[…] a key challenge for product development organizations is matching the organization to the product being developed. This involves two fundamental problems: (1) How to assign people to the parts and subsystems that make up the product, and (2) How to ensure that people communicate/collaborate effectively in the performance of design tasks.

– The Impact of Misalignment of Organization Structure and Product Architecture on Quality in Complex Product Development, Gokpinar et al, 2007

The research defined a new metric coordination deficit, which quantifies mismatches between product architecture and organisation structure, and investigated the effect of coordination deficit on product quality.

They concluded that mismatches between product architecture and organisational structure are positively associated with quality problems.

Our results suggest that misalignment of the design organization with the product architecture negatively affects product quality”

– The Impact of Misalignment of Organization Structure and Product Architecture on Quality in Complex Product Development, Gokpinar et al, 2007

Once more, if there is a misalignment between organisation and product architecture, there will be problems.

The Micro Software Validation (2006)

In 2006, Cataldo et al. investigated the consequences of congruence on the speed and efficiency of software development work inside a single software project. They investigated the impact of misalignment.

This is particularly important in product development organizations which organize themselves around their products’ architectures because the main components of their products define the organization’s key sub-tasks.

– Identification of Coordination Requirements: Implications for the Design of Collaboration and Awareness Tools, Cataldo et al, 2006

This matters because, as architectural knowledge is embedded in the communication structures of organisations (Henderson and Clark, 1990), any minor changes to the product architecture can disrupt the organisation’s ability to coordinate effectively.

Ultimately, Cataldo et al. found that tasks were completed more rapidly when the patterns of communication between team members were congruent with the patterns of interdependency between components (more on congruence in Mechanics: The Mathematical & Geometrical Shades).

Congruence between coordination requirements and coordination activities shortened development time.

– Identification of Coordination Requirements: Implications for the Design of Collaboration and Awareness Tools, Cataldo et al, 2006

Fundamentally, the research indicates, if teams are aligned with the components they work on, teams are more efficient.

The Macro Software Validation (2012)

In 2012, we had the first empirical evidence for the software industry provided by the research paper Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis from Baldwin et al.

One of their findings was: software products tend to mirror the structure of the organisation in which they are developed.

We find strong evidence to support the hypothesis that a product’s architecture tends to mirror the structure of the organization in which it is developed.

– Exploring the Duality between Product and Organizational Architectures: A Test of the “Mirroring” Hypothesis, Baldwin, MacCormack and Rusnak, 2012

Source: Sketchplanations https://sketchplanations.com/conways-law

To validate this hypothesis, they compared open-source with closed-source software. Based on the idea that the open-source communities are loosely coupled organisations by design because contributors have diverse goals, belong to different organisations, work in different geographical locations and time zones, and have no formal authority to guide development activities. Whereas closed-source organisations are more tightly-coupled, as they consist of smaller, co-located teams that share common goals, and are dedicated full-time to products and have formal decision-making authority to guide development.

The study’s approach focused on comparing the architectures of open-source and closed-source software products that have similar functions and are of a similar size. They identified five software categories: financial management, word processing, spreadsheets, operating systems and databases. For each category, they selected an open-source and a closed-source software product.

Because commercial firms are somehow reluctant to share their code base, especially for research comparing with “free” equivalents, researchers did not always have a closed-source codebase at their disposal. When commercial options were unavailable, they turned to formerly closed-source products that had been open-sourced. In those instances, they analysed the first open-source version.

So they ended up comparing:

For financial management: GnuCash vs MyBooks
For word processing: Abiword vs StarWriter
For spreadsheets: Gnumeric vs StarCalc
For operating systems: Linux vs Solaris
For databases: MySQL vs Berkeley DB

The paper primarily explores whether organisations with distinctly different forms develop products with distinctly different architectures.

The outcome of the study was that loosely-coupled organisations, such as open-source, tend to develop products with a more modular architecture than tightly-coupled organisations such as commercial firms. This confirms Parnas’ information hiding concept (Parnas 1972), which allows individual, isolated contributors to work independently. It also reaffirms Henderson and Clark’s observation. Loosely coupled, open-source organisations prevent architectural knowledge from becoming a central, siloed trap. They adopt cross-functional, loosely coupled teams to democratise knowledge. Tightly-coupled organisations, on the other hand, stumble when faced with innovations, because knowledge is tightly frozen, siloed, in the structures of the organisation.

The Industry Reality Check (1995-2020)

We know why projects fail, we know how to prevent their failure – so why do they still fail?

– Cobb’s Paradox, Martin Cobb, CIO for the Secretariat of Treasury Board of Canada, CHAOS University, 1995, published in Unfinished Voyages I, Standish Group, 1995

When organisations keep treating software products as mere, rigid projects, the resulting architecture and outcomes for users will be notably poor, leading to surprising failures.

From 1994 until 2020, the Standish Group published the CHAOS Report, a study on the success, failure, and challenge rates of IT projects.

Year	Success	Challenged	Cancelled
1994	16%	53%	31%
2000	28%	49%	23%
2002	34%	51%	15%
2004	29%	53%	18%
2006	35%	46%	19%
2008	32%	44%	24%
2011	39%	39%	22%
2012	37%	46%	17%
2013	41%	40%	19%
2014	36%	47%	17%
2015	36%	45%	19%
2020	31%	50%	19%

– source: CHAOS Reports 1995, 2009, 2015, 2020, Standish Group.

Although this may look baffling at first, this stagnation blindsides no experienced practitioners. The numbers reveal a flatline trend. Despite agile and DevOps, the success rate is capped at approximately 30%.

Till 2015, the Standish Group focused mainly on classic project management requirements to measure success, such as well-defined upfront requirements, proper planning, skilled project managers, as well as user involvement and project sponsor. Success was defined in classic PMI terms, the Iron Triangle, i.e. on time, on budget, with all features as initially specified. Then, in 2015, a first significant shift happened. The success resolution definition changed. It was still on time and on budget, however, with satisfactory results. All requirements no longer have to be implemented, since data shows that some projects meet the Iron Triangle yet do not return value. In the end, satisfaction and value are greater when fewer features are delivered, but meeting obvious user needs. This is aligned with Lean principles, as well as another Standish Group study revealing that 64% of delivered features are rarely used. Later confirmed by the 2019 Pendo Feature Adoption Study, revealing 80% of features see low to zero adoption.

By 2020, the Standish Group had pivoted and reported an astonishing outcome that contradicts their early recommendations. Stop treating software products as a project because, by definition, projects have a start and an end, but products do not. They explicitly stated that project managers harm software products and increase the failure rate. Specifically, the report demonstrates that project managers often generate more paperwork, resulting in slower decision-making that inevitably slows down feedback. While, once more, not surprising for experienced practitioners — it was already established long before, and brought to the public in 2017 with the #NoProjects movement — the Standish Group brought it to the masses.

Ultimately, the Standish Group concluded that project success is defined by Good Sponsor, Good Team, Good Place, and Short Decision Latency. To a large extent, this aligns with the 2001 findings from the book Good to Great. Organisations become great when they have Level 5 Leadership (Good Sponsor) to build enduring greatness through a paradoxical blend of personal humility and professional will. They focus on First Who … Then What (Good Team), first securing the right people before figuring out where to drive it, before vision, before strategy, before tactics, before organisational structure, before technology. Lastly, they Confront the Brutal Facts of Reality (Good Place), by fostering a climate where the truth is heard.

These crucial prerequisites enable Short Decision Latency, allowing information to circulate rapidly. However, low decision latency is entirely dependent on communication paths. Since Conway’s Law dictates that systems reflect the organisation’s communication structures, high-latency organisations stuck in silos are unable to produce high-velocity, decoupled system designs. This architectural congestion hampers communication and impedes overall success.

Ultimately, the CHAOS Report recommends moving away from “projects” and adopting Infinite Flow, which Lean has been promoting since the 1980’s. Somehow, this is the business world finally accepting what Baldwin et al. proved in 2012: tightly coupled organisations produce tightly coupled system architectures that work against flow, while loosely-coupled organisations thrive because they produce loosely coupled system architectures that enable flow, short time to markets, and consequently accelerated feedback to meet user expectations better. The 2020 CHAOS Report Good Place — where truth is heard to reduce Decision Latency — is exactly the type of environment needed to break the “frozen”, siloed, tacit communication lines Henderson and Clark blamed for corporate blindness.

Conclusion

To conclude, the tech industry spent decades trying to fix management processes, only to realise they were fighting a losing battle against the structural gravity of Conway’s Law and its implications on innovation and market leadership. Mediocrity is the default. Success is optional. Just saying …

The Series: Navigating the Shades

Beyond the Shades of Conway’s Law series:

Foundations: The Origin & The Mirroring Principle - How the worlds of organisation and product design observed the same thesis independently.
Validation: The Research & Reality Check - Moving beyond the “hunch”, how researchers proved the Law in different industries, but especially in software.
Mechanics: The Mathematical & Geometrical Shades - The geometry of design: from mathematical isomorphism, homomorphism, congruence to compatibility.
Strategy: Reversing the Law - How the system ultimately forces the organisation to change versus deliberately changing the organisation.
Scale: Conway’s Corollary - The required organisational flexibility.
Dynamics: Conway’s Time Component - The “Engineer Half Life” and why architecture is “sticky” long after teams change.
Conclusion: The Different Lenses - A concluding look at how we perceive organisations and their systems.

Bibliography

How Do Committees Invent?, Melvin Conway, 1968
On the Criteria To Be Used in Decomposing Systems into Modules, Parnas, 1972
Architectural Innovation: The Reconfiguration of Existing Product Technologies and the Failure of Established Firms, Henderson and Clark, 1990
CHAOS Report 1995, Standish Group, 1995
Unfinished Voyages I, Standish Group, 1995
Good to Great, Jim Collins, 2001
The Misalignment of Product Architecture and Organizational Structure in Complex Product Development, Sosa et al, 2004
Identification of Coordination Requirements: Implications for the Design of Collaboration and Awareness Tools, Cataldo 2006
The Impact of Misalignment of Organization Structure and Product Architecture on Quality in Complex Product Development, Gokpinar et al, 2007
CHAOS Report 2009, Standish Group, 2009
Exploring the Duality between Product and Organizational Architecture: A Test of the “Mirroring” Hypothesis, Baldwin, MacCormack, Rusnak, 2012
CHAOS Report 2015, Standish Group, 2015
Standish Group 2015 Chaos Report - Q&A with Jennifer Lynch, InnoQ, 2015
Are 64% of Features Really Rarely or Never Used?, Mike Cohn, 2016
The 2019 Feature Adoption Report, Pendo, 2019
Chaos Report — why this study about IT project management is so unique about the CHAOS Report 2020, Radek, The Story, 2024

untitled

2026-06-14T16:10:31Z

The Plan

In the beginning was the Plan.

And then came the Assumptions.

And the Assumptions were without form.

And darkness was upon the face of the Workers.

And they spoke among themselves, saying, "It is a crock of shit, and it stinketh."

And the workers went unto their Supervisors and said, "It is a pail of dung, and none may abide the odour thereof."

And the Supervisors went unto their Managers, saying, "It is a container of excrement, and it is very strong, such that none may abide by it."

And the Managers went unto their Directors, saying, "It is a vessel of fertiliser, and none may abide its strength."

And the Directors spoke amongst themselves, saying one to another, "It contains that which aids plant growth, and it is very strong."

And the Directors then went onto the Vice Presidents, saying unto them, "It promotes growth and is very powerful."

And the Vice Presidents went unto the President, saying unto him, "This new plan will actively promote the growth and vigour of the company; with powerful effects."

And the President looked upon the Plan, and saw that it was good.

And the Plan became Policy.

This is How Shit Happens.

→ Check out more Funny Shit

untitled

2026-06-14T06:26:18Z

Think about the last time you tracked your progress on a personal goal. Maybe you were trying to exercise more frequently, be more patient with a spouse or partner, or learn a new skill. Chances are, you had a rough sense of how it was going. And chances are that sense was more optimistic than the evidence warranted.

This is not a character flaw. It is one of the most reliable findings in behavioral science: We are systematically poor judges of our own progress, and during periods of active change, we tend to get worse.

One reason is what psychologists Terence Mitchell and Leigh Thompson at the University of Washington termed rosy retrospection. This is our consistent tendency to remember past experiences more favorably than we rated them in the moment. When we look back over a month of trying to exercise more or sleep differently, our memory selectively surfaces the days we succeeded. The days we failed are there, but they are not as memorable. We feel we’ve been doing better than we really have.

A second explanation is subtler. Motivation isn’t a fixed state; it shifts gradually, often well before behavior changes in any visible way. The enthusiasm that felt solid in January has usually started to erode by March. But because the erosion is incremental, we rarely catch it in real time. We trust that how we feel today is roughly how we’ve been feeling all along. It almost never is.

Together, these two patterns create a specific failure mode: We assume the feedback loop is running when it isn’t. We trust that because we know our own goals and intentions, we know how we’re actually doing. But intention and behavior are not the same thing. How we feel about a change is not the same as how we’re enacting it. And until we close that gap with something more rigorous than a gut check, we’re optimizing for a version of our progress that may not exist.

In researching what separates change successes from failures at organizations for my book, my coauthors and I found that leaders designing change were consistently more confident about employee progress on change than the employees’ actual behavior or stated experience supported. They trusted their read on the room. The data, when they gathered it, told a different story. The wider the gap, the more likely the change failure.

The same gap operates in personal change. And the same remedy applies: Use measurement, not instinct.

This doesn’t require an elaborate system. Research by James Pennebaker at the University of Texas at Austin shows that the act of writing specifically about your experience—not vague journaling, but naming exactly what you did, how it felt, and where the friction was—produces measurable improvements in self-understanding and in the likelihood of follow-through. Writing forces the brain to translate impression into information. The gap between what you felt and what actually happened becomes clearer.

Social accountability produces a related effect. A study by psychologist Gail Matthews at Dominican University found that people who wrote down their goals and reported progress to a friend were 42 percent more likely to achieve those goals than people who kept them private. Part of what accountability does is discipline the story you tell yourself. You can’t smooth over the gaps as easily when someone else is watching for them.

Both interventions do the same thing: They replace vague impressions with actual information. When people begin gathering that information honestly, they usually discover not only the gaps in their efforts, but also the progress they had stopped noticing.

Teresa Amabile, a psychologist at Harvard Business School, spent years studying what helps people stay motivated during sustained effort. Her research, drawn from the daily diaries of 238 professionals tracked over several months, produced a counterintuitive finding: The single biggest day-to-day motivator wasn’t recognition from a manager or a meaningful reward. It was the perception of making progress on work that mattered. Small wins, when noticed specifically, produced outsized improvements in engagement and follow-through. The operative word is “noticed.” Progress that goes unobserved doesn’t produce the same effect. It needs to be named to become fuel.

This is what honest self-assessment makes possible. When you journal about your week in specific detail, you often discover you accomplished much less than your vague, optimistic impression suggested—and you'll have a record you can point to as concrete evidence. That specificity matters more than it might seem. Ayelet Fishbach at the University of Chicago Booth School of Business has shown across repeated experiments that concrete progress feedback strengthens goal commitment more than encouragement does. What keeps people going isn’t being told they’re doing well. It’s seeing, with some precision, that they truly are.

Motivation Essential Reads

The story you’re telling yourself about your progress probably has some blind spots. But it may also be overlooking real growth that felt too small or too ordinary to count. Learning to see your progress more clearly, without judgment, isn’t self-punishment. It’s an invaluable form of self-support.

untitled

2026-06-11T19:21:22Z

Chances are you used an AI tool before 9 a.m. today. Chances are most of your users didn't.

It's a simple contrast, but Debbie McMahon, VP of Product at Loveholidays, built an entire MXP London session around it and what it means for every product decision. She called it the AI adoption gap, and she was refreshingly clear-eyed about the ways it had distorted her own judgment.

The AI adoption gap and the 0.04%

An infographic Debbie shared on stage breaks the world's relationship with AI into four tiers:

84% of people have never used AI

16% have tried a free chatbot

0.3% pay for AI

0.04% are actively building with it

That last group is the one that fills rooms like MXP London. And Debbie's point is that this creates a fundamental disconnect. The people designing AI-powered products are a statistical anomaly relative to the people they're designing for.

She made that concrete with a story about her friend Agnes. Agnes is a primary school teacher who spends her days helping children from difficult family circumstances settle into school. She's smart, busy, and has a free ChatGPT account she’s never used. Why? Her school doesn't allow AI tools on work devices. The budget isn't there for anything paid. And nobody on staff is confident enough with the technology to know where to start, even if the first two problems disappeared tomorrow.

Agnes is not an edge case. She's a typical Loveholidays customer, and she's who Debbie asked the MXP London audience to hold in mind.

“

We're living in a bubble. We're the 0.04% and our daily experience of AI has essentially nothing to do with our users’ reality.”

Debbie McMahon

VP of Product, Loveholidays

For a look at how AI engagement is trending across real products, Mixpanel's 2026 AI benchmarks draw on nearly 290 billion AI events across 2.6 billion devices, and the picture is more nuanced than adoption headlines suggest.

Three ways the bubble distorts your decisions

Debbie named three patterns she sees in herself and across the industry.

Over-prioritizing AI features. "Have you put something out there just because it was easy to do?" She raised her own hand. The pressure is real: boards want AI in the roadmap, investors want AI in the roadmap, competitors are shipping. And the tooling makes it fast to build something. But fast to build isn't the same as worth building.

Underestimating friction. Most people are forming their views on AI right now without the benefit of product communities or conference sessions to help them process it. That's not a knock on users. They're figuring out whether to trust the technology at the same moment they're being asked to use it. Dropping a disclaimer like "generated by AI, so may not be accurate" into a set of results doesn't help someone who's already uncertain about the output.

Asking users to change behavior. Behavior change is extraordinarily difficult even when people want to change. For users with an ingrained habit and no clear reason to do anything differently, it's close to impossible. The customers who are confused or skeptical about AI aren't going to reroute their entire search behavior for a feature they weren't asking for. If what they want is a keyword search and a filter, that's what they'll reach for.

Go deeper

See whether your AI features are delivering value, or just getting used:

What the data actually showed

Two case studies from Loveholidays that Debbie shared with the kind of candor that makes MXP sessions worth attending.

The room grouping problem. Hotel listings at Loveholidays had accumulated a long tail of duplicated, poorly named room types, a messy, years-old problem that had resisted every previous attempt to fix it. When a team went after it with AI, they went in with confidence. What they found was that the problem was deterministic: two rooms are either the same or they're not, and AI isn't built for that kind of precision. The model grouped rooms in ways that didn't hold up to scrutiny, renamed options customers recognized, and quietly dropped listings that people had been booking. The output looked coherent, but it wasn't.

In Debbie’s own words: "Don't put AI on top of a broken thing. Fix the actual problem."

The Q&A tool. Another team shipped an LLM-based Q&A feature into the pre-booking journey, built around the hypothesis that customers comparing hotels would want to ask questions. The feature got used, a lot, actually. But when the team looked at who was using it, the data didn't match the hypothesis at all.

The users weren't pre-booking customers weighing their options. They were people who had already made a booking, navigating a long and confusing post-booking experience to find basic information about their upcoming trip. And the questions they were asking weren't the ones the team had imagined. The top two were whether their room came with a kettle and whether it had an iron. Third most common: the wi-fi password.

In other words, customers who needed information Loveholidays already had were threading through a complex AI-powered feature just to ask if they needed to pack a travel iron. The team proposed moving the tool into the post-booking journey where the actual demand was. Debbie shut it down, and the reasoning is worth sitting with.

“

Just because it does answer those users’ questions doesn't mean that this is the right solution. We have that information. It’s a fact. We just need to give it to them in a form that they need it in.”

Debbie McMahon

VP of Product, Loveholidays

The post-booking journey got fixed instead, and the Q&A tool got pulled. The story doesn't end there: the team is relaunching the feature with a genuinely different hypothesis behind it. Since that original experiment, Loveholidays launched its own reviews platform, which changes what a Q&A tool can meaningfully do and who it's actually for. There's a real use case now tied to a specific user group, and that's what "not now" looks like when it's used well.

Go deeper

Further reading on building and measuring product adoption in the AI era:

Building different journeys for different people

Loveholidays went to their customers directly and asked how they'd feel about AI-mediated booking experiences. The words that came back included "anxiety," "I trust filters more," and "I prefer clicking." There was also genuine enthusiasm from a portion of respondents. But the skepticism was real, present across a significant share of the audience, and Debbie didn't try to explain it away.

53% of consumers distrust AI-powered search results, according to a Gartner survey published in September 2025. Debbie cited a similar figure on stage and her read was plain: "I can't ignore that. That’s the reality for my customers, and that's where we're starting from."

Her answer is to segment more precisely. AI comfort and interest now sit alongside demographics, holiday type, and referral route as a dimension Debbie's team uses to personalize the experience. Design one AI-mediated journey for everyone and you either hold back the users who want to explore new things or push unwanted change onto the customers who aren't ready for it.

Debbie's dad started using email about a decade after she did. She uses that as a reference point: adoption follows its own timeline, and you can't compress it by shipping a feature and calling it done.

The playground: A structural answer

Recognizing a problem clearly is useful. Building an organizational system to address it at scale is something else. That's what separates this MXP session from a general mindset piece.

Debbie's team built what she calls "out the bubble," an internal prototyping environment that anyone at Loveholidays with access to Codex or Claude Code can use, with no prior technical setup required. It's pre-integrated with the company's design system, data mesh, live pricing, and real images, which matters more than it might sound. When you put a prototype in front of a customer in a travel context, the first thing they notice is whether the hotel price looks real. This system removes that distraction so the feedback is about the experience itself.

The pipeline works in three stages:

Anyone at the company builds a prototype, sometimes in 10 minutes, sometimes a couple of hours, and pushes it to an internal testing environment for NMD review.

Prototypes that clear that bar are automatically routed to Usertesting.com, with the builder setting up the user panel themselves, no dependency on a separate research team.

The ones that pass user testing move to a small live test, pushed out via socials, CRM, or the homepage to a defined customer segment.

The important shift isn't the speed, though. It's that the people with the best product ideas are no longer gated by their ability to build prototypes. The system makes that capability available to the whole company. Fewer ideas get duplicated. More of them get in front of real customers. And when something earns the full investment of a real build, there's actual evidence behind the decision.

Start with the problem. The tools will follow.

Debbie closed by revisiting the Henry Ford quote, carefully, because she's not entirely sure Ford said it. But the argument holds regardless. The car achieved adoption because Ford understood what his customers actually needed. He built a faster horse, not a different animal entirely.

“

AI doesn't let us skip understanding what our users need. If you want people to adopt things, you have to start with their problem.”

Debbie McMahon

VP of Product, Loveholidays

The tools have changed. The product job hasn't. What AI does change is how big your answers can be once you've understood the question clearly. The potential is genuinely extraordinary, but only after you've done the harder work of understanding what your users need and why they'd change.

Remember Agnes from the opening of this piece? The primary school teacher who supports children through difficult family circumstances, has a ChatGPT account she never uses, and has no budget, no tech support, and no time to figure it out herself. She's never going to ask for an AI-powered solution to her problems. But she'd benefit enormously if someone took the time to understand those problems and built something that addressed them, with AI as part of the answer rather than the starting point.

That's what good product work looks like, and as Debbie put it, that's always been the job.

Build the bridge your users are ready to cross

The product teams pulling ahead right now aren't the ones shipping the most AI features. They're the ones who understand the gap between their own relationship with AI and their users', and who've built the systems to keep closing it.

To understand what your users are doing in your product, Mixpanel AI is built to surface that signal proactively, so the insight finds you rather than the other way around. For technical teams who want to go further, try Mixpanel Headless where AI agents read and drive Mixpanel programmatically.

Social RSS (?)

2026-06-01T15:41:59Z

What’s up with this?

The spirit, of course, is “I want my Google Reader back.”

I should be careful though: I imagine if we really did have it back exactly as it was, it would probably not be as cool as we remember. That was a long-ass time ago and web software just wasn’t as nice as it is now. But: it really did have social features in it! I could leave comments and see comments from my friends. (How “friends” worked back then, I scarcely remember.)

I’m not alone in wanting this. Here’s what I’ve seen so far.

There is Skyreader, and it looks like Tim Disney is still actively working on it:

In my mind (and perhaps not reality?) Skyreader solves a “cold start” problem where signing up for a new social site is a lonely bummer because you don’t have any friends. Well, if all my Bluesky friends were automatically my friends on Skyreader, wouldn’t that be, like, good?

My problem is… I don’t… get it.

Maybe there aren’t really “friends” on Skyreader? If there are, I can’t really find a list of them. If there aren’t, I guess this isn’t what I’m looking for. Or is it just assumed they are the same as Bluesky friends? I dunno, I think I have a lot to learn about this AT Proto stuff.
What happens when I share an article? Does it share on my Bluesky? It doesn’t look like it. Who sees my shared articles then? My friends, if there are such a thing? Other people who explicitly subscribe? How would anyone figure out how to do that?
It looks like I can share and I can highlight stuff specifically in what I share. Who sees the highlight? I imagine they need to use Skyreader to see that highlight? Or does it republish as RSS somehow?
No comments… right? That’s weird to me for a social feed reader. What I think of when I think social feed reader is 90% writing and reading my friends comments.
The UI is confusing to me. I don’t love the expanding list format that jumps around a lot.

The main reason I can’t “really use it,” though, is that it doesn’t sync with Feedbin. I understand that’s a niche concern, but I need one canonical feed source, so everything I’m subscribed to is in one place, and how much I’ve read is also canonical. That might be antithetical to AT Proto? I have no idea.

Indieweb has their own version of all this, but it’s seriously no joke getting involved. From one of the reader sites, Togther:

What You Need

#1 Your own website

On the IndieWeb your website is your identity. It doesn’t need to be advanced, it doesn’t need to be pretty, it just needs to be yours.

#2 IndieAuth

IndieAuth is a technology to allow you to sign into services using only your website.

#3 A MicroSub Server

MicroSub is where the real magic happens. There are 2 parts; the server and the client. Together is the client, but it needs a server to go along with it. The server does a lot of tricky work such as fetching & parsing feeds as well as keeping track of what you have read and how you have everything organized. If you don’t already have a MicroSub server then check out Aperture.

#4 MicroPub (optional)

MicroPub is an optional but very cool piece of the puzzle. If your own website has MicroPub functionality then you can use Together not just to read content, but also to reply and create your own content. You can like, repost and reply to stuff you are following, you can even write full on blog posts from inside Together.

I mean, I’m not above some nerd hackin’, but this is 100% not ever going to be a place with a critical mass of my friends just chillin’ and sharing/commenting on blog posts. Way too hard.

The closest thing I’ve seen is CommonRSS by Brad Coffield which was build in a direct response to my original Bluesky post.

I originally had a gut reaction to the vibe coding nature of it. Like I don’t wanna use this thing you slopped together over a weekend, you gotta get more serious about it first. Which I admit is just a gut reaction and not a fair assessment of the software. Brad does seem quite sincere about making it a thing. But at the same time, it feels like it’s been months without updates, which is a bad sign for super brand new software.

In testing it lately…

It looks great, love the design — but it feels quite slow across the board.
The Feedbin sync (yay!) didn’t work at first, but appears to be working now.
It now claims to have 2-way syncing (yay!) but that doesn’t work for me. The articles I read aren’t read in feedbin. The stars don’t sync.
It’s got the cold-start social problem: there isn’t anyone to follow. The discover page only lists Brad, and clicking the follow button from him doesn’t work.

It feels like it’s close, but it needs to work better. The commenting feature (again, like my main thing for wanting this) requires you to highlight some of the post first, then you can comment, but the comment won’t save.

CommonRSS feels like a solid concept, but it’s both got the cold-start thing in terms of the social network, but also the cold-start thing in terms of a business. My guess is it’s hard for Brad to muster a ton of enthusiasm to work on the project all day every day with low users.

I’m thinking the main problem is that there just isn’t much of a business to be built around RSS. It can build boutique one-person companies with a passion for it, but even then, difficult.

On top of that, maybe there just isn’t much appetite for the social part? There are a number of arguably already-decently-successful boutique RSS apps, so why haven’t they done it? Why hasn’t Feedbin done anything terribly social? Why not Feedly? Remember FlipBoard’s kind weird taking on RSS? Now they have an equally weird spinoff. My guess is it’s just too hard of work for too little payoff.

On wintering.

2026-05-29T15:00:36Z

Abraham Lincoln rode home from Washington in December 1849, with what looked like the end of his career packed into his luggage. He'd served one term in the House, alienated his constituents by opposing the Mexican War, and lost his shot at a federal Land Office appointment.

He went back to Springfield to practice law, a near-broken man. And, for nearly 5 years, he barely participated in national politics.

He rode the Illinois circuit, argued patent disputes, and taught himself geometry from Euclid by candlelight in coach inns. He read newspapers obsessively; he read Shakespeare and the King James Bible until he could quote either from pretty much any starting point.

The folks who saw him in those years said he looked...tired.

When he returned to the spotlight, in October 1854, the Kansas-Nebraska Act had cracked the country open. Lincoln walked onto the stage at Peoria and spoke for 3 hours straight. The man who'd been a country lawyer that morning was a national figure by midnight.

Six years later, he was president.

Lincoln's lost years are the part of the biography American children skip past in school; they get the rail-splitter, the beard, the debates, the war, the emancipation, the address, the assassination.

But the 5 years we skip over are the whole ballgame.

They rebuilt the instrument.

The English writer Katherine May coined the modern usage in her 2020 book Wintering, but the idea is older than the word. Russian peasants called the long quiet stretches between harvests zima and treated them as a season for weaving, sleeping, repairing tools, and telling stories. Japanese Buddhist monasteries built whole liturgies around rohatsu sesshin, the seven-day winter retreat that closes the year. Foragers like the !Kung and the Hadza, spent something like 4 hours a day on subsistence and the rest on…rest.

Productivity is a recent invention; wintering is not.

Cormac McCarthy published Blood Meridian in 1985 to a shrugging response. The New York Times reviewed it in a single column. He'd been writing in El Paso for years, broke and largely forgotten. Friends thought he'd peaked. Then in 1992 All the Pretty Horses came out, won the National Book Award, sold half a million copies, and the back catalog got reissued. McCarthy hadn't been recovering. He'd been finishing something the culture wasn't ready for in 1985 and was ready for by 1992.

He'd been wintering.

Daniel Day-Lewis stopped acting in 1997 and apprenticed as a cobbler in Florence. He came back, played Bill the Butcher in Gangs of New York, and won an Oscar. He stopped again. Came back. Won another Oscar. Stopped again, and by all reports has actually stopped this time, though I wouldn't bet on it. The cobbler years were how he reset the instrument.

In the long winter, organisms route metabolism inward.

Trees pull resources out of leaves, drop the leaves, and push the sugars down into root systems. Bears don't sleep, exactly. Their core temperature drops a few degrees, their metabolism halves, and they cycle slowly through fat reserves while their kidneys learn to recycle urea into protein. They come out in spring with their bones still mineralized and their muscles roughly intact, which is something no human has yet figured out how to do. What the bear performs is one of the most metabolically sophisticated tricks in the animal kingdom.

The Romans understood that a field left fallow for a season produced more in the next cycle than one worked continuously. Norfolk farmers in the 18th century made it a four-course rotation: wheat, turnips, barley, clover, with the clover restoring nitrogen the wheat had pulled out. The land that looks unused is doing the most useful work.

People who winter well are doing something analogous. They route attention inward and downward, into the parts of the system that don't show up on the surface. They read, they revise, they take long walks they can't account for, and they think the same thought 400 times until it cracks.

Most of what gets published, shipped, posted, and announced is washed off the rocks within a quarter. The people doing it are running on a treadmill that resets their position to zero every Monday. They have to keep producing to stay visible, and visibility is how they earn the right to keep producing.

It's a closed loop, and it generates very little compound interest.

The winterer is off the loop. They aren't maintaining a position because they don't have a position to maintain.

In the short term, you pay dearly for it.

People forget you exist. Calls dry up. Old collaborators stop replying. Younger versions of you lap you in the standings.

The benefit is that you can do work that takes longer than a quarter, and longer than a year, and longer than 5 years, because nobody is auditing the line item.

Charles Darwin came back from the Beagle voyage in 1836 with the rough outline of natural selection in his head. He published On the Origin of Species in 1859. The intervening 23 years included long stretches when he wrote almost nothing in his theory notebooks, partly because he was sick, partly because he was writing 8 volumes about barnacles, and partly because he understood the case had to be airtight. When he finally published, the argument was so heavily fortified that the church spent the next 50 years trying to find a hairline crack and failing.

If Darwin had published in 1840, he might be a footnote. His 23 years of comparative silence were the moat.

Robert Caro started his Lyndon Johnson biography in 1976. He's published 4 volumes of an intended 5. He's now 90. He moved to the Texas Hill Country to live among the people Johnson grew up with, because he thought he couldn't write about a man without inhabiting his weather. Each volume took roughly a decade. The publishing world treats him as a slow eccentric. Anyone who's read the books knows he's running a different clock, on a different scale, and that no one currently working at speed is going to produce anything close.

Plenty of people stop and produce nothing. The graveyard of failed comebacks is large, and wintering is dangerous as a strategy because most attempts at it collapse into actual stagnation.

The difference between the two is invisible from the outside, until the end.

The reason the wintering few register as dangerous, when they re-emerge, is that they have something the still-busy don't have: a center of gravity. They've spent enough time alone with a single problem to develop actual opinions about it, opinions that don't move when other people push on them. In a culture optimized for constant repositioning, conviction is a structural advantage. The market doesn't know how to price it.

The winterer has been watching while you weren't looking. They've watched the consensus shift, watched the mistakes pile up. When they come back, they come back with reads you can't get from inside the swirl, because the swirl makes you stupid.

The philosopher Hannah Arendt, writing in The Life of the Mind in the 1970s, described thinking itself as a form of withdrawal. You can't think and act at the same time, she said, because thinking pulls you out of the stream of ongoing events. She was suspicious of people who claimed to do both at once.

The British psychiatrist Anthony Storr, in Solitude (1988), made the case that the most original work of major figures often came out of long isolated stretches. Newton in plague-year Cambridge. Wittgenstein in Norway. Kafka in Zürau. Beckett in his Paris apartment with the curtains drawn. Storr wasn't romanticizing it; the isolated stretches were often miserable, sometimes pathological. But the work that came out of them had a density that wasn't available to people doing it part-time.

Any culture that systematically punishes withdrawal is going to lose its most concentrated thinkers to either burnout or invisibility. The modern knowledge economy, with its ambient pressure to post, ship, and stay in the conversation, is a machine for producing exactly that loss. The people we'll wish we had in 15 years are, right now, being shamed into producing slop they don't believe in, because the alternative is to drop out, and dropping out reads as failure.

The winterers who survive this will be those who can tolerate looking like they failed. This is a real and rare psychological skill, and most people don't have it. It requires you to be okay with the wrong kind of silence around your name for years. It requires you to pass on small wins that would re-establish your position. It requires you to bet that what you're working on is worth more than what you're giving up, when the only person who can evaluate the bet is you, and you might be wrong, and you'll only know in 7 years.

Lincoln didn't know in 1851 that he was wintering.

He thought he was finished.

He told his law partner William Herndon that his political career was over, and he believed it. And then his country produced an emergency that demanded exactly the kind of mind he'd been nurturing, and he was the man of the hour whose hour had finally come.

The people who appear to have stopped, in any given year, are mostly people who have actually stopped. But small fraction of them are doing the other thing.

Our world produces emergencies on a reliable schedule; when the next one comes, watch who walks out of the woods.

10x engineers: the Purple Developer

2026-05-22T06:35:39Z

What makes a software engineer productive? You can list attributes like experience with the language, scientific mindset, intelligence, focus, a personally crafted IDE setup. Yet, in my experience, far and away the biggest factor is: familiarity with the codebase they’re changing.

That knowledge of what the system does and needs to do, it’s completely essential and entirely contextual. The easiest way to get is to create it — that is, to write that software from scratch. And then it feels completely natural. It doesn’t feel like knowledge, it feels like breathing. It feels obvious.

When you have a decent mental model of a system, sharing that with others is hard. You don’t know how much you know. If you’re the purple developer in this picture:

below the line, a software system; above it, a purple person with a mental model of the system. A blue person and a green person with very incomplete models and lots of questions.

then you have a mental model of this system because you built it. The green and blue developers have been assigned to help, but they can’t change the system because they don’t understand it. Meanwhile, you may be changing the system fast enough that it’s impossible for them to get a grasp on it, no matter how smart they are. (I’ve been in their situation.) The solution is to work together on the system, and invest attention in transferring your mental model. Until then, Blue and Green get in your way.

This slide is part of my Collective Problem Solving keynote (also seen as Origins of Opera). People came up to me afterward: “We have a purple developer. Now I don’t feel so bad about being blue or green” or “Oh no, I’m the purple developer!”

Which developer in this picture is ten times more productive than the others? Purple developer!

Is it because they are inherently smarter? Nah. Circumstances lead to this situation.

There is not any “productive” software engineer so much as “productive in this codebase.” Spread the knowledge, spread the productivity.

Native Apps Should Be Avoided Whenever Possible

2026-05-15T05:08:54Z

April 12, 2026

Native Apps Should Be Avoided Whenever Possible

TL;DR: What you should do:

Openly refuse apps, and vocally advocate for the web instead.

Try not to install any apps if you don’t need to.

If a service has a functioning website, use it instead.

Revoke all permissions by default, including background location, microphone, and camera permissions for anything that doesn’t require them to function.

Audit your installed apps. Uninstall all apps you don’t actively need.

Treat every “download our app” prompt with skepticism.

Most native apps collect far more data than their website equivalents ever could. They request permissions to hardware, sensors, and background processes that browsers deliberately restrict. The third-party software embedded in these apps frequently transmits your location, device identifiers, and behavioral data to third parties before you even see a consent prompt. This data is in tandem bought, sold, and aggregated by brokers. It has been used to out individuals, track immigrants, and enable prosecution over reproductive healthcare.

The White House App

On March 27, 2026, the Trump administration released an official White House app for iOS and Android. Within hours, two independent security researchers decompiled it and published their findings [1]. The app is a textbook example of everything wrong with the native app model.

Apple requires apps to submit a privacy manifest disclosing what data they collect. The White House app declared an empty array. Zero data collection. Meanwhile, the actual binary contained ten analytics frameworks, including the full OneSignal SDK with a sub-framework specifically for location tracking [2]. The GPS pipeline polled precise coordinates every 4.5 minutes in the foreground and every 9.5 minutes in the background, syncing everything to OneSignal’s commercial servers. A boolean flag in OneSignal’s server responses could remotely enable or disable GPS tracking without an app update and without Apple review.

An Exodus Privacy audit identified three embedded trackers, one of which was Huawei Mobile Services Core [3]. The app’s privacy policy, last updated January 20, 2025, makes no mention of GPS tracking, OneSignal, or background data collection.

Nearly everything in the app is available on whitehouse.gov. The app’s unique additions are push notifications, a pre-filled text message to the President, and an ICE tip button (also available on ice.gov). What it actually added at scale was a surveillance pipeline: 77% of the app’s network requests go to third parties, not whitehouse.gov.

The Software Embedded in Apps

Most people think of apps as products built by a single company. In practice, the average app is a thin wrapper around dozens of third-party software packages, each with its own data collection pipeline and commercial incentives. When you grant an app permission to access your location, every package embedded in that app inherits that permission. A single package can appear in hundreds of apps, feeding location data on millions of people to a single aggregator.

In January 2025, a hacker breached Gravy Analytics and leaked roughly 30 million location records collected from 3,455 apps — dating, fitness, gaming, and health apps among them [4]. The FTC subsequently banned Gravy Analytics from selling Americans’ location data [5], but by then the data was already circulating on cybercrime forums.

In a separate case, Google paid $391.5 million to settle claims from 40 states for continuing to collect location data even when users explicitly disabled location tracking [6].

Why Everyone Should Care

This data is bought, sold, and aggregated by brokers. It has been used to out individuals, track immigrants, and enable prosecution over reproductive healthcare. In multiple cases, journalists and private groups have purchased app-derived location data to identify specific people based on their movements.

There are virtually no restrictions in the United States on buying, selling, or weaponizing this data. There is no comprehensive federal privacy law. And there isn’t likely to be one soon. The best we can do is minimize the data we share in the first place.

What Apps Can Do That Websites Can’t

The core argument for using the website instead of the app comes down to what each platform is technically capable of doing without your knowledge.

Capability	Native App	Website / PWA
Background location tracking	Yes, can poll GPS continuously	No
Run at device startup	Yes	No
Access biometric hardware	Yes	Limited (WebAuthn, user initiated)
Modify or delete device storage	Yes	No (sandboxed to browser)
Embed invisible third-party software	Yes, all inherit granted permissions	No, scripts visible in page source
Transmit data before consent prompt	Yes (common with third-party software)	Restricted by browser policies
Push notifications while closed	Yes	Yes (PWA, user opt in required)
Access contacts, call logs, SMS	Yes (if permitted)	No
Prevent phone from sleeping	Yes	No
Camera and microphone	Yes (persistent if granted)	Yes (per session, prompted each time)
Offline functionality	Yes	Yes (via service workers)

The browser is the security boundary. Websites operate within it. Native apps bypass it.

The Access Provided by Default is Enough to Do Real Harm

The moment you install an app, before you allow a single permission prompt, it can:

Reach any server on the internet
Read your IP address, device model, OS version, timezone, country, carrier, and network type
Generate and persist a unique identifier tied to your device
Run code at device startup (Android) and wake up in the background
Fingerprint your device by combining the above into a signature that follows you across sessions
Grant all of this same access to every third-party software package embedded in the app
Compare this data to other datasets to infer your identity, demographics, interests, and habits

The runtime permission prompts you actually see (location, camera, contacts) are helpful while annoying, but the majority of the default access permissions do not require your consent.

A website, by contrast, starts with almost none of this: no persistent identifier, no background execution, no third-party software inheritance, no startup hooks.

Some Things Need to Be Apps, But Most Don’t

Some things need to be apps. AR and VR, real-time games, anything talking to NFC or Bluetooth hardware, serious audio and video work, accessibility tools. These are legitimate cases where the browser sandbox is the limitation. In these circumtances, I personally use a full computer as opposed to my phone.

Almost nothing else qualifies. Your banking, your travel, your grocery store, the restaurant down the street — none of it needs an app. And rewards be damned. No rewards are worth the data you are willingly giving them.

Same goes for hardware. If a thermostat or a fitness tracker can’t be set up without a proprietary app, that’s a flaw in the product, not a feature. I immediately avoid such products. You’re buying an ongoing relationship with someone else’s servers and guaranteeing that you’ll forget that corporations are watching everything they can.

Conclusion

I avoid most apps. It turns out this is easier than most people assume, because the app is almost never the only option. It is just the option the company wants you to take and not enough people question.

We are at a very specific time in humanity right now. Where aggregating data is a currency, and it is actively being utilized at a scale never before seen. I recommend you at least take stock of what you’re freely giving away.

References

1. I Decompiled the White House’s New App (Thereallo, March 28, 2026) and Security Analysis of the Official White House iOS App (atomic.computer, March 27, 2026). Two independent researchers decompiled the app on Android and iOS within hours of release.

2. Security Analysis of the Official White House iOS App (atomic.computer). Documents the empty privacy manifest, OneSignal SDK with ten sub-frameworks, and the remote GPS toggle via server response.

3. Exodus Privacy Report: gov.whitehouse.app. Automated audit identifying three embedded trackers including Huawei Mobile Services Core. Additional context in Fedware: 13 Government Apps That Spy Harder Than the Apps They Ban (Sam Bent).

4. A breach of Gravy Analytics’ huge trove of location data threatens the privacy of millions (TechCrunch, January 13, 2025).

5. FTC Finalizes Order Prohibiting Gravy Analytics, Venntel from Selling Sensitive Location Data (FTC, January 14, 2025).

6. Google to pay $391.5 million in location tracking settlement with 40 states (TechCrunch, November 14, 2022).

AI dělá chyby a autisté je dokážou najít. Z jejich jinakosti dělá Češka ve svém startupu přednost

2026-05-07T05:32:58Z

Představte si konkrétní situaci: datoví vědci ve startupu trénují svůj analytický model, ale v určitých případech narážejí na vysokou chybovost v podobě falešně pozitivních výsledků. Místo toho, aby se pálil drahý čas seniorních inženýrů na manuálním čištění datasetů, předá se úkol ven. Výsledek? Najatý tým projde pět iterací dat a pomůže tak o polovinu zlepšit úspěšnost modelu. Právě na tom staví mladý pražský startup Diversight. Jeho tajnou zbraní nejsou pokročilejší algoritmy, nýbrž dedikovaní analytici na autistickém spektru. Ukazuje tak, že vlastnosti, kvůli kterým se jiné firmy těmto lidem někdy vyhýbají, se mohou proměnit na silné stránky.

„Nejsme charita ani neziskovka, jsme klasická technologická firma,“ říká hned na úvod spoluzakladatelka a ředitelka Diversightu Irena Zatloukalová. V českém technologickém prostředí se pohybuje dvacet let, a to zejména v oblasti komunikace, kdy sedm let byla mluvčí tuzemské internetové jedničky Seznam.cz. Mimo jiné působila i jako spolumajitelka PR agentury Fenek a později na volné noze radila s komunikací technologickým firmám jako Heureka, Apify, Liftago či Ackee. Loni v červenci ale všechny klienty předala dál a naplno se vrhla do nového byznysu.

V Diversightu se zaměřuje na takzvaný datový dluh. V éře, kdy se prakticky každá firma snaží do svých procesů implementovat umělou inteligenci, stojí budoucí úspěch primárně na kvalitě vstupních dat. „I ty nejpokročilejší vývojářské týmy totiž musí manuálně odstraňovat duplicity a řešit hraniční případy, v nichž zavedená automatizace zkrátka selhává a modely začínají generovat nesmysly. Diversight funguje jako filtr, který přebírá na přesnost náročnou vrstvu ekosystému a zajišťuje potřebnou lidskou pojistku proti halucinacím,“ vysvětluje pro CzechCrunch Zatloukalová.

Foto: Diversight

Irena Zatloukalová s kolegou Šimonem

Právě v oblasti hledání nepatrných vzorců totiž samotná umělá inteligence běžně naráží na své limity, dodává. Pokud modely generují opakující se chyby, vývojářům nepostačí jen jednoduché přepsání textového promptu. Týmy potřebují člověka, který dokáže precizně pochopit byznysovou logiku a vyčíst přímo ze syrové databáze konkrétní pravidla a odchylky. „V tom máme ohromnou výhodu, protože máme lidi, kterým jednou řeknete pravidla a oni pak po nich neúnavně půjdou, od prvního řádku až po řádek číslo 1 500,“ popisuje specifikum práce Zatloukalová.

Doplňuje přitom, že jejím lidem nedělá problém udržet stejnou hladinu pozornosti na jednom tématu klidně i osm dní v kuse: „Prostě potřebují problém vyřešit, neznámou najít a věc dotáhnout do konce. To pomyšlení na rozlousknutí problému pomáhá jejich fokusu.“

Na samotném začátku příběhu Diversightu přitom nestála Zatloukalová. „Ráda bych to říkala, ale bohužel to nebyl můj nápad,“ usmívá se a jako originálního tvůrce označuje Tomáše Borovičku z technologické společnosti Datamole. Ten na zahraničních trzích narazil na izraelskou firmu Point AI, která budovala data-anotační byznys (zaměřený na označování surových dat) na přesné práci lidí na spektru. Od té doby přemýšlel nad tím, jak vyzkoušet podobný koncept i v Česku.

„Byla to jedna večeře, jedno potkání, tři hodiny povídání. Šli jsme hodně do hloubky a do našich hodnot a na konci mi řekl: Tak jo, pojďme to zkusit,“ vzpomíná Zatloukalová na zlom, který přišel v prosinci 2024. A dodává, že na začátku je propojila Lenka Kučerová ze spolku prg.ai.

Původní plán Diversightu počítal s tím, že se do Prahy přenese jako franšíza přímo izraelský model. Rychlý průzkum trhu ale ukázal, že běžný anotační byznys je v tuzemsku v podstatě jen levná komodita, kde firmy často najímají studenty a na finální kvalitě jim tolik nesejde. Zatímco v Izraeli se data pro zdravotnictví či zbrojní průmysl anotují s kritickou přesností, v lokálních podmínkách by takový model ekonomicky nepřežil. Diversight proto musel okamžitě změnit plány. Zaměřil se na komplexnější analytické úkoly a takzvanou validaci s člověkem v procesu (human-in-the-loop), kde se naplno využije kognitivní preciznost ve složitých datech.

Projekt od začátku strategicky i finančně podpořil zmíněný Datamole, který mu poskytl peníze na bezpečný roční provoz a působí v roli partnera. Mimo jiné nabízí i přímý přístup ke svým seniorním AI architektům. Hlavním byznysovým úkolem pro nadcházející měsíce je tak dostat Diversight do zisku díky příjmům ze zakázek.

Foto: Diversight

Tomáš Borovička a Irena Zatloukalová

Mezi aktuální klienty vedle analytické společnosti BizMachine, pro kterou startup dělá v úvodu zmíněné čištění dat, patří například také InfraHex, jedna z firem holdingu Respilon. Ta vyvinula technologii, která upravuje tepelnou stopu živých i neživých objektů a tím omezuje jejich detekci pomocí termokamer. V současnosti se využívá i na Ukrajině, kde pomáhá vojákům v terénu. I drobné odchylky zde hrají zásadní roli, protože se systém opírá o přesné analýzy obrazů v různých infra spektrech. A tak se na této detailní práci vyhodnocování a výběru dat podílejí lidé na autistickém spektru.

Českým mediálním i firemním prostorem dnes podle Zatloukalové bohužel rezonují převážně extrémní obrazy autismu, kdy na jedné straně stojí příběhy nespolupracujících jedinců s těžkým postižením, na straně druhé zprofanované postavy geniálních vědců, jako je například Sheldon Cooper z Teorie velkého třesku. Diversight ale systematicky hledá velkou množinu lidí s nadprůměrnou analytickou inteligencí ležící mezi těmito dvěma extrémy. Většina z nich má však potíže projít přes výběrová řízení či běžná HR oddělení, protože standardní firemní postupy zkrátka neumí s neurodiverzitou pracovat.

Pokud zahodíte své ego a uznáte, že někdo našel lepší cestu, firmě to hodně pomůže.

„Už jen to, když do pracovního inzerátu vypíšete deset věcí jako ‚nice to have‘. Člověk na spektru si to projde, u třetí položky si řekne, že má jen dva a půl roku zkušeností místo tří, takže to není práce pro něj, a jde dál,“ vysvětluje Zatloukalová jeden z mnoha detailů, proč kandidáti sami rovnou z recruitmentu vypadávají. Značná část lidí na spektru tak i kvůli tomu končí na úřadu práce či na podřadných pozicích a ve firmách běžně narazí kvůli logickému poukazování na neefektivitu a navrhování lepších postupů.

Zatloukalová proto změnila rovnou i náborový proces a přizpůsobila ho lidem na spektru. Přesné zadání úkolů a otázky zasílá s předstihem, kandidáty navíc netestuje pod umělým tlakem, ale zaměřuje se striktně na jejich schopnost strukturovaně přemýšlet. Aktuálně má firma pět lidí – vedle samotné Zatloukalové je to technologický manažer Adam Vesecký a interní tým tří specializovaných analytiků. Záměrem je tým rozšiřovat, nicméně se stropem na hranici deseti zaměstnanců, aby firma nepřišla o klidné prostředí komorního kolektivu.

Zatloukalová navíc varuje před zjednodušováním nebo předsudky, že práce s neurodivergentními lidmi přináší jen těžkosti a komunikační zádrhele. Na první pohled nepříjemné situace, kdy podřízený manažerovi zcela upřímně oznámí, že zadal úkol špatně, totiž vedou k lepším procesům do budoucna, a tím i výsledkům. „Pokud zahodíte své ego a uznáte, že někdo našel lepší cestu, firmě to hodně pomůže,“ vysvětluje Zatloukalová.

Lidé na spektru podle ní přinášejí do byznysu inovace a odlišné úhly pohledu nejen v datové analytice, ale napříč všemi obory od zákaznické podpory po design. „Mají přirozenou schopnost jít striktně po podstatě problému a všímat si i drobných odchylek, které neurotypická většina snadno přehlédne,“ doplňuje. Výměnou za tento výkon často vyžadují jen velmi specifické, avšak finančně nenáročné úpravy pracovního prostředí – typicky přesun stolu dál od rušné kuchyňky, utlumení ostrého kancelářského osvětlení nebo zkrátka jen možnost po náročné schůzce úplně vypnout a odejít domů.

Cítím nespravedlnost. Jsem naštvaná na to, jakým způsobem se společnost staví k lidem, kteří jsou jiní.

Častou chybou některých manažerů je tyto potřeby zpochybňovat jen proto, že zaměstnanec nemá na stole oficiální lékařskou diagnózu. „Moje velká prosba k jakémukoliv manažerovi je: i bez diagnózy člověka poslouchejte. Když říká, že něco potřebuje, respektujte to, nezpochybňujte a hledejte cesty, jak zařídit, aby mohl svoji práci vykonávat co nejlépe,“ apeluje. Jak sama upozorňuje, nevyžaduje to stavbu drahých oddělených kanceláří, často stačí investice do kvalitních sluchátek s aktivním potlačením hluku.

Přístup orientovaný na lidi se specifickými potřebami má podle Zatloukalové přesah do celkového chodu jakékoliv firmy. Veškerá drobná provozní pravidla a limity, které startup explicitně zavádí kvůli neurodivergentním kolegům, totiž v důsledku ulehčují práci všem. „Každý zaměstnanec občas potřebuje ničím nerušený čas na práci, jen se to v běžných korporacích tolik neakcentuje. Funguje zde stejný princip jako v moderním urbanismu. Pokud navrhnete veřejný prostor tak, aby vyhovoval lidem na vozíku, dětem i rodičům s kočárky, vytvoříte ve finále vysoce funkční prostředí, ve kterém se bude dobře žít úplně všem,“ srovnává.

Na druhou stranu Zatloukalová doplňuje, že budování neurodiverzního týmu s sebou pro vedení nese nutnost preciznosti v mezilidské komunikaci. „Tou se živím dvacet let a největší paradox je, že se mi opravdu stává, že si s kolegy nerozumím v zadání,“ přiznává s tím, že sama musela odložit své ego stranou a opět se učit zadávat úkoly maximálně jasně, doslovně a bez zbytečného sarkasmu.

To vše se promítá i do samotného workflow při řešení úkolů pro klienty. „Když řeknu ‚udělej A‘, kolega si začne domýšlet B, C a D. A místo toho, aby se zeptal, radši to rovnou udělá až po to D. Já mu pak musím říkat, že zašel moc daleko. Pro příště ale vím, že potřebuji dát víc kontextu k tomu, proč má v bodě A skončit,“ ilustruje občasné komunikační střety zakladatelka. Doslovnost a analytický rozklad problémů se však startupu okamžitě vrací ve chvíli, kdy tým narazí na nekvalitní a chaotická data v zadání.

„Cítím nespravedlnost. Jsem naštvaná na to, jakým způsobem se společnost staví k lidem, kteří jsou jiní. Ta jinakost nemusí být na první pohled patrná, ale znamená pro ně spoustu překážek, které jim vyrábíme my všichni. Angličtina pro to má slovní spojení ‚disabled by society‘. Jakmile mi ukážete něco takového, jsem totální buldok a jdu po narovnávání té nespravedlnosti,“ vysvětluje Zatloukalová, pro kterou se tak v Diversightu kromě společenského přesahu spojuje vášeň pro data a práce s lidmi. „Baví mě dělat věci, které nikdo předtím moc nedělal nebo neprozkoumal. Diversight má v sobě všechno,“ uzavírá.

Using safe-area-inset to build mobile-safe layouts

2026-05-06T12:14:32Z

Modern phones are not simple rectangles. They have rounded corners, camera cutouts, dynamic islands, and home indicators that double as gesture areas. Browsers know the dimensions of all of these and expose the parts that could obscure content as safe area insets.

The "safe area" is the portion of the screen that is guaranteed to be free from being obscured by system UI. The safe-area-inset is the measurement of how much space the system UI is taking up on each edge of the screen. By using these values in your CSS, you can make sure that important content and controls are not obscured by the system UI.

If you don't want your floating chat button to end up sitting behind the home indicator, where it's unreachable, you need to account for the safe area inset.

Environment variables for safe area insets

With the safe-area-inset environment variables, you can make your layout adapt to the current device's safe area and avoid those bugs. The env() function is how you read those values in CSS:

body {
  padding-top: env(safe-area-inset-top);
  padding-right: env(safe-area-inset-right);
  padding-bottom: env(safe-area-inset-bottom);
  padding-left: env(safe-area-inset-left);
}

Browser support

Safe-area-insets are baseline widely available, which means you can use them in production today and be confident that they will work for almost all your users on mobile devices.

Since it's baseline widely available, you don't really need to think about fallbacks but if you want to be extra safe, you can provide a fallback padding if the browser doesn't support env():

body {
  padding-top: 1rem; 
  padding-top: calc(env(safe-area-inset-top) + 1rem);
}

And for browsers that support env() but not safe-area-inset-* variables, you can provide a fallback value directly in the env() function. If safe-area-inset-top is not supported, it will fall back to 1rem:

body {
  padding-top: env(safe-area-inset-top, 1rem);
}

It's worth noting that this situation is purely theoretical, as all browsers that support env() also support safe-area-inset-* variables. That might not be the case with other environment variables, so it's good to know that this fallback mechanism exists.

Using safe-area-inset values

Before we get into problem areas, let's get a general understanding of how these variables work and how you can use them to affect the layout.

In this demo, change each inset and watch how a realistic mobile UI that takes safe area insets into account shifts to remain usable:

The specific px values here are not particular to any specific device, the point is to show how the device sets these variables and how your layout can respond to them as they change.

On real devices, you can think of these values as constants. They're provided by the browser and while they might change when switching from portrait to landscape or between OS updates that change the device UI as well as simply differ per device, they don't change dynamically as the user scrolls or interacts with the page. The browser provides them as a constant value that you can use to ensure your content is not obscured by the system UI.

Which web pages actually need this?

If you want your pages to look the best they can, all of them.

Browsers by default will prevent your site from being obscured by the notch or home indicator, so your content will be safe without any special handling. That does come with a downside, which is that the browser will give you a smaller viewport to reserve space:

You'll notice the edges here keep the site from being obscured, but they also don't look that great. Ideally we want the content to stretch edge-to-edge, but we want to make sure they're not obscured by system UI. To get that, you need to opt in to the full viewport and handle safe areas yourself.

To do so is a two-step process. First, you need to add viewport-fit=cover to your meta viewport tag:

<meta name="viewport" content="width=device-width, viewport-fit=cover" />

This will make the browser stretch your page edge-to-edge:

As you can see, the content sits behind the notch/dynamic island. viewport-fit=cover tells the browser that you want to be responsible for making sure your content is not obscured by the system UI.

And now we can move those elements away from behind the system UI using env(safe-area-inset-*).

.content {
  padding-right: env(safe-area-inset-right);
  padding-left: env(safe-area-inset-left);
}

If you opt into the full viewport, here are the kinds of things you now have to think about to make sure your content is not obscured by the system UI:

Fixed headers and navigation bars should have enough space above or below for the notch or home indicator
Floating chat or help buttons should remain inside the safe area
Full-screen dialogs and drawers should take up the right height without being obscured by the home indicator
Map or video controls near screen corners

Safe-area-inset doesn't provide margins

Safe-area-insets are defined to be exactly the space that the system UI is taking up. That means they don't provide any margin between the system UI's edge and your content.

If you set padding to just the safe-area-inset value, your content will sit right up against the edge of the safe area, which is right up against the system UI.

To add some breathing room, you can add your own padding on top of the safe area insets by combining things with calc(). This way you can ensure that your content is not only safe from being obscured but also has some space to breathe:

body {
  padding-top: calc(env(safe-area-inset-top) + 1rem);
  padding-right: calc(env(safe-area-inset-right) + 1rem);
  padding-bottom: calc(env(safe-area-inset-bottom) + 1rem);
  padding-left: calc(env(safe-area-inset-left) + 1rem);
}

Safe-area-inset only has non-zero values on mobile devices

env() is supported across browsers and platforms, but the safe-area-inset-* variables really only have non-zero values on mobile devices.

Desktop browsers always return 0 because there is no UI on top of pages in desktop browsers. It's only on mobile devices that these values are non-zero and that you have to account for them.

That's exactly why these bugs are so easy to miss. If you test in the Chrome responsive view, the safe area insets will still be 0 and you won't see any issues during development.

Testing on real devices is often delegated to the end of the project. By then, making layout changes to accommodate safe areas can be expensive, and the bugs can slip through to production. Even worse, they often only affect users on certain devices, so they can go unnoticed for a long time.

Polypane's device emulation supports safe area insets

Polypane is the first and only desktop browser to emulate safe area insets. Every device in Polypane has correct safe area inset values for both portrait and landscape orientations.

Here's Polypane showing the safe area insets in blue, and the small viewport height difference in pink:

We're also the only desktop browser to emulate svh, but that's a topic for another article.

With Polypane's safe-area-inset overlay visualization, you can see exactly where the unsafe areas are on each device.

Solving a specific issue: Floating buttons

Let's look at a specific example of how to use safe-area-inset values to solve a common issue: floating buttons that end up behind the home indicator and become unreachable.

.chat-button {
  position: fixed;
  right: 10px;
  bottom: 10px;
}

Toggle the positioning between 'Fixed position' and 'Using env()' to switch between hard-coded offsets and offsets that use safe-area-inset-bottom and safe-area-inset-right.

`safe-area-max-inset`

Along with safe-area-inset-*, the specification also describes safe-area-max-inset-* variables. Those are not widely supported yet, but they are worth mentioning because they have slightly different behavior:

safe-area-inset-* gives you the current inset value right now. On scroll, the browser chrome can collapse, and the inset value can shrink all the way to 0. Your element moves with that change.
safe-area-max-inset-* gives you the maximum inset the browser can report for that edge. It stays stable even when the browser chrome collapses. Use it when you want a reserved zone that does not jump around.

Drag or scroll the phone to simulate the browser address bar appearing and disappearing.

The green button uses safe-area-inset-bottom and follows the current inset. The blue button uses safe-area-max-inset-bottom and stays put.

OverlayShow safe inset areas

inset vs max-inset

When to use which really depends on your situation. For some UI components it makes sense to move with the live viewport state, like a floating chat button that should always be just above the home indicator.

For other things, like a persistent cookie banner or a full-screen dialog, it can be better to reserve a stable zone that doesn't shift when the browser chrome collapses so that users don't inadvertently tap the wrong button.


.floating-cta {
  bottom: calc(env(safe-area-inset-bottom) + 1rem);
}


.persistent-zone {
  bottom: calc(env(safe-area-max-inset-bottom) + 1rem);
}

Browser support for `safe-area-max-inset-*`

As of now, only Chromium implements safe-area-max-inset-* so there is no support in (mobile) Safari or Firefox. That means you can't depend on it yet and should provide a fallback stack for other browsers:

.bottom-spacer {
  padding-bottom: 1rem;
  padding-bottom: calc(env(safe-area-inset-bottom) + 1rem);
  padding-bottom: calc(env(safe-area-max-inset-bottom, env(safe-area-inset-bottom)) + 1rem);
}

Notice how we're using the env() fallback mechanism to fall back to safe-area-inset-bottom if safe-area-max-inset-bottom is not supported.

Testing safe areas in Polypane

As covered earlier, safe area bugs are easy to miss during development. Chrome's responsive view always reports inset values of 0, and real-device testing tends to get pushed to the end of the project, when fixing layout issues is expensive and bugs have already reached production.

Polypane changes that. You can test safe area insets (and small viewport behavior) directly on your desktop, across multiple devices and orientations simultaneously, as part of your normal development workflow.

Catch real-device layout failures during development, not after shipping.

What to take away

Safe areas are not edge cases for unusual devices. They are the reality of modern mobile devices with camera punch holes, notches, dynamic islands, and home indicator bars. Your users are on those devices, and if you want to give them the best experience, you need to make sure your content is not obscured by the system UI.

Make sure your viewport is set to viewport-fit=cover so you get the full viewport and that you use env(safe-area-inset-*) so all your content is visible and accessible. That gives users the best experience.

Get started with testing safe areas in Polypane today, and catch real-device layout failures during development, not after shipping.

Design Token Naming Conventions: A Practical Guide

2026-05-04T10:30:43Z

Design Token Naming Conventions: A Practical Guide

23rd of April 2026

On This Page:

If you have ever stared at a long token list and wondered whether a name should be button-primary-bg, primary-button-background, or color-button-primary, you are not alone.

Naming design tokens can look and feel simple right up until you have to do it for real. Choose a weak pattern and things get inconsistent fast. Choose a clear pattern and you get a shared language that helps both design and engineering move quicker.

There is no single correct convention. A two-person team shipping one product has very different needs from a large organisation running multiple brands across multiple platforms.

What you can do is pick a convention that is clear, consistent, and scalable. This article walks through the core token tiers, common naming models, and practical rules that help avoid naming drift.

Why naming gets hard faster than expected

Most teams don't struggle creating tokens. They struggle to keep token meaning stable as more people and components work on the Design System.

You can often see multiple names emerge for the same idea:

Code languagejson

["spacing.small", "space-2", "gap-md", "paddingStandard"]

Each name might make sense in isolation. Together, they signal a semantic drift. The naming model is no longer acting as a shared language.

This is why naming quality can affect delivery speed. If token intent is unclear, every usage becomes a local judgement call, and those judgement calls will accumulate into inconsistency.

The examples in this article follow the Design Tokens Community Group specification using $value, $type, and dot-notation aliases like {color.brand.primary}.

What are design tokens, a quick recap

Design tokens are a tooling and platform agnostic way to store design decisions as named values: colour, spacing, typography, radius, shadows, motion, and (much) more.

The key difference is where and how many times you define those values.

Without tokens, you might use #BADA55 in dozens of places across components, stylesheets, and design files. When that green needs to change, you might have to hunt down every instance to make sure you're updating everything that needs to be updated.

With tokens, you create a design token file, a JSON object following the Design Tokens Community Group specification:

Code languagejson

{
  "green": {
    "400": {
      "$value": "#BADA55",
      "$type": "color"
    }
  }
}

You define #BADA55 once as green.400, then you can reference that name everywhere. The value is still defined somewhere, but it is defined in one place with a meaningful name and consumed by both design tools and code by reference via tooling like Tokens Studio or Style Dictionary.

This centralisation helps to give you three major benefits:

Better consistency across UI
Easier theming and re-branding
Safer changes at scale because you update once and propagate everywhere

Tokens are not just a technical detail. They are a shared language between design and development (and the whole team) that ends up in the product(s).

The three token tiers

Most modern token workflows follow a three-tier model. You will see different names for each tier, but the same underlying structure keeps showing up.

Tier 1 - Primitive tokens

These are your raw values.

They describe what something is, not why it exists.

They are also referred to as reference, base, options, or global tokens.

Code languagejson

{
  "blue": {
    "500": {
      "$value": "#0066CC",
      "$type": "color"
    }
  },
  "spacing": {
    "8": {
      "$value": "8px",
      "$type": "dimension"
    }
  }
}

Primitives should not (imho) and are usually not consumed directly by components. They are source values for more specific design decisions and token tiers.

A common failure is skipping straight to component naming because it feels productive in the short term. In practice, that locks in naming decisions before your core scales are stable.

When possible, stabilise primitives first, attach intent later.

Code languagejson

{
  "core": {
    "dimension": {
      "100": { "$value": "8px", "$type": "dimension" },
      "200": { "$value": "16px", "$type": "dimension" },
      "300": { "$value": "24px", "$type": "dimension" }
    }
  }
}

Tier 2 - Semantic tokens

Also known as alias, decision, theme, or system tokens.

Semantic tokens can express intent. They describe why a value is used or what it is for.

Code languagejson

{
  "color": {
    "brand": {
      "primary": {
        "$value": "{blue.500}",
        "$type": "color"
      }
    }
  }
}

This is where tokens become resilient.

If brand blue changes, the semantic name can stay the same while the underlying primitive reference changes.

You can update once and it will change everywhere.

Code languagejson

{
  "layout": {
    "spacing": {
      "formStack": { "$value": "{core.dimension.300}", "$type": "dimension" },
      "contentToButton": {
        "$value": "{core.dimension.200}",
        "$type": "dimension"
      }
    }
  }
}

Tier 3 - Component tokens

Also known as "component specific" or contextual tokens.

This layer maps semantic intent to specific elements, components, and parts thereof.

Component tokens should always reference semantic tokens, never primitives directly. That indirection is what can keep the system flexible.

It is optional, but very useful in larger systems.

Code languagejson

{
  "button": {
    "primary": {
      "background": {
        "$value": "{color.brand.primary}",
        "$type": "color"
      }
    }
  }
}

Component tokens give you precision. You can tune one component without creating side effects and explosions elsewhere.

Common naming conventions

There is no universal winner ... "It depends". Different teams will always optimise for different makeup, needs, and constraints.

These diagrams show the core layers for each convention. Real-world usage may add optional layers like state or namespace for more specificity.

1. Category-Property-Modifier (CPM)

category property role state

This starts broad and gets more specific: category, property, role (and optionally state for interactions). It is easy to scan and keeps naming fairly lightweight.

Code languagejson

{
  "color": {
    "button": {
      "primary": {
        "hover": {
          "$value": "{color.brand.primary-hover}",
          "$type": "color"
        }
      }
    }
  }
}

2. Tier-based naming

primitive semantic component state

Here, the naming pattern changes depending on the tier. Primitives hold values, semantic tokens hold intent, and component tokens hold local UI decisions, which keeps each layer focused. The diagram shows the token tiers; actual nesting depth varies (e.g., primitives are often 2 layers, while component tokens may be 3+).

Code languagejson

{
  "blue": {
    "500": {
      "$value": "#2196F3",
      "$type": "color"
    }
  },
  "color": {
    "brand": {
      "primary": {
        "$value": "{blue.500}",
        "$type": "color"
      }
    }
  },
  "button": {
    "primary": {
      "background": {
        "$value": "{color.brand.primary}",
        "$type": "color"
      }
    }
  }
}

3. Object-Property-Modifier (OPM)

object property modifier state

This one starts with the UI object, then narrows to property and variant. It tends to feel natural in component-led workflows because it mirrors how teams talk about UI day to day.

Code languagejson

{
  "button": {
    "background": {
      "primary": {
        "hover": {
          "$value": "{color.brand.primary-hover}",
          "$type": "color"
        }
      }
    }
  }
}

4. Context-first naming

tier category property modifier

Context (e.g., 'brand' or 'theme') comes first, followed by category, property, and modifier. This ensures you know the layer before the specific decision. That works well when the same semantic token needs to exist across several themes or brands.

Code languagejson

{
  "brand": {
    "color": {
      "primary": {
        "default": {
          "$value": "{primitive.color.blue.500}",
          "$type": "color"
        }
      }
    }
  }
}

5. A Comprehensive Structure

namespace category concept property variant state

Each segment has a specific job, from namespace through to state. This comprehensive structure allows for up to 6 layers, but start with the core 5 and add as needed for complexity. Names are longer, but they are very explicit, which helps when multiple teams and brands share the same system. Nathan Curtis's article Naming Tokens in Design Systems goes much deeper on this taxonomy, it's well worth a reading (and bookmarking).

Code languagejson

{
  "acme": {
    "color": {
      "button": {
        "background": {
          "primary": {
            "hover": {
              "$value": "{acme.color.brand.primary}",
              "$type": "color"
            }
          }
        }
      }
    }
  }
}

Handling variants, states, and modes

Whatever base naming model you choose, you still need clear, predictable state and variant placement patterns.

One practical way to stay coherent is to define where each concept lives in the name:

Variant: what version of the same thing it is (for example primary, secondary, danger)
State: how that version is currently behaving (for example hover, active, disabled)
Mode: which environment it belongs to (for example light, dark, highContrast)

If those three ideas float around in different positions, naming gets noisy fast.

The same decision in different conventions

These examples all express the same meaning: primary button background on hover in dark mode.

Code languagejson

[
  "button.primary.background.hover.dark",
  "button-background-primary-hover-dark",
  "dark.button.primary.background.hover",
  "acme.color.button.background.primary.hover.dark",
  "theme.dark.component.button.primary.background.hover"
]

Pick one ordering model and enforce it consistently. Mixing these patterns inside one system is where discoverability starts to break down.

Variants

Variants describe alternatives at the same hierarchy level, not interaction changes.

Code languagejson

[
  "button.primary.background",
  "button.secondary.background",
  "button.danger.background"
]

Equivalent variant naming in other conventions:

Code languagejson

[
  "button-background-primary",
  "button-background-secondary",
  "button-background-danger",
  "component.button.background.primary",
  "component.button.background.secondary",
  "component.button.background.danger"
]

States

States represent interaction or status changes for the same UI element. Keep state terms predictable (hover, active, focus, disabled) so engineers can find related tokens quickly.

Code languagejson

[
  "button.primary.background.hover",
  "button.primary.background.active",
  "button.primary.background.disabled",
  "button.primary.background.focus"
]

The same state grouping works across naming styles:

Code languagejson

[
  "button-background-primary-hover",
  "button-background-primary-active",
  "button-background-primary-focus",
  "button-background-primary-disabled"
]

Code languagejson

[
  "component.button.background.primary.hover",
  "component.button.background.primary.active",
  "component.button.background.primary.focus",
  "component.button.background.primary.disabled"
]

Scale sizes

Scale tokens create consistent step-based sizing. Whether you use xs-xl labels or numeric steps, use one scale pattern and apply it everywhere to avoid drift.

Code languagejson

{
  "spacing.sm",
  "spacing.md",
  "spacing.lg",
}

For type scales, the same rule applies: keep naming sequential so size relationships are obvious at a glance.

Code languagejson

["font.size.sm", "font.size.md", "font.size.lg"]

Modes and themes

Modes are contextual variants of the same decision (for example light and dark). The token purpose stays the same, only the value changes per mode.

Code languagejson

["color.background.default.light", "color.background.default.dark"]

Other mode-placement patterns you will see in real systems:

Code languagejson

[
  "light.color.background.default",
  "dark.color.background.default",
  "theme.light.color.background.default",
  "theme.dark.color.background.default"
]

Whichever pattern you choose, keep mode placement fixed. A stable suffix or a stable prefix both work; switching between them does not.

Numbered scales

Numbered scales are useful when you need many fine-grained steps, especially for colour ramps and heading systems. The key is to keep the numbering direction and increments consistent.

Code languagejson

[
  "font.size.heading.1",
  "font.size.heading.2",
  "font.size.heading.3",
  "color.gray.50",
  "color.gray.100",
  "color.gray.200"
]

Numbered scales also appear in alternative patterns:

Code languagejson

[
  "size-font-heading-100",
  "size-font-heading-200",
  "size-font-heading-300",
  "scale.type.heading.100",
  "scale.type.heading.200",
  "scale.type.heading.300"
]

Rules that keep token naming healthy

Most strong naming systems follow a predictable anatomy: an optional prefix (namespace or context), a core meaning (category and property), optional modifiers (intent, variant, scale), and an optional suffix (state or mode).

You do not need every part in every token, but when a part is present it should always appear in the same position.

1. Consistency beats perfection

The best naming system is the one your whole team actually follows.

Drifting tends to start not where the convention is broken outright, but where it is ambiguous enough to invite interpretation. A token set that mixes naming styles makes it impossible to predict what a new token should be called.

Avoid: mixing conventions across the same token tier

Code languagejson

[
  "color.button.primary.default",
  "button.background.primary.hover",
  "theme.dark.component.button.primary.background.default"
]

Prefer: one convention applied throughout

Code languagejson

[
  "component.button.primary.background.default",
  "component.button.primary.background.hover",
  "component.button.secondary.background.default"
]

2. Optimise for clarity over brevity

Autocompletion means typing long names is rarely a problem, but reading a token list at a glance still relies on human pattern recognition. Abbreviating too aggressively trades a small typing convenience for an ongoing cognitive overhead every time someone reads or audits the system.

Avoid abbreviations that require decoding

Code languagejson

["btn-bg-pri-hvr", "c-txt-err", "sp-md"]

Prefer names that read on first glance

Code languagejson

["button-background-primary-hover", "color-text-error", "spacing-md"]

3. Keep semantics semantic

A name like color-text-red describes a visual value, which means the name breaks as soon as the colour changes. A name like color-text-error describes intent, which stays stable even when the underlying value does not. At semantic and component levels, name for why, not what.

Avoid: naming for the visual value

Code languagejson

["color.text.red", "color.background.grey", "color.border.green"]

Prefer: naming for the intent

Code languagejson

["color.text.error", "color.background.subtle", "color.border.success"]

4. Order from broad to specific

Names are easier to scan when they move from the widest concept toward specificity. This also means that alphabetically sorted token lists naturally group related tokens together, which makes auditing and searching much faster.

Avoid: specificity before category

Code languagejson

["hover.primary.button.color", "disabled.background.input", "lg.font.heading"]

Prefer: broad category first, narrowing toward specificity

Code languagejson

[
  "color.button.primary.hover",
  "color.input.background.disabled",
  "font.heading.lg"
]

5. Make names self-explanatory

A developer who has never seen your design tokens before should be able to make a reasonable guesstimate about what it does. If a name requires specific knowledge or a colleague to interpret, it is a candidate for renaming.

Avoid: names that only make sense in context

Code languagejson

["token-1", "c-bd-x", "primary-a"]

Prefer: names that explain themselves

Code languagejson

[
  "button.border.radius",
  "color.border.focus",
  "color.button.background.primary"
]

6. Design for growth

Your naming model should be able to absorb more components, more themes, and potentially more brands without a heavy structural rewrite. That does not mean you need to "over engineer" from the start, but it does mean avoiding patterns that only work at small scale, like implicit positional meaning or naming steps after their current count.

Avoid: patterns that hit a ceiling

Code languagejson

["spacing-small", "spacing-smaller", "spacing-new", "spacing-new-2"]

Prefer: a scale that can always grow in either direction

Code languagejson

["spacing.100", "spacing.200", "spacing.300", "spacing.420"]

Choosing your convention

A practical way to decide is to consider your team size, system scope, tooling, and existing patterns together.

Larger teams will need a stronger structure, single product systems can probably stay simpler, and tools like Figma, Tokens Studio, and your build pipeline may naturally favour one style.

It is also usually safer to evolve existing patterns than replace everything at once, and the best outcome comes when designers and developers both buy into the same model.

Start simple, document it clearly, add examples, and revisit as the system grows.

Token names do not need to be academically perfect. They need to be clear enough that your team can apply them without hesitation.

Keep naming alive with lightweight governance

Naming is not a one time decision.

It is an ongoing Design System practice.

If you want conventions to hold up over time, define lightweight governance:

One canonical naming guide with approved examples
A short review checklist for new tokens
Periodic cleanup of duplicate or ambiguous names
Shared ownership across design and engineering

The goal is not "process for process' sake".

A token system in a Design System that people trust is one they will actually use, and consistent naming is how that trust gets built.

Upgrading Forgejo with S3 Object Storage and Actions!

2026-05-03T10:50:05Z

Awhile ago I spun up my own instance of Forgejo. Forgejo, if you are not familiar, is a hard fork of Gitea when they became a for-profit company and is run/managed by Codeberg. If you want more details on why Forgejo came to be, you can read their blog post here. As of now it’s basically a drop-in replacement for Gitea. Though over time this will change as the two projects drift apart. So it may not be one in the future! Anyhow, I’ve been rolling my own instance since September 2023 and, recently I have been moving my entire lab towards a more GitOps approach. To do this and do it securely (in the confines of my internal network), I’ve decided to turn Forgejo into my full CI/CD manager and config storage place. I’ll also be using Bitwarden’s Secret Manager to manage, well, secrets.

Before I begin re-doing my lab for the umpteenth time, I need to change how Forgejo operates currently. That way Forgejo can support the transition from ‘FileOps’ (aka loose files) to GitOps. Now this isn’t the ‘perfect’ setup process as the repo storage still lives in /data, and it’s not currently replicated across my small swarm cluster. This will change when I get to actually rebuilding the cluster from the ground up to utilize NFS mounts for shared storage. Though that requires more hardware, which the wife probably won’t be happy about. 😅

Migrating to S3 Object Storage

Forgejo (in Docker), by default, has you map a /data directory where all the necessary configs/repos/logs/etc. live. As you can see by the example compose file here.

docker-compose.yml


    image: codeberg.org/forgejo/forgejo:7
      - ./forgejo:/data # <---- data volume
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro

This is great if you plan on just running a simple setup, or you already have shared storage. For me though, I have no shared storage, and a MinIO server that is currently doing nothing but holding attachments for Outline. I figured it’s time to put it to more use. That, and my day job involves doing AWS things so figured it would be good practice.

Currently, Forgejo supports the following directories (under /appdata) for object storage.

Forgejo Docs: Storage Settings
Subsystem	Directory	app.ini Sections
Attachments	attachments/	[attachment]
LFS	lfs/	[lfs]
Avatars	avatars/	[avatar]
Repository avatars	repo-avatars/	[repo-avatar]
Repository archives	repo-archive/	[repo-archive]
Packages	packages/	[packages]
Actions logs	actions_log/	[storage.actions_log]
Actions Artifacts	actions_artifacts/	[actions.artifacts]

As you can see in the table above there are a few storage directories missing. Mainly repositories. Since repositories do not work well in object storage they are unsupported. Which means they will still be living on one of my hosts temporarily until I finalize my cross cluster storage solution. In order migrate the storage to MinIO, I first need to create a bucket (named forgejo), an Access Identity, and an ACL for it.

access-credentials

Access_key: O3n9bNhrbadkeyAGKOuhIUzMGF
Secret_key: czgQT1fb1l3GD2nRQEPebadsecretbWG0xGIu20hjOeBfoSGo

Access Key User Policy


    "s3:ListBucketMultipartUploads",
    "s3:AbortMultipartUpload",
    "s3:ListMultipartUploadParts",

The above ACL replaces the default one under the “Current User Policy” after enabling the “ON” switch for “Restrict beyond user policy” setting in User > Access Keys > Create access key. It limits the access key to the forgejo bucket. The bucket is also private by default, so I do not have to change the bucket ACL.

MinIO Create Access Key with a custom user policy

Next was to upload the existing files to MinIO so that when Forgejo restarted with the new s3 config it would pick them back up. As you can see in the picture below there are a few absent directories. I decided to condense a few related directories into parent ones for my ease of use. Also, some of them do not exist yet and will be created when needed (e.g. packages/).

Example MinIO bucket directory layout

My current s3 bucket directory layout:

With MinIO ready to go, all I had to do was update the Forgejo container environment variables for the MinIO connection and re-deploy. Forgejo environment variables can be defined using the env -> ini notation. So in your app.ini you have sections that are labeled, such as ‘[security].’ In order to update the INI value for say, ‘INSTALL_LOCK’, you’d need to define it as FORGEJO__security__INSTALL_LOCK.

As you can see in the example snippet file below, I am defining the MinIO connection information, as well as, where to look for specific directories in the bucket.

forgejo-minio-env-example

      - FORGEJO__storage__STORAGE_TYPE="minio"
      - FORGEJO__storage__MINIO_USE_SSL="true"
      - FORGEJO__storage__MINIO_ENDPOINT="s3.${LAB_DOMAIN}"
      - FORGEJO__storage__MINIO_ACCESS_KEY_ID=${FJ_S3_ACCESS_ID}
      - FORGEJO__storage__MINIO_SECRET_ACCESS_KEY=${FJ_S3_ACCESS_KEY}
      - FORGEJO__storage__MINIO_BUCKET="forgejo"
      - FORGEJO__storage__MINIO_LOCATION="us-east-1"
      - FORGEJO__attachment__MINIO_BASE_PATH="attachments/"
      - FORGEJO__lfs__MINIO_BASE_PATH="lfs/"
      - FORGEJO__avatar__MINIO_BASE_PATH="avatars/users/"
      - FORGEJO__repo-avatar__MINIO_BASE_PATH="avatars/repositories/"
      - FORGEJO__repo-archive__MINIO_BASE_PATH="archives/"
      - FORGEJO__packages__MINIO_BASE_PATH="packages/"
      - FORGEJO__storage.actions_log__MINIO_BASE_PATH="actions/logs/"
      - FORGEJO__actions.artifacts__MINIO_BASE_PATH="actions/artifacts/"

Forgejo Compose Example [Expand me]

forgejo.yml


      test: ["CMD", "curl", "-fSs", "localhost:3000/api/healthz"]
    image: codeberg.org/forgejo/forgejo:7.0
      - FORGEJO_APP_NAME="Forgejo"
      - FORGEJO_RUN_MODE="prod"
      - FORGEJO_WORK_PATH="/data/gitea"
      - FORGEJO__repository__ROOT="/data/git/repositories"
      - FORGEJO__repository.local__LOCAL_COPY_PATH="/data/gitea/tmp/local-repo"
      - FORGEJO__repository.pull-request__DEFAULT_MERGE_STYLE="merge"
      - FORGEJO__repository.signing__DEFAULT_TRUST_MODEL="committer"
      - FORGEJO__server__APP_DATA_PATH="/data/gitea"
      - FORGEJO__server__DOMAIN="git.${LAB_DOMAIN}"
      - FORGEJO__server__SSH_DOMAIN="git.${LAB_DOMAIN}"
      - FORGEJO__server__HTTP_PORT="3000"
      - FORGEJO__server__ROOT_URL="https://git.${LAB_DOMAIN}"
      - FORGEJO__server__DISABLE_SSH="false"
      - FORGEJO__server__SSH_PORT="22"
      - FORGEJO__server__SSH_LISTEN_PORT="22"
      - FORGEJO__server__LFS_START_SERVER="true"
      - FORGEJO__server__LFS_JWT_SECRET="${FJ_JWT_SECRET}"
      - FORGEJO__server__OFFLINE_MODE="false"
      - FORGEJO__database__DB_TYPE="postgres"
      - FORGEJO__database__HOST="${FJ_DB_HOST}"
      - FORGEJO__database__NAME="${FJ_DB}"
      - FORGEJO__database__USER="${FJ_DB_USER}"
      - FORGEJO__database__PASSWD="${FJ_DB_PASS}"
      - FORGEJO__database__LOG_SQL="false"
      - FORGEJO__database__SCHEMA=""
      - FORGEJO__database__SSL_MODE="disable"
      - FORGEJO__indexer__ISSUE_INDEXER_PATH="/data/gitea/indexers/issues.bleve"
      - FORGEJO__session__PROVIDER_CONFIG="/data/gitea/sessions"
      - FORGEJO__session__PROVIDER="file"
      - FORGEJO__session__COOKIE_SECURE="true"
      - FORGEJO__log__MODE="console"
      - FORGEJO__log__LEVEL="info"
      - FORGEJO__log__ROOT_PATH="/data/gitea/log"
      - FORGEJO__security__INSTALL_LOCK="true"
      - FORGEJO__security__SECRET_KEY="${FJ_SECRET_KEY}"
      - FORGEJO__security__REVERSE_PROXY_LIMIT="1"
      - FORGEJO__security__REVERSE_PROXY_TRUSTED_PROXIES="${CADDY_INT_IP}"
      - FORGEJO__security__INTERNAL_TOKEN="${FJ_INT_TOKEN}"
      - FORGEJO__security__PASSWORD_HASH_ALGO="${FJ_PASS_ALGO}"
      - FORGEJO__service__DISABLE_REGISTRATION="true"
      - FORGEJO__service__REQUIRE_SIGNIN_VIEW="false"
      - FORGEJO__service__REGISTER_EMAIL_CONFIRM="false"
      - FORGEJO__service__ENABLE_NOTIFY_MAIL="false"
      - FORGEJO__service__ALLOW_ONLY_EXTERNAL_REGISTRATION="false"
      - FORGEJO__service__ENABLE_CAPTCHA="true"
      - FORGEJO__service__CAPTCHA_TYPE="cfturnstile"
      - FORGEJO__service__REQUIRE_CAPTCHA_FOR_LOGIN="true"
      - FORGEJO__service__CF_TURNSTILE_SECRET="${FJ_CFT_SECRET}"
      - FORGEJO__service__CF_TURNSTILE_SITEKEY="${FJ_CFT_SITE_KEY}"
      - FORGEJO__service__DEFAULT_KEEP_EMAIL_PRIVATE="true"
      - FORGEJO__service__DEFAULT_ALLOW_CREATE_ORGANIZATION="true"
      - FORGEJO__service__DEFAULT_ENABLE_TIMETRACKING="true"
      - FORGEJO__service__NO_REPLY_ADDRESS="noreply@${FJ_DOMAIN}"
      - FORGEJO__mailier__ENABLED="false"
      - FORGEJO__openid__ENABLE_OPENID_SIGNIN="false"
      - FORGEJO__openid__ENABLE_OPENID_SIGNUP="false"
      - FROGEJO__cron.update_checker__ENABLED="false"
      - FORGEJO__oauth2__JWT_SECRET="${FJ_OAUTH_SEC}"
      - FORGEJO__actions__ENABLED="true"
      - FORGEJO__actions__DEFAULT_ACTIONS_URL="https://git.${LAB_DOMAIN}"
      - FORGEJO__actions__ARTIFACT_RETENTION_DAYS="90"
      - FORGEJO__storage__STORAGE_TYPE="minio"
      - FORGEJO__storage__MINIO_USE_SSL="true"
      - FORGEJO__storage__MINIO_ENDPOINT="s3.${LAB_DOMAIN}"
      - FORGEJO__storage__MINIO_ACCESS_KEY_ID=${FJ_S3_ACCESS_ID}
      - FORGEJO__storage__MINIO_SECRET_ACCESS_KEY=${FJ_S3_ACCESS_KEY}
      - FORGEJO__storage__MINIO_BUCKET="forgejo"
      - FORGEJO__storage__MINIO_LOCATION="us-east-1"
      - FORGEJO__attachment__MINIO_BASE_PATH="attachments/"
      - FORGEJO__lfs__MINIO_BASE_PATH="lfs/"
      - FORGEJO__avatar__MINIO_BASE_PATH="avatars/users/"
      - FORGEJO__repo-avatar__MINIO_BASE_PATH="avatars/repositories/"
      - FORGEJO__repo-archive__MINIO_BASE_PATH="archives/"
      - FORGEJO__packages__MINIO_BASE_PATH="packages/"
      - FORGEJO__storage.actions_log__MINIO_BASE_PATH="actions/logs/"
      - FORGEJO__actions.artifacts__MINIO_BASE_PATH="actions/artifacts/"
      - /etc/timezone:/etc/timezone:ro
      - /etc/localtime:/etc/localtime:ro

With the environment variables updated, and a quick redeploy of Forgejo, I was up and running with object storage via MinIO! A quick trip into the Site Administration > Configuration > Summary in Forgejo shows that LFS was now using MinIO as seen in the below image.

Forgejo site admin config showing LFS using MinIO

Setting up Forgejo Actions

All jokes aside, Forgejo Actions is actually fairly decent. The runner is not production ready (according to Forgejo themselves) but it works well enough that I am going all in on it for my lab. Setting up the action runner was fairly straight forward. It’s got a similar setup process to the self-hosted GitHub runner.

Enable Actions in the app.ini or using environment variables. Restart/Redeploy Forgejo.

See above for an example using environment variables under #Actions Configs.

Create a new runner in Site Administration > Actions > Runners > Create new runner.
Copy the new runner registration token.
Deploy Forgejo Runner and register it with the token from step 3.

Now there are a few ways you could deploy the runner, but I decided to deploy it in Docker. You can bind the runner container to the Docker sock, but I did not. I really do not like doing that so, I ended up using Docker in Docker (DIND). It’s not really recommended to use Docker this way but for my lab it will do fine. The compose file was also pretty easy to set up.

forgejo-actions.yml


    command: ['dockerd', '-H', 'tcp://0.0.0.0:2375', '--tls=false']
    image: code.forgejo.org/forgejo/runner:3.4.1
        condition: service_started
    command: '/bin/sh -c "while : ; do sleep 1 ; done ;"'
    # Change to this command after registration
    #command: '/bin/sh -c "sleep 5; forgejo-runner daemon"'
      - DOCKER_HOST=tcp://dind:2375

As you can see above there are two commands:. '/bin/sh -c "while : ; do sleep 1 ; done ;"' starts up the runner container and does nothing. This allows you to enter the container via docker exec and run the registration command using the token generated in the Site Administration settings. After registering the container, it can be brought down and the current command can be replaced with the commented out one ('/bin/sh -c "sleep 5; forgejo-runner daemon"'). Then after redeploying the container the runner will become available in Forgejo globally. Having a global runner means it can be used by all repositories. Which for me works fine since my Forgejo instance is mainly private except for a few public repositories and a few GitHub mirrors.

Forgejo Manage Runners

With my runner online and working, I am now able to have workflows kick off from steps defined in files located in .forgejo/workflows/. The syntax is fairly similar to GitHub actions so most of the actions you can run there can run in Forgejo. The best part is I can mirror the action repositories and have my runner pull them directly from my Forgejo instance. The first thing I set up was Renovate Bot to keep my Docker images updated. The bot runs on a cron based workflow as seen below and opens a PR for image updates.

.forgejo/workflows/renovate.yml


    - cron: '0 0/6 * * *'  # every 6 hours, every day
  RENOVATE_REPOSITORIES: ${{ github.repository }}
    if: ${{ secrets.RENOVATE_TOKEN != '' }}
      image: renovate/renovate:full
          GITHUB_COM_TOKEN: ${{ secrets.RENOVATE_GITHUB_COM_TOKEN }}
          RENOVATE_BASE_DIR: ${{ github.workspace }}/.tmp
          RENOVATE_ENDPOINT: ${{ github.server_url }}
          RENOVATE_REPOSITORY_CACHE: 'enabled'
          RENOVATE_TOKEN: ${{ secrets.RENOVATE_TOKEN }}
          RENOVATE_GIT_AUTHOR: 'Renovate Bot <renovate@mydomain.dev>'
          GIT_AUTHOR_NAME: 'Renovate'
          GIT_AUTHOR_EMAIL: 'renovate@mydomain.dev'
          GIT_COMMITTER_NAME: 'Renovate Bot'
          GIT_COMMITTER_EMAIL: 'renovate@mydomain.dev'
      - name: Get Ntfy Token from SM
        uses: actions/sm-action@v4
        access_token: ${{ secrets.BITWARDEN_LAB_KEY }}
          some-secret-id-string > NTFY_TOKEN
          some-secret-id-string > LAB_DOMAIN
        uses: actions/ntfy-action@master
          url: 'https://ntfy.${LAB_DOMAIN}'
          headers: '{"authorization": "bearer $NTFY_TOKEN"}'
          details: Renovate Bot failed to run!

The bot is configured via a renovate.json file located in the root of the repository.

renovate.json


  "$schema": "https://docs.renovatebot.com/renovate-schema.json",
  "extends": ["config:base"],
  "assignees": ["alexandzors"],
  "dependencyDashboard": true,
  "labels": ["maintenance"],
  "enabledManagers": ["docker-compose"],
    "fileMatch": ["^.*\\.yml$"]
      "managers": ["docker-compose"],
      "depTypeList": ["services"],
      "datasources": ["docker"]

At the moment I have it scanning through all YAML files since I do not name my compose files docker-compose.yml. They are named as the service so: forge.yml, caddy.yml, authelia.yml, etc. They are also located in their own folders. This will be changing as I move more to GitOps but for now it’s fine.

PR Opened by Renovate Bot using the Forgejo Action workflow

Conclusion

This was a fun project to work on in between work and family stuff. Hopefully this inspires one of you to upgrade your own local git setup with an ‘Actions’ runner or object storage! I’ll have a full config dump for MinIO, Forgejo, Forgejo Actions, and an example workflow in the blog-files repo.

On to the next project. 🚀

Rebuilding My Home Lab

2026-05-03T10:46:07Z

_{FTC: Some links in this post are income earning affiliate links.}

It’s been a while since I last posted about my homelab or well posted on the blog. So I figured I’d start off with a banger for 2025. Rebuilding my homelab into a Docker Swarm cluster that supports high availability. Hope you’re ready for a ride, because this was definitely a journey. 😅

_{Side note: I also recently acquired a Bambu Lab A1 3D printer (with the AMS :)) to replace my old Anet A8. I’d say it’s mine, but I’ve only been printing stuff for my wife so far..}

The Plan

The plan for this project was to:

Create a cluster that supported high availability ✅
Setup a distributed storage solution that supported the above ✅
Setup a load balancer ✅
Have the cluster communicate over 2.5gb or faster networking ✅
Have a minimum of 3 nodes ✅
Be small and efficient ✅

Easy enough right?… right?

Since I had two Dell Optiplex 5050 Micros that I was using already, I decided to grab a third micro to complete the 3 node cluster. As for the actual orchestration software I decided to stick with Docker and use Docker Swarm. I’m a Docker guy but never had a chance to use Swarm properly with a shared storage system. Figured it was time to give it a proper go.

Wait… Docker Swarm? Alex you should use Kubernetes!!!!!!

Current v2 Cluster Specs

2x Dell Optiplex 5050 Micros
1x Dell Optiplex 7040 Micros
3x Realtek 8125B 2.5gb A+E NICs
3x Intel 700p 256GB SSDs
3x Crucial BX500 1TB SSDs
Ubiquiti Flex-2.5g Switch
Ubuntu 24.04 LTS
GlusterFS

Cluster v1

_{circa 2023}

Cluster v1 never actually made it to ‘production’. It ended up being a test bed and a learning experience on gotchas when it came to Linux, Intel, drivers, and poor research on my part…

TLDR: I originally bought some Intel i225-v 2.5gb m.2 cards from IOCrest thinking they’d work. Come to find out these particular chips have some driver issues on Linux (specifically Ubuntu).

When originally designing the cluster I had planned on using M.2 2.5g cards since the Micro’s had M.2 M-key slots. That way I could get a less expensive SATA SSD for storage. After doing some research I settled on some Intel 225-V 2.5g cards from IOCrest on AliExpress. The one downside to these cards was the vertical connector pins. The chassis did not have enough space with a SATA SSD installed. So I did what any tinkerer would do and replaced the pins with right angle ones. The first two cards went good, but my old soldering iron doesnt keep temp well. On the third card’s NIC module I messed up and destroyed one of the traces. So I had to fix it with a jumper wire. Live and learn I suppose.

As for the NICs themselves, I started experiencing driver issues after getting two of the nodes up and running in a ‘mock’ swarm. These issues manifested as random disconnects or complete NIC power loss. I tried to fix it by messing with grub configs for pcie_aspm thinking it was related to Active State Power Management (ASPM) at first. I then tried manually setting the autonegotiation via ethtool. Also double checked UEFI settings, etc. Nothing seemed to work. So I ended up scrapping the Intel cards and going with Realtek 8125B cards for cluster v2.

Anyways, I’ll leave you with a few pictures from the v1 prototype, and we can move on to v2.

Cluster v2

_{circa 2024}

My second attempt at the cluster faired a bit better. Well mostly (more on that later). After my first purchase mistake I went back and bought different M.2 adapters. These were A+E keyed and used the WLAN slot rather than the M.2 M-keyed slot which got freed up for more storage. These new adapters also use a Realtek chipset (8125B) rather than an Intel one. So no more odd driver issues.

M.2 A+E keyed adapter installed

With the new adapters using the A+E slot, I decided to use the M slot for a boot drive and the SATA port for cluster storage. For the boot drive I went with some Intel 700p 256GB SSDs I bought off someone from the Ubiquiti Discord server. As for cluster storage I went with 1TB Crucial BX500 SSDs from Amazon. These are not the fastest drives by any means but for my use case they should do just fine.

Storage SSDs

There was one downside to the Intel SSDs though. Their physical size. They are 2230 and the Micro chassis only supports 2260 and 2280. So in order to use them I had to print out some 2230 to 2280 adapter brackets. I also printed out a 2.5in tray for the third Micro since it did not come with one. The print files are linked below.

The OS

For the OS I decided to stick with my tried and true Ubuntu Server (24.04 LTS btw). It’s stable and easy to manage. Though, I may eventually re-image to Rocky Linux for easy live patching when I rebuild again. The process was pretty standard. I booted via my netboot.xyz PXE server, ran through the installer and then used Ansible to configure the OS. I’ll have the playbooks + task files in the blog-files repo after this post is live.

Your browser does not support webm.Ansible playbook running on the cluster nodes

Networking

After the OS was set up on all the nodes, I went ahead configured the network interfaces. During the v2 build Ubiquiti launched their Flex 2.5g switch line. Since this was an SFF cluster the Flex Mini 2.5g was a perfect fit as the cluster’s network backbone. Also with it being powered by POE made for one less cable to deal with. The cluster network is also a fairly simple one. It has no access to the internet and no access to any other networks. Other networks also can’t access it. Don’t need stuff snooping on my unencrypted SQL traffic..

With the network interfaces configured and working, it was time to test the speed using iperf. As you can see by the short video below, I was able to get roughly 2.5gbps of bandwidth between the nodes.

Your browser does not support webm.iperf testing

Distributed File System

This was probably the most difficult part of the cluster build. At the time I had really no experience dealing with distributed file systems. I narrowed down my options to GlusterFS and Ceph. I ended up going with GlusterFS for this iteration. Using the official documentation I was able to get a basic cluster up and running fairly quickly. I also created a dedicated Docker user ‘doc’ and set its home directory to the GlusterFS volume on each of the nodes. I thought this would be a great idea, but it ended up being a pain later on.

GlusterFS setup

Docker Swarm

With the OS, Networking, and DFS setup, it was time to set up Docker Swarm. Setting up Docker and Docker Swarm is fairly straight forward using the official documentation. You basically follow the installation on each of the nodes. Then you initialize the swarm on one and join the other nodes to it. In my case my commands were:

Terminal window


sudo docker swarm init --advertise-addr 192.168.100.2 ## init the swarm on the cluster network interface
sudo docker swarm join --token SWMTKN-1-4c2d6gncjh15gaznem5m8t2twwfn09o0paqpjxwdkqr1n76h8j-chr42vcbaobx7v2nrk86q9e93 192.168.100.2:2377 ## joining other nodes to the swarm

I then promoted the other two nodes to managers. This way I had proper high availability as it requires a minimum of 3 managers to be in the swarm.

Docker Swarm cluster

Keepalived

Next up was setting up Keepalived to handle VRRP for the cluster. This allowed me to have a single IP address that automatically failed over to the next node automatically. The video below shows the failover in action (sped up to keep the video short).

Your browser does not support webm.Keepalived VRRP failover

As you can see the active node switches as each keepalived service is terminated. The lower right shows a constant ping to the VRRP virtual IP (VIP). In this case 10.8.8.11. Having this VIP allows me to bring down hosts for maintenance or updates without having to worry about service connectivity.

HA Caddy

The final step before I could start using the cluster was to set up a load balancer/reverse proxy. There are a few different options but, if you’ve read any of my previous posts you know I love using Caddy. With its easy-to-use configuration and automatic certificate management makes it hard to beat. Also, Caddy is a great choice for this since it automatically clusters itself if all instances use the same storage volume.

First thing I did was create the new overlay network for Caddy. This network would be for any services that I wanted to be able to access from outside the cluster.

Terminal window


sudo docker network create --opt encrypted=true --driver overlay --attachable --internal --subnet=172.0.96.0/20 caddy-internal

Creating the Caddy service file.

caddy.yml


    image: alexandzors/caddy:2.9.1
      - /swarm/volumes/doc/caddy/Caddyfile:/etc/caddy/Caddyfile:ro
      - /swarm/volumes/doc/caddy/.data:/data
      - /swarm/volumes/doc/caddy/configs:/etc/caddy/configs:ro

Then deploying Caddy to the swarm.

Terminal window


sudo docker stack deploy --c caddy.yml caddy

docker service ls command showing Caddy running on all 3 nodes

I eventually need to update the Caddy deployment to use host mode for port assignments. That way I can get the source IP address of incoming requests and not the docker proxy IP. But that will be part of v3.

Cluster v3

_{circa 2025}

So here we are. Cluster v2 has been running great for a while now, but I’ve been having some issues with it. The main, and arguably the largest, issue I have been running into is the slow performance of GlusterFS. I’m not sure if it’s the hardware choices I made, or a misconfiguration? I tried the performance tuning tips from the official documentation but was still running into issues. Like switching to the cluster user ‘doc’ would take anywhere from 30 to 45 seconds to complete. Also, deploying stacks of services could take up to 5 minutes before they were alive and running.

Either way for v3 I’m probably going to move to Ceph as my DFS solution. Since it seems to be the more popular of the two after digging around more. I may need to upgrade the RAM on the nodes to handle it though. I’m also going to try and add a 4th node to the cluster with beefier hardware since I still have one 2.5g port left on the switch. Maybe one with some GPU compute to handle local LLMs?

Current services running on the cluster

However, what won’t be changing is my use of Docker Swarm. 😉

How to smoke

2026-05-02T05:49:10Z

The best part of smoking was always the click of the Zippo.

This week’s question comes to us from Mat Honan:

I used to love to smoke. If it weren’t for the whole lung cancer, emphysema, death thing, would you recommend smoking?

You’re forgetting the smell.

Last week I was coming back from the record store and feeling lazy, so I jumped on the bus. A couple of stops after I got on, a dude got on and sat down next to me. Well-dressed dude, also carrying an Amoeba Records shopping bag. Out and about on a Sunday afternoon, doing his record shopping just like me. Within seconds it became clear this dude had just had a cigarette. And he stunk. The bus was also packed at this point, so I was pretty much stuck in that seat until I got off, which luckily wasn’t for too much longer. Also, it feels kinda shitty when you sit down next to somebody on the bus and they immediately get up. (Unless you’re getting a creeper vibe, of course.) I just had to suck it up for a few more stops. But man, it was rough. I’m not trying to disparage the guy or anything. Especially because I used to be that guy, and you used to be that guy, and I’m guessing a lot of our readers used to be that guy. We just walked around smelling awful.

Which is not to say that’s the worst part of smoking, but you took lung cancer, emphysema, and the dead thing off the table. Which leaves us with the smell.

I started smoking my freshman year in college. All reasons to take up smoking are stupid, but this one might be the stupidest. This being the mid-80s our dorm had a cigarette machine in the lobby. One of those old machines you might still see in old man dive bars, with two rows of big ka-chunky knobs, which felt objectively good to pull. It was like you could feel the entire mechanism of the machine come to life when you pulled that knob. And it took some strength to do it! But you could feel the knob hit a gear, you could hear the gear spin, you could feel a pack of cigarettes get pushed free from deep inside the machine. You could hear it slide down a little ramp, and then you’d see it appear down in the landing zone, where you’d push your hand past the trap door, grab it, and somehow have the pack open, and a cigarette in your mouth before the rest of the pack hit your pocket.

If memory serves, a pack of smokes was between $1.25 and $1.50 around that time. (Fun fact, I attempted to Google this and the slop top on the search results page said 26¢ a pack, which is… not true. But please, continue to rebuild society around such amazing technology.) Being the art school miscreants that we were, and also broke, we discovered that if you pulled a knob halfway out, inserted a quarter, and then pulled the knob the rest of the way out it would release a pack of cigarettes. (Ok, that may not have been the actual process, but it was a long time ago, and it’s very close to the spirit of the actual process, so let’s run with it. So I guess we were getting a pack of cigarettes for what Google’s stupid slop robot said, but it included doing crimes.) The knowledge of how to hack the cigarette machine spread through the dorms like wildfire, and soon we were all smoking. Because we were idiots. Also, it felt like we were getting one over on The Man. But mostly because we were idiots.

Also, being art school kids we were very visually-driven people, and all the photos of cool people that we’d hang up in our dorm rooms showed them holding a cigarette. And we very much wanted to be cool people. (True fact: take a photo of Humphrey Bogart, replace the ever-present cigarette with a vape and Humphrey Bogart will look like an herb.) Again, mostly we were idiots.

The vending machine company tried to patch the hack several times, eventually gave up and just took the machine away. This was our first lesson that sometimes doing crime is in the public interest, but that lesson didn’t occur to us right away. At the time, we were just pissed that we had to pay retail for cigarettes again.

By the time I started smoking society was pretty much done with the pretense that smoking was doing anything but murdering you slowly. I know this because we’d sit around in art classes making collages using old cigarette ads where doctors would tell you smoking was good for your nerves, and we would laugh at people for believing this, as we lit cigarette after cigarette. (Yes, you could smoke in class.) And we thought “Boy, our grandparents sure were chumps for believing cigarettes were healthy.” Then we would have a coughing fit. But there was definitely the sense that doing this thing that we all knew had a very very high probability of killing us wasn’t a big deal, mostly because we were in our 20s when nothing can hurt you, Reagan was president and, just to reiterate—we were idiots.

My first post-college job was at a copy shop, and you got one 15 minute break during your shift. Unless you smoked, then you could get as many breaks as you needed. Several people started smoking while working there.

We all stunk. We’d come in from smoking out back, and immediately walk up to the service counter to help a customer. A customer who either stunk as bad as we did, or had become inured to the stench because it was all around them, emanating from everyone.

We smoked in class. We smoked at the movies. We smoked at the supermarket. We smoked at sporting events. My friend Jeff, who grew up in Boston, tells a good story about going to Celtics games as a kid and having to look past the hovering cloud of smoke between the cheap seats and the court. We smoked in restaurants, where the smoking and non-smoking sections were often divided by nothing more than a paper sign denoting the territorial boundary. We smoked on planes, man.

It wasn’t too long after college that the world began to shift. In 2003 New York City banned smoking in bars. And I was visiting at the time. By 2003, I was no longer “a smoker” but I was very much someone who would look for reasons to bum a smoke from someone if the situation arose, and very likely to put myself in situations where it might. But I remember the rage from several friends and from the owners and bartenders of any bar we’d walk into. The ban was going to kill bars all over the city. It was going to kill nightlife. It was going to completely take down the economy. New York, as we know it, would cease to exist. Which of course, it didn’t. Everyone adjusted. They went outside. They eventually started smoking less because it was cold outside. People enjoyed being able to hang out in rooms that weren’t making them sick, and they enjoyed going home not reeking of cigarette smoke. If I could go back in time I’d reassure all those bartenders that it wasn’t the smoking ban they had to worry about. It was the kids who’d stop going out at all because they needed to sit at home and tend to their AI agents.

I selected your question this week because I’ve actually been thinking of the smoking ban lately. We grew up in a time when smoking, or dealing with other smokers was an inevitability. Even if you didn’t smoke, you’d most likely work next to someone who did, or sit down next to someone who did at a restaurant, or at the movies. And even if they weren’t actively smoking, and covering you in second-hand smoke, you’d go home with the stench of smoke all over you. Airing your clothes out was an inevitability. Having to wash the stench out of your hair was an inevitability. Society smoked, so you did too. Whether you wanted to or not. And then it changed. Most cities in America now have smoking bans and rules about how far away you have to be from a public entrance to smoke, which get enforced to various degrees.

The change came in a couple of very interesting ways. One, cigarettes are now hovering between $12 to $14 a pack. (I had to look this up!) They’re also available in less places. (You used to be able to buy cigarettes at the drug store!) Secondly, people just look at you weird if you start smoking now. Like, what the fuck dude, did you just light a cigarette!? Are you from the past? Gross.

Which of course makes me think of some of the things that we have currently accepted as a society, things which we fully know are not healthy for society, that we are currently tolerating. And also thinking there’s no way it will ever change, because we appear to be in an era of “what if everyone modeled themselves off the stupidest people?”

Right now there is someone firing up ChatGPT because it’s cheap. Right now there is someone writing a prompt in Claude because it brings him closer to his co-workers. Right now there is someone walking a co-worker through his agentic workflow, in the same way we attempted to impress one another by blowing smoke rings. Right now there is someone parking a Cybertruck on your street, believing that leaving his divorce where everyone can see it is somehow impressive. We have always been good at ignoring the warnings that came with the pack.

Our parents packed their homes with asbestos. They heated their homes with coal. They packed their Big Macs in styrofoam. Making mistakes will always be cheaper than fixing them. But nothing is more expensive than ignoring them.

Cultural norms are an ever-changing thing. History is the story of what was once desirable becoming unacceptable. Something that used to be an inevitability is no longer inevitable. Something that used to be tolerated is no longer tolerated. Something that was seen as a cultural norm no longer is. Even when those things were backed by entire industries with very strong lobbies, as the tobacco lobby once was. The same fate will someday befall the NRA. The same fate will someday befall AIPAC. The same fate will someday befall the slop lobby.

There was a time we thought if we prohibited people from smoking in bars it would lead to societal collapse. I think it was a good idea. More importantly, it was an idea that worked. It improved not just our personal health but the health of our communities.

The basic strategy of all addictive technologies is very simple. They make you feel extra capable, they addict you, then they make you feel inadequate without them. They start by making you feel cool, and confident. Relax. Put your feet up. Hang with the fellas. Social anxiety? It’s toasted, dog! Let me write that résumé for you. Anniversary card for your wife? I can write that for you. Light one up. It’s a great way to start a relationship. But that initial boost eventually turns to reliance, and suddenly you can’t get out of bed without a hit. You can’t write your kid a love note without firing up a slop engine. And suddenly an entire industry is telling you that you’re not capable of moving through your day without their help. An entire industry gaslighting you, until it becomes easier to just gaslight yourself into believing that you were never truly capable of things you are very much capable of.

I don’t miss smoking. Maybe I did at one point. But eventually the whiff of cigarette smoke went from smelling nostalgic to just smelling bad. Thankfully, knock on wood, I’ve been able to escape years of smoking without any major lasting effects, but trust that I carry every pack I ever smoked with me every time I walk up a flight of stairs. If I’m doing anything strenuous, it’s always my lungs that give up first.

Thankfully, I still have some lung capacity. I enjoy using it. You should too.

🚬

🙋 Got a question? Ask it! I will somewhat answer it!

📓 Get your sexy copy of my new book How to Die (and other stories)! And if you’re in the Bay Area, come see me and Annalee Newitz talk about it on May 11 at Booksmith!

🚢 My friend Lucy Bellwood made a wonderful comic about loss and building.

🙅 My friend Jason Cosper made a great tool for fucking with Substack’s dollar.

📣 I’ve got a few seats left in next week’s Presenting w/Confidence workshop where you can learn true confidence. The one inside you.

🍉 Please support the children of Palestine.

🏳️‍⚧️ Please support trans kids. And if there is a trans person in your life please tell them you love them.

Crashing hard: why talking about bubbles obscures the real social cost of overinvesting into “Artificial Intelligence”

2026-04-27T08:11:01Z

More and more commentators talk about and warn of an “AI bubble”, and everybody seems to congratulate each other on being such a smart financial analyst. BUT: A bubble pops and you are left with air and maybe a splash of soap somewhere on the floor. A fairly clean affair. This kind of investor speak obscures the severe consequences economic crashes cause, coming from someone’s point of view for whom this is more likely to be a spectacle than a direct threat.

When the “AI” market crashes, there will be NO “reset button”, NO “rollercoaster” continuing on an orderly path after having come down, NO “bubble” that just lets off hot air. These are all metaphors that heavily misrepresent what it means for markets to crash, or, as they say, “correct”. We might be in for a long and painful struggle to at least reduce the grip of “AI” on current core societal functions like government administration, education and research funding. In this article, I want to illustrate the broad range of costs that BOTH the buildup of “AI” overvaluations AND their coming down will have. The current “AI” investments will have long-term costs by creating significant path dependencies: They make harmful things cheaper, speed up the commodification of human labour and shift social norms. Just to be clear: I am referring to the current “AI” boom which is driven mostly by generative AI (“genAI”) applications, not necessarily the things that have been around for decades (e.g. various forms of pattern recognition) and that did not induce companies to spend hundreds of billions on data centres.

To better understand what is going on, let’s first look at the outcomes of previous instances of overinvestment, including the 2000 dot-com “bubble” and the significant piles of money Uber burnt for many years, before turning to contemporary “AI” path dependencies.

Overinvestments shape technological paths

Let’s start with the obvious: The so-called dot-com boom crashed between 2000 and 2002 – this already hints at the fact that “bubble bursting” is a long period during which no one knows when it will end. When it did end, investors lost money, and it is mostly their perspective that was covered in the media (and they whined about a crash being less bad than the pain inflicted by missing out on a boom). Many people lost their jobs, their livelihoods, and needed to find other ways to make ends meet (developers on Reddit gave an account, but they were probably among the more privileged). Unemployment in the US increased from about 4% to almost 6%.
What might be a little less obvious: A few key developments that the dot-com boom had started persisted long after. While the internet was still a mostly academic affair until the 1990s, the dot-com boom kicked off the scale-over-everything, ad-based internet we know today. We saw alignment of advertising business and finance as well as a massive drive to consolidation during the crash. Google, eBay, Amazon, Nvidia, they all became central players in the commercial internet. What now seems inevitable to most people seemed coincidental before the boom – but then today’s driving forces crowded out most other, less commercial forms of existing on the internet.

“AI” investments make harmful things cheaper, speed up the commodification of human labour and shift social norms.

The investment logic has shaped the internet ever since: Uber accumulated almost $34bn USD in losses (excluding losses while it was not yet public between 2009 and 2014) before it started to generate profits in 2023. (And also various other unicorns incur massive losses they may never recoup.) Money also creates habits and legitimises actions: Uber “broke laws, duped police and secretly lobbied governments”, as the Guardian titled in 2022 and its controversies got their own Wikipedia page. But also their very official business model is based on a) normalising precarious working conditions by eroding labour protections as they fought countless lawsuits over giving their workers only freelance and not an employee status, thereby avoiding sick pay, holidays etc., and b) making human work seem more automated and less visible by mediating passengers and drivers through an algorithm in an app, reducing the need for actual human interaction. Both developments shift social norms in ways that are likely to be profitable for businesses even beyond Uber: Uber’s mission can be understood as reducing the value of workers and human interaction, and with that long-term goal it is commercially rational to rack up significant losses in the short to medium term.

The “AI” path dependencies we will not correct

It is plausible to expect something similar to happen with “AI”. The ongoing investment boom is creating significant overcapacity with effects lasting long after many “AI” startups have gone bust. These range from very visible and direct to the more indirect and structural.

Lower costs for compute and energy: In order to sustain the boom, investments follow projections of endless “AI” growth, which translate into hundreds of billions currently being invested into data centre construction, alongside an expansion of energy infrastructure. And once they are built, it does not make sense to stop them, does it? Keeping them running is much cheaper than constructing them. This puts us on a path of energy-intensive technology even once these data centres are no longer needed for “AI” applications. This eradicates any incentive for resource-efficient coding or low-computation technology. At the same time, this infrastructure is not costless to maintain (to my knowledge, chips need to be replaced about every 7 years) – but possibly that cost is still lower than doing anything else, hence continuing on that trajectory will remain cheaper than alternatives for quite some time to come. These artificially low costs of compute and energy will be even further away from the “real” costs when factoring in just the environmental harms they produce. That is very bad news for anybody still hoping for a combined digital and environmental transition.

Sectoral knowledge destruction: Some people may get used to using “AI” for a variety of tasks, even where this is neither actually helpful nor profitable for the “AI” providers. As is widely reported, managers often encourage or force their employees to e.g. code using genAI applications, university students use genAI applications for writing, public bodies are continuing to move onto fancy “AI” clouds and forget how to do on-premise computing, and we are likely to see more diffusion before the boom crashes. Just as Uber’s mission was broader than just individual transport, “AI” has an inbuilt contempt for human interaction (as it is built to automate speech while avoiding any interpersonal friction) and workers (as it seeks to make them even more interchangeable and subordinate to machine processes). Hence, using “AI” often destroys established processes of developing skills and sharing knowledge. Rebuilding them will take much longer and possibly cost more than might have been saved in the meantime.

Again more economic inequality: An economic crisis is not equally dangerous for everyone. Only few companies are benefitting from the “AI” boom and most of the stock market gains in recent years were driven by Big Tech valuations going absolutely through the roof. However, we can expect that the losses will be shared more widely, based on the experience of past financial crises. Big Tech is trying to portray itself as too big to fail, which means that their systemic relevance would prompt governments to inject tax money to reduce any losses they might incur. A financial crisis has ripple effects that go far beyond the market in question – just as the 2008 US housing crisis did not only lead to people losing their homes, but caused a huge recession with a stark increase in unemployment and financial instability.

Why “AI” overinvestments might take a long time to unwind

There is no way of knowing when the “AI” boom is likely to crash – that is the whole point of markets that are supposed to create collective rationality from individual choices. I see a few reasons to suspect an even longer and more painful struggle than the dot-com crash in 2000. First, the boom is orchestrated or arguably planned by a handful of extremely powerful companies. Being few increases the scope to act strategically. Second, these companies are very close not only to the US government, but through their start-up investments also to governments across the world, selling “AI” promises and lies to politicians. The push of small and large “AI” firms into military tech aggravates this dynamic: It is the area in which talking of an “AI race” carries quite intuitive meaning because having more destructive power translates into military power, though not necessarily into better societal outcomes. And third, the intention of reaching systematic relevance is bearing some fruit as more and more institutions are becoming financially invested into “AI success”. Not only VC investors, but large parts of society including life insurance and pension funds will bear the cost of its failure, giving them an incentive to prolong the boom at fairly high costs.

There are a few reasons to suspect an even longer and more painful struggle than the dot-com crash: market concentration, closeness to governments, and financial actors being invested into “AI success”.

What to do and why not to despair

It is important to analyse the abyss, but don’t stare into the abyss, as Jathan Sadowski sometimes says on my currently favourite podcast This Machine Kills. Understanding what is happening is essential to figure out a plan and I am keen to do that with others (i.e. I am aware my suggestions are insufficient). Anything that contributes to not making the boom bigger than it needs to be is helpful (e.g. do not invest into “AI”, tell your friends not to, do not use genAI applications or pay for them). Anything that helps us to talk in less delusional terms about what is going on is helpful (e.g. do not join those talking about “bubbles” suggesting they are merely financial events or that have one moment of coming down after which everything will be okay again). And let’s try to preserve that knowledge that companies are keen to replace with “AI”. We will need it.

Photo by Maxim Hopman on Unsplash

Wrap Text Around Images with CSS shape-outside

2026-04-25T17:37:09Z

Make your text wrap around images perfectly.

By default, text wraps around a boring rectangle. But what if you could make it hug the actual shape of the image?

You can. With just one CSS property:

shape-outside: url(your-img.png);

Add a float and a bit of margin with shape-margin, and your layout feels instantly more refined.

No JavaScript. No layout hacks. Just native CSS support and it’s supported in over 95% of browsers.

Use it with transparent PNGs, SVGs, or even basic shapes like circle() or polygon(). Ideal for editorial layouts, landing pages, or any design that needs more personality.

Checkout the codepen: https://codepen.io/theosoti/pen/ogjjged

shape-outside can produce elegant editorial layouts when image silhouettes stay simple. Test long paragraphs and varied image ratios, because float-based wrapping can become fragile in edge cases.

shape-outside can create editorial layouts with strong flow, but test with varied image sizes and long text. Float-based wrapping can break faster than block layouts.

Use this as a readability tool, not only a visual effect. The best result is when style improves scanning speed without adding cognitive load.

To roll this out safely, start by applying shape-outside: url(your-img.png); in a single UI surface where the benefit is obvious. Then reuse that same pattern in similar contexts so behavior stays consistent and review time stays low.

Before shipping, test shape-outside: url(your-img.png); with both short and long content, then verify behavior in narrow and wide containers.

If you liked this tip, you might enjoy the book, which is packed with similar insights to help you build better websites without relying on JavaScript.

Go check it out https://theosoti.com/you-dont-need-js/ and enjoy 20% OFF for a limited time!

Why The Split? - MeshCore Blog

2026-04-24T04:36:09Z

Since inception, the MeshCore development team have been working hard to build MeshCore.

We’ve released more than 85 versions of the MeshCore Companion, Repeater and Room Server firmwares with support for more than 75 hardware variants. All of this has been hand crafted, by humans.

We have always been wary of AI generated code, but felt everyone is free to do what they want and experiment, etc. But, one of our own, Andy Kirby, decided to branch out and extensively use Claude Code, and has decided to aggressively take over all of the components of the MeshCore ecosystem: standalone devices, mobile app, web flasher and web config tools.

And, he’s kept that small detail a secret - that it’s all majority vibe coded.

We ran a poll recently, and asked in the MeshCore Discord about AI and trust, and these are the results:

The team didn’t feel it was our place to protest, until we recently discovered that Andy applied for the MeshCore Trademark (on the 29th March, according to filings) and didn’t tell any of us. We have tried discussing this, and what his intentions are, but those broke down and we now have no communication with Andy.

It’s been a stressful few months trying to sort this out, and is now a sad day to bring this out to the public. It’s been a slap in the face to the team that have worked so hard on this project, to have an insider team up with a robot and a lawyer.

“Official” MeshCore

The use of the ‘official’ status is what is currently being contested. Andy is adamant that he owns the brand, and is using the word very heavily with his MeshOS line.

Meanwhile, in reality, the only ‘official’ MeshCore is the github repo. It’s the source of truth in terms of what is MeshCore, and Andy has never contributed to that.

Since the internal split, we launched the meshcore.io site, as Andy controls the meshcore.co.uk site and original discord server. We’ve been left with little other recourse. And, since launching the site, Andy copied the look and feel (again, using Claude) even though we asked him not to.

Project Growth

The MeshCore project has been on an incredible journey.

Having only started in January 2025, we have grown extremely fast!

As of this post, the official MeshCore Map shows 38,000+ nodes around the world, and the official MeshCore App has more than 100,000+ active users across Android and iOS.

It’s pretty epic how we’ve all built such an incredible community in such as a short time!

As the project grows, so does our need for a dedicated space that provides you with official information from the core team.

In recent times, we’ve seen an explosion of growth in MeshCore web sites dedicated to specific countries and mesh communities.

To name a few, we’ve seen:

Andy Kirby did do an amazing job helping to promote the MeshCore project on his personal YouTube, but only promotes his own products now.

Where To From Here?

So, the core team are pushing ahead with the meshcore.io website, the ongoing work of firmware feature development, bug fixes, managing PR’s and developer discussions, etc.

We now release change logs, blog posts and technical documentation for all of our new firmware and app releases here.

You’ll also find some familiar faces on our blog posts, such as:

Scott our project founder, lead firmware engineer and developer of the Ripple firmware!
Recrof our official MeshCore Map developer and Firmware Flasher guru. He has shared some insights into the early development of the MeshCore Map.
Liam Cottle the official MeshCore App developer who will be posting useful guides for getting started with the MeshCore App.
FDLamotte who has done epic work on the Python tooling for MeshCore, as well as the STM32 firmware variants.
Oltaco (Che Aporeps) who has done amazing work on the new OTA Fix bootloader that makes firmware updates much more reliable.

The Core Team

The MeshCore team, now consisting of Scott, Liam, Recrof, FDLamotte and now Oltaco remain committed to designing and developing high quality, human-written software.

Our New Home

Please update your bookmarks!

This is where we will be hosting all official releases, technical documentation, and community discussions moving forward.

With the new website, we are also starting fresh with a new Discord server!

This is where you can interact directly with the MeshCore developers, get help with your projects, and contribute to the future of MeshCore.

Thanks for being a part of this journey!

The MeshCore Team

How to Stop A Data Center in Your Backyard ~ L.A. TACO

2026-04-23T13:10:47Z

When the people of Monterey Park found that their local government was going to approve a 250,000-square-foot data center just 500 feet from their homes, they organized.

And within a few months, the developer withdrew their application.

Andrew Yip, an organizer with SGV Progressive Action, tells L.A. TACO that the organization’s success started with their “existing network of volunteers,” noting that “the community was able to jump in at a moment's notice.”

SGV Progressive Action was founded in 2020 to “address the Black Lives Matter uprisings," Yip says. "To support our Black community."

Then it organized local resolutions advocating for a ceasefire in Palestine, and built a lending library in El Monte called Matilija Collective, where they trained volunteers in community defense against ICE, hosted organizers, and stored 20 canopies and a speaker system.

"So that existed," Yip says.

In November, a community member who had come to a council meeting for other business saw the data center on the agenda and called on SGV Progressive Action.

"They asked if we can take a look at this," Yip says. "And see if that's something that communities should be concerned about."

All that was needed was one last council vote. But the developer requested a delay to the next meeting.

"Had they voted that day, it would have been done, right? It would have been done," Yip says. “But we found out about it, and we turned out hundreds of people to the next meeting.”

CA PUBLIC RECORDS ACT

Under California's Sunshine Laws, local governments are required to turn over agendas, meeting minutes, attendance records, and emails. SGV Progressive Action immediately filed public records requests.

"That's really how we found out," Yip says.

The records showed city planners had given their blessings to the data center, saying it would not result in any “significant environmental impacts.” They had used the developer's own impact assessment in place of a more thorough state environmental review.

The records also showed the city had held a series of community meetings to ask residents what should be built at 1977 Saturn Street, but only notified people living within 500 feet. Each meeting drew between 20 and 60 people. Residents who were there told Yip and other organizers that the city clerk brought in people who backed the data center. It won with roughly 20 votes.

“Twenty-something votes determined [that] residents here wanted a data center,” Yip says. ”That just seemed like a weird recommendation coming out of a community town hall.”

Council Member Thomas Wong, who would vote for having the data center, also works at the power company that would sell its electricity.

The developer also bought a larger property at 1980 Saturn Street across the street. The data center trade magazines reported that these were part of a 13-parcel assembly, all meant for data centers. Yip asked the developers what they planned to do with 1980 Saturn; they said they were not authorized to discuss it.

NO DATA CENTER MPK & THE INFORMATION CAMPAIGN

The residents of Monterey Park bought the domain No Data Center MPK.

“And we had a ton of people come out to support, whether it's walking the neighborhoods, distributing fliers, calling folks, creating artwork,” Yip says. “It was a big showing.”

They went door-to-door to tell their neighbors what the city had not told them: The data center would use twice as much electricity as all of Monterey Park. The 14 “backup” generators would burn 200,000 gallons of diesel every year, without a blackout. And more when the grid price was high.

They held a teach-in. 150 people came.

“We have a lot of very smart residents who were able to do a lot of this research and fact-finding. Many of the residents we work with are researchers or hold PhDs, and they work in universities. So they know how to find this information,” Yip says.

One resident 3D-printed a model of the data center to show just how much of the neighborhood’s space it would take up. Another resident mixed noise recordings from data centers and played them over a loudspeaker. You couldn't hear the birds.

Two dozen people in Virginia who lived near a data center were ready to fly out to testify on their own dime.

“Virginia became ground zero for data center proliferation,” says Yip. “The people didn't know enough about data centers at the time.”

The vibrations and noise never stop, the people from Virginia warned. The reported sound levels of 60db and higher are far from the data center. They have taken to sleeping in their basements. Neither a decibel meter nor the law measures vibration.

Yip and the organizers found that almost nobody in Monterey Park that they spoke to had heard of the data center. The city’s notification had only reached 40 people living within 500 feet of its proposed location, in English.

The neighborhood is 65 percent Asian and 27 percent Latino. The community’s outreach was done in at least three languages, five when necessary. It extended to all the surrounding neighborhoods.

“Data centers, their pollution, and their effects don't just stop at the border,” Yip says.

They started a petition in English, Chinese, and Spanish. It grew to 4,500 signatures.

THE DEVELOPERS & THE DISINFORMATION CAMPAIGN

The developers retained a law firm with 1,000 attorneys on four continents. They hired Actum, the lobbying firm that represents Amazon and Clorox. Actum lists Trump’s former chief of staff as a partner and another who exploited a loophole so large that California had to legislate to close it.

"The applicant sent a letter to the city council talking about misinformation being spread, and that was exactly what the council members said," Yip tells us. "They just parroted the same talking points."

The political lobbyists canvassed neighborhoods and local shops.

"One of the public benefits of the project they were touting was a pocket park ... The pocket park is basically just leftover land on their property that they didn't really need for the data center," Yip says.

They promised 200 jobs and, in the same conversation, no traffic.

“Our people would poke holes in it,” Yip says. “Why wouldn't there be cars in that facility if you're going to have a lot of employees?”

No Data Center MPK retained an environmental and land use attorney. They recommended an ordinance banning data centers immediately, then to reinforce it with a ballot measure.

They set up a one-click email so residents could send comments to City Council demanding both.

Hundreds showed up to the next three council meetings.

“We played mahjong on the City Hall lawn while we waited. We had a lion dance right outside to cheer people on as they entered the council chambers,” Yip says.

The chambers filled, overflowing into the aisles and hallways.

The first meeting produced a 45-day ban on data centers, the second brought a ballot measure that would ban them forever.

During the third meeting, opponents of the data center called for a rally at 5:30 p.m. before the 6:30 p.m. meeting. Steven Kung, the Monterey Park resident who purchased the No Data Center MPK domain, addressed the developers, their lawyers, and the lobby firm directly.

“You’re fighting an uphill battle against an entire city that doesn’t want you here and yet you continue to bully your way into this community of color, to pollute the air we breathe, to make electricity more expensive, to devalue our homes, to drain our energy and resources like a parasite,” Kung says. “You think you can take us on? You’ve messed with the wrong city. ”

On March 31, the developer withdrew its application.

“They underestimated the community's passion. And we never underestimated them. And I think that was a good strategy,” says Yip.

The FPPC, California’s political ethics commission, saw the data center would have a “material financial effect” on councilmember Wong. His power to vote on them was stripped.

Yip says the people who joined for the fight over 1977 Saturn Street have overwhelmingly stayed active with SGV Progressive Action.

"They recognize it's not just about data centers. It's about building community and protecting your community," he says.

The volunteers who organized against the data center are now working to strengthen sanctuary ordinances to protect their communities from ICE.

“And now we have a coalition of all these community members coming from La Puente, Avocado Heights, Rowland Heights, and Hacienda Heights coming together to fight this common enemy. And I'm just going to name it the City of Industry,” Yip says.

NO DATA CENTERS SGV COALITION

Samuel Brown Vazquez rode ten miles horseback from Avocado Heights to the Monterey Park council meeting. Vazquez is a community organizer and founding member of the Avocado Heights Vaqueros.

The City of Industry is in the process of approving zoning changes that would clear the way for three data centers and battery energy storage that would affect the residents of Hacienda Heights, La Puente, Walnut, Diamond Bar, West Covina and others.

The Avocado Heights Vaqueros, SGV Progressive Action, and others organized across city and county lines.

“We created an infographic and started mobilizing folks,” Vazquez says. They are No Data Centers SGV Coalition.

Like Monterey Park, they canvassed door-to-door, showed up to every City of Industry meeting, started a petition, and filed public records requests.

The record requests showed the City of Industry had been discussing zoning changes with developers at Puente Hills Mall, Madrid Middle School, and two battery storage facilities near Hacienda Heights. All just feet from homes and schools.

In February, the city unanimously rezoned Puente Hills Mall for battery storage. Months earlier, the city manager, Joshua Nelson, emailed the developers that they were working to allow data centers anywhere in the city.

Again, organizers found that people had no idea what the city was planning to put next to their homes. Battery centers burned for days when they caught fire. One at Moss Landing had spilled 55,000 tons of nickel, cobalt, and lithium.

“Maybe only one or two people had heard," said Sophia Ramirez, an organizer and the daughter of Zacatecan immigrants. “That was pretty shocking.”'

Ramirez, a Cal Poly biology grad, explained in the outreach, in plain language, how PM2.5 and PM10 particles could slip past the body's filters into the lungs, then the blood.

The No Data Center SGV petition grew to 18,000 signatures.

In Monterey Park, the people who organized were also the people who vote. In the City of Industry, there hasn’t been a competitive election in 10 years, and only four since 1957.

State law says when fewer people run than there are open seats for, a city doesn't have to hold an election. The City of Industry council appoints its council members and some of its members are descendents of the original founders.

The City of Industry has 256 residents, the largest financial reserves of any city in the San Gabriel Valley, and a history of building its wealth at the expense of the surrounding working-class Latino and Asian Pacific Islander communities.

"I had normalized what it was like to live next to City of Industry,” Vazquez says. “I thought it was normal to just grow up near all these warehouses."

The people of the surrounding areas, Covina, Diamond Bar, El Monte, La Puente, Pomona, Walnut, and West Covina, would all be affected by the data centers, but have no political power over the City of Industry.

“To think of it in the context of environmental racism, environmental injustices, it’s really crazy that it's like the city of industry has decided that these communities that live around them are not valuable lives,” Ramirez says. “Zonas de sacrificio.”

People from La Puente, Avocado Heights, Rowland Heights, Diamond Bar, Walnut, and Hacienda Heights came to the City of Industry’s March 26 council meeting where they planned to change the city's zoning code to allow data centers.

The city’s email went down before the meeting. People said it often does. The only way to comment is to show up. More than 100 people did, at 9 a.m. on a workday. Before public comment, the council went into closed session.

“They made us all wait outside in the heat,” Ramirez says.

Ramirez said that it was 90 degrees, and there were many elders. After two hours, roughly 40 were let inside. Outside, there was no livestream. They chanted, "Let us in."

When the doors opened, only about 30 people were allowed to speak. Their comment time was cut from three minutes to one minute. Mayor Pro Tem Greubel got up and walked out halfway through.

The City of Industry does not provide interpreters, translated materials, or any way for people who speak other languages to comment. They haven't posted meeting minutes in over a year. More than a quarter of their meetings are called with 24 hours notice.

“Everything about City of Industry is designed to minimize participation of the public,” Vazquez tells us. ”Like, that is not an exaggeration to say that.”

VALLE IMPERIAL RESISTE VS. IMPERIAL COUNTY

Gilberto Manzanarez, an organizer and founder of Valle Imperial Resiste, learned of the data center on Facebook. Someone had leaked the planning commission’s map over Thanksgiving break.

Manzanarez grabbed his camera, drove to the site, and posted a video that spread across the valley.

The Imperial Valley data center would be one of the world’s largest at nearly one million square feet. It would use double the electricity of Imperial Valley and 750,000 gallons of water every day. County planning staff decided they “qualified as a permitted industrial use,” and there would be no need for environmental review.

Manzanarez, also a history teacher, says, “Public health always takes a backseat to economic development in the Imperial Valley.”

The air carries cropland burnings, diesel fumes, and dust from the drying Salton Sea, laced with pesticides and heavy metals. More than one in five children that live around the Salton Sea have asthma.

Despite decades of investment, solar farms, geothermal plants, military bases, and canals, the 80 percent Latino region’s unemployment sits at three times the national average.

“The promise of economic development and jobs, the same thing, these are stories that we already heard when we had the solar farm boom. Those solar panel projects were sold to us,” Manzanarez says. “It's like, this is going to save us. This is going to lift us out of poverty ... Thousands of people across the Imperial Valley were hired, and they were excited to go work. Fast forward 10 years, 2026, guess what? We have the highest unemployment rate in the state of California. Again.”

Bryan Vega, another local organizer, saw the Valle Imperial Resiste post and joined the other activists. They knocked on doors, handed out flyers, and flooded Instagram with informational videos.

“We started to share information about what the data center is and invited folks to submit public comment,” Vega says.

In January, they held a protest on Main Street and Imperial Avenue. They started a petition to enact the Imperial County Data Center Prohibition Act.

On March 26, the Imperial County Board of Supervisors called for an evening meeting, outside of their normal schedule, specifically about the data center.

The main chamber filled 30 minutes before it started. Two overflow rooms opened in a separate building. And when those filled, too, more than 60 people stood in the parking lot.

The developer, Sebastian Rucci, spoke. There were to be no questions.

Vega recalled standing out in the parking lot.

“Someone outside said, ‘Why are we just standing here? Why are we not more upset? They're making decisions about us in there. And we're out here. And we should be in there. We go to the door and we're like, ‘No Data Center. No Data Center.’ And it's like a battle cry from our soul,” he says.

Vega said one of the organizers, from Imperial Valley for Palestine, had a bullhorn in her car, “because, duh, she's an organizer and she's always prepared for these things."

KPBS reported that “county officials paused the meeting and Rucci departed early after protestors drowned him out.”

Videos show Imperial County sheriff’s deputies escorting Rucci and his business partner, Hector Casas, to their car.

Outside, the 60 people who weren’t allowed in chanted “Fuera! Fuera!” at Rucci and Casas as they drove off.

"This meeting was a sham,” Manzanarez says. “They didn't want to educate us. They didn't want to hear people. They just wanted to check a box."

KPBS reported that in 2010, Ohio prosecutors charged Rucci with money laundering, promoting prostitution, and perjury at a Youngstown nightclub. The felonies were thrown out, but he served 30 days for selling alcohol on an expired license. He later opened an addiction treatment center. The state revoked its certification after finding falsified records.

In 2021, the FBI raided the treatment center and seized more than $600,000. No criminal charges were filed. Rucci sued, got the money back, and is still fighting in federal court.

In an interview with KPBS, he said, "I won them all but one."

Rucci and his partner, Hector Casas, targeted Imperial County because the zoning laws allowed them to skip environmental review.

"Our whole goal is speed," Rucci told KPBS. "That is not sneaky. That's just smart."

On April 7, at 8 a.m., 50 men got off a tour bus with identical orange vests that said, "Data centers equal jobs and prosperity."

They were led through the side entrance of the County Administration Building before any members of the community were allowed through the front. A leaked internal county email sent the night before warned of high turnout and increased security. Despite that, the county provided no overflow room.

Over 100 community members were left outside in 96-degree heat for five to six hours. Elders with walkers. No shade, no water, no chairs. One community member got kicked out for calling out the outsiders taking seats from residents.

The board of supervisors voted to approve the lot merger. Only one supervisor voted no.

Senator Padilla's SB 887 would require all new data centers in California to go through environmental review. The bill does not ban data centers, it only requires developers to study their impact and hear from the public before building.

On April 2, the organizers filed the Imperial County Data Center Prohibition Act, the first step toward a ballot measure that would ban data centers across the county.

“Our parents and grandparents sacrificed so much to be able to be in the Imperial Valley ... part of the sacrifice was having to accept a hard hand,“ Vegas says. “Like when I think about what my Mexican farmworker parents had to undergo, it makes it almost intuitive to fight for the environment, intuitive to fight for the things that I know are true to them, but also very simply put, we would not be here without that."

How one programmer's pet project changed how we think about software

2026-04-17T03:53:44Z

This is the story of how one programmer's obsession with simplicity quietly reshaped how the software world thinks about time, immutability, and what it means to write code that lasts. From a sabbatical pet-project to the backbone of one of the world's largest fintechs and a global community that treats their language like a philosophy. This is the story of Clojure. --- This documentary wouldn't exist without the kind support of Nubank: https://building.nubank.com/engineering/ Thanks to Railway, our channel sponsor, for supporting all of our films: Railway is the all-in-one intelligent cloud provider ➡️ https://railway.com/?referralCode=cultrepo --- The Clojure Documentary features: Alessandra Sierra, Alex Miller, Chris Houser, David Nolen, Ed Wible, Eric Normand, Eric Thorsen, Lucas Cavalcanti, Michael Fogus, Nathan Marz, Rich Hickey, Steph Hickey, and Stuart Halloway. Film Credits: Directed by: Cormac Dunne Produced by: Emma Tracey Additional direction: Joey Bania Music supervision and sound design: Tomás Malara --- For a full overview of all the papers, talks, essays, etc. that appear in the film, check this link: https://clojure.org/about/documentary --- Follow us: X: x.com/CultRepo Bluesky: cultrepo.bsky.social Instagram: www.instagram.com/cult.repo LinkedIn: https://www.linkedin.com/company/cult-repo

‘By Design’ Flaw in MCP Could Enable Widespread AI Supply Chain Attacks

2026-04-16T12:15:58Z

Model Context Protocol (MCP) has been a boon to agentic AI users and is widely used and trusted locally by companies adopting agentic AI internally.

Introduced by Anthropic in November 2024, it provides a standard connector between agents and data. Enterprises use it locally to avoid the pain of developing their own connectors, and it is in widespread use as a local STDIO MCP server.

There are multiple providers of MCP servers, almost all inheriting Anthropic’s code. The problem, reports OX Security, is what it terms an architectural flaw in Anthropic’s MCP code embedded within most of these local STDIO MCPs.

In a nutshell, OX Security says this flaw can result in a complete adversarial takeover over the user’s computer system. “And the exploit mechanism is straightforward, MCP’s STDIO interface was designed to launch a local server process. But the command is executed regardless of whether the process starts successfully,” reports OX.

“Pass in a malicious command, receive an error – and the command still runs. No sanitization warnings. No red flags in the developer toolchain. Nothing.”

OX extensively tested whether this ‘flaw’ was exploitable, extensively succeeded, and extensively disclosed its findings to the MCP providers; from Anthropic downward. Initially it had little response. Eventually, the common response was inaction coupled with the suggestion that this behavior was ‘by design’.

Advertisement. Scroll to continue reading.

But OX discovered, and demonstrated, that this ‘by design’ behavior could be easily exploited, leaving potentially millions of downstream users exposed to sensitive data, API key and internal corporate data theft, the exposure of chat histories, and more. If the process that MCP failed included malware, that malware could be silently installed, potentially leading to complete system takeover.

Eventually, the only apparent action from Anthropic was to quietly update its security guidance to recommend MCP adapters be used ‘with caution’ – “leaving the flaw intact and shifting responsibility to developers”.

This is an interesting position to take. It suggests that developers are responsible for the security of what they develop, which is fair. It possibly also suggests that any company so breached is not the responsibility of Anthropic, but the fault of misconfiguring the MCP installation – which certainly does happen. And to be fair, GitHub’s own installation was an exception to the OX testing, proving that security gating on installation is possible.

Learn More at the AI Risk Summit | Ritz-Carlton, Half Moon Bay

But the sheer volume of successful compromises conducted by OX demonstrates that the developers installing MCP servers are failing to install successfully. This should be no surprise when AI is automating so many aspects of security and lowering the bar of security competence among developers.

The OX position is that Anthropic should take responsibility and fix this ‘architectural flaw’ itself. Without doing so, it is leaving industry open to “the mother of all supply chain attacks”, starting from Anthropic, fanning out to many thousands of local MCP users, and from those compromised systems to who knows how many other servers.

During its research, OX adopted a coordinated disclosure process, leading to more than 30 accepted disclosures and more than 10 high and critical vulnerabilities patched. But the underlying design flaw, it says, remains, leaving millions of users and thousands of systems exposed to unauthorized access. “The current implementation of the Model Context Protocol places the entire burden of security on the downstream developer – a structural failure that guarantees vulnerability at scale.”

The OX report on its findings includes details on how Anthropic could solve the problem by deprecating unsanitized STDIO connections, introducing protocol level command sandboxing, including a ‘dangerous mode’ explicit opt-in, and developing marketplace verification standards to include a standardized security manifest.

In the meantime, any company adopting STDIO MCP as part of an agentic AI development should do so ‘with caution’.

rarouš.w3b

untitled

The Aircraft Engine/Automotive Validations (2004, 2007)

The Micro Software Validation (2006)

The Macro Software Validation (2012)

The Industry Reality Check (1995-2020)

Conclusion

The Series: Navigating the Shades

Bibliography

untitled

The Plan

untitled

untitled

The AI adoption gap and the 0.04%

Three ways the bubble distorts your decisions

What the data actually showed

Building different journeys for different people

The playground: A structural answer

Start with the problem. The tools will follow.

Build the bridge your users are ready to cross

Social RSS (?)

On wintering.

10x engineers: the Purple Developer

Native Apps Should Be Avoided Whenever Possible

The White House App

The Software Embedded in Apps

Why Everyone Should Care

What Apps Can Do That Websites Can’t

The Access Provided by Default is Enough to Do Real Harm

Some Things Need to Be Apps, But Most Don’t

Conclusion

References

AI dělá chyby a autisté je dokážou najít. Z jejich jinakosti dělá Češka ve svém startupu přednost

Using safe-area-inset to build mobile-safe layouts

Environment variables for safe area insets

Browser support

Using safe-area-inset values

Which web pages actually need this?

Safe-area-inset doesn't provide margins

Safe-area-inset only has non-zero values on mobile devices

Polypane's device emulation supports safe area insets

Solving a specific issue: Floating buttons

safe-area-max-inset

Browser support for safe-area-max-inset-*

Testing safe areas in Polypane

What to take away

Design Token Naming Conventions: A Practical Guide

Design Token Naming Conventions: A Practical Guide

Why naming gets hard faster than expected

What are design tokens, a quick recap

The three token tiers

Tier 1 - Primitive tokens

Tier 2 - Semantic tokens

Tier 3 - Component tokens

Common naming conventions

1. Category-Property-Modifier (CPM)

2. Tier-based naming

3. Object-Property-Modifier (OPM)

4. Context-first naming

5. A Comprehensive Structure

Handling variants, states, and modes

The same decision in different conventions

Variants

States

Scale sizes

Modes and themes

Numbered scales

Rules that keep token naming healthy

1. Consistency beats perfection

2. Optimise for clarity over brevity

3. Keep semantics semantic

4. Order from broad to specific

5. Make names self-explanatory

6. Design for growth

Choosing your convention

Keep naming alive with lightweight governance

Upgrading Forgejo with S3 Object Storage and Actions!

Migrating to S3 Object Storage

Setting up Forgejo Actions

Conclusion

`safe-area-max-inset`

Browser support for `safe-area-max-inset-*`