Giant Robots Smashing Into Other Giant Robots

Why thoughtbot is joining the Ruby Alliance

2026-05-20T00:00:00+00:00

For more than two decades, Ruby has shaped how we think about software development at thoughtbot. It influenced how we write code, how we collaborate, how we teach, and how we build products alongside our clients. Many of the practices, tools, and ideas that define our company today were either born from or heavily influenced by the Ruby community.

Ruby also helped shape our careers, friendships, businesses, and opportunities. That’s a big part of why we’re excited to share that thoughtbot is joining the Ruby Alliance alongside Gusto as a founding company.

What is the Ruby Alliance?

The Ruby Alliance is a new coalition of companies making a long-term financial and operational commitment to the sustainability of Ruby infrastructure and the broader ecosystem.

The Alliance was created around a simple idea that the long-term health of Ruby should not depend on only a small number of maintainers, volunteers, or companies carrying the responsibility alone. We believe strongly in this idea.

RubyGems.org, Bundler, ecosystem security, conferences, education, and community initiatives are all part of the shared infrastructure Ruby developers and businesses rely on every day. Sustaining that infrastructure requires more than appreciation. It requires ongoing investment, operational support, and shared stewardship from the organizations that benefit from Ruby’s continued success.

Why we joined

Joining the Ruby Alliance felt like a natural extension of who we already are.

We’ve always believed in contributing back to the communities and ecosystems that support our work. Over the years, that has included:

Authoring and maintaining open source libraries and tools
Developing custom training and tutorials
Presenting conference talks and mentorship
Community organizing and hosting events
Helping teams build and scale Ruby applications thoughtfully

Ruby infrastructure also has a direct connection to thoughtbot’s history. The creator of RubyGems.org worked at thoughtbot when the project was originally launched as Gemcutter, and thoughtbot contributed the original design for the project. Supporting the long-term sustainability of Ruby infrastructure feels deeply aligned with the role Ruby has played in our company’s story.

Ruby has given us an enormous amount to be thankful for over the last 23 years. Participating in the Ruby Alliance is one way we can help ensure the ecosystem remains healthy, stable, innovative, and community-driven for the long term and we’re grateful to Ruby Central for inviting us to participate.

We believe this is an important time for the Ruby community to thoughtfully shape what the next chapter of stewardship looks like together. We’re proud to be participating early in that effort and excited to collaborate alongside the other companies, maintainers, organizers, and contributors helping move everyone forward.

Summer Special: We’re Taking London Tech Leaders Outdoors

2026-05-19T00:00:00+00:00

This summer, we’re bringing the London Tech Leaders Meetup series outside.

Over the next few months, we’ll be hosting a series of outdoor summer gatherings across London for founders, CTOs, engineering managers, product leaders, designers, and builders who enjoy having thoughtful conversations with good people, without the pressure of a formal networking event.

We started these meetups because we wanted to create the kind of events we’d actually want to attend ourselves.

No sales pitches. No presentations. Just people in tech meeting other people in tech.

Smaller groups, interesting people, and space for genuine conversations about building products, scaling teams, AI, startups, leadership, engineering culture, and everything in between.

First stop: People’s Park Tavern

Our first summer meetup will take place on June 23rd at People’s Park Tavern in London.

Located right on the edge of Victoria Park, it’s one of our favourite summer spots in the city and the perfect setting for an outdoor tech gathering.

Whether you’re scaling a startup, leading engineering teams, building products, or simply looking to meet friendly people in tech, we’d love to have you join us.

Expect relaxed conversations, drinks, summer weather (hopefully), and the kind of networking that doesn’t actually feel like networking.

Why we’re doing this

A lot of people in tech work remotely now. And while online communities are useful, there’s still something hard to replace about meeting thoughtful people in person.

Some of the most valuable connections come from sitting outside with a drink after work and talking honestly about the challenges of building products, hiring teams, navigating growth, or figuring out what’s next in tech.

That’s the energy behind these meetups.

Intentional, welcoming, and community-driven.

Join us

If this sounds like your kind of evening, we’d love to have you join us.

You can sign up here: People’s Park Tavern Meetup RSVP.

We’ll also be announcing more summer meetups soon.

Looking forward to seeing familiar faces and meeting new ones along the way.

AI and minority languages

2026-05-18T00:00:00+00:00

Last week I attended an excellent conference in the Irish consulate in San Francisco titled “AI & Minority Languages: A Bay Area Perspective”.

Our team at thoughtbot speaks over 25 different languages, from Swedish to Bekwarra, so this conference was of particular relevance. Here are my key takeaways from the discussions.

Who gets in the ark?

AI poses both an opportunity and an existential risk for minority languages. While these are typically languages whose speakers are fewer than those of another group within a defined area, in this context it more closely relates to languages that are not one of the world’s dominant languages such as English, French, German, Spanish, Russian or Chinese (including the likes of Mandarin and Cantonese).

On the one hand, new AI-powered tools like Abair from Trinity College Dublin (for Irish/Gaeilge), Aina (for Catalan) and Project Vaani (for a whole range of Indian languages and dialects), can create new ways for people to interact with minority languages and dialects.

But the picture is not all rosy. AI is accelerating the loss of languages with 97% of the world’s languages now being categorised as “in danger”.

That is partly because language is not just about how many people speak it. It’s about usability; what you can achieve using your language. If a minority language is no longer useful in the modern world, it becomes associated with the past. And languages that are associated with the past die out. With the proliferation of AI, for the first time in history, you could have a language spoken by 20 million people that could actually be in danger because it’s about to be drowned out in the present technological wave.

The old global divide was about access; do you have a device, a connection, an account? The new divide is around quality. If a doctor can use technology to get decision support in English but a doctor looking for support in Swahili gets only noise, the language is going to be in danger.

We’re at an inflection point and the implications of not making it into the ark are profound.

What are the problems?

Biased data

The current imbalances largely occur due to gaps in the data. 93% of ChatGPT3’s training data was in English. Therefore, the language you speak determines your access to and effectiveness with the technology. If the data used to train models is only in a handful of primary languages, we will have less diversity and fewer useful living languages.

Defining success in different languages

Public success metrics for performance in general reasoning models nearly always relate to how proficient a model is in English. But if you assess a model in terms of multilingual performance, the success rate is much lower.

For example, Claude Sonnet 4.5 performs at 94% in general reasoning in English, but at only 76% in Yoruba. That is quite a disparity, and it likely increases when compared to even more marginalised languages.

Furthermore, 28% of questions that are asked of an LLM require culturally sensitive knowledge, which becomes increasingly difficult to accommodate the more marginalised a language is.

Accessibility

Language is subtle and nuanced. There can be a difference between accuracy and understandability. An AI system can be technically correct, but it still might miss out on nuances in different languages.

A simple example is that an AI system might say 25%, whereas humans might more commonly say “one in four”. It’s the same outcome, but expressed differently. Humans also use metaphors whereas AI tends to rely on literal descriptions. The question isn’t whether AI can do something, but how does AI communicate meaning.

A humorous example of this failing came during an Eleven Labs demo of an AI voice product which was tasked with creating some Irish folk tunes. While it completed the task well, the voice agent, despite speaking in the voice of an American man, decided to name itself “Aoife”. For those who don’t know, Aoife is a very popular Irish girls name. The system clearly knew enough to select an Irish name, but it clearly didn’t understand the name itself. It missed the nuance.

Computational power

Dr. Mochamed Asri brought up one of the most fascinating issues discussed during the conference. He explained that, while models might be getting better, the tokeniser is seriously lagging behind. It focuses on English, and it needs to get much better to bring parity to different languages.

Over 90% of model training data is in English. Because of this familiarity, it’s easy for the LLM to assign a single token to words. For example, the word “community” in English registers as a single token. But the word “masyarakat”, which is Japanese for the same word “community”, because it is not recognised, gets split into 4 different parts; “mas”, “ya”, “ra” and “kat”. That’s four tokens, which means four times the computational power, for the same meaning.

Energy gap

Computing power leads us on to the energy gap issue. Unfortunately, the countries with the greatest need for extra compute power because of the tokeniser imbalance, are the ones least equipped to provide the necessary energy, which prevents countries from making their own models.

For comparison, the United States has a population of ~350 million people and an electrical capacity of ~1,200 GW. Indonesia, with a population of ~288 million people, has a capacity of only ~80GW. Kenya, with a population of ~59 million people has only ~4GW of electrical capacity.

Bystander problem

AI can contribute to bystander syndrome. We might think someone else will work on adding and protecting our languages, that there’s no need for me to take any action. But the reality is that big frontier models will not do this work for us.

Improving models but more to do

The frontier models are improving, which is a step in the right direction.

During his talk, Zach Parent of OpenAI, demonstrated how ChatGPT 3.5 turbo performed much worse than ChatGPT 5.5 at Irish language tasks. The test demo was simple; he asked each version of the model a question in English but asked it to give the answer in Irish. Then he asked both to translate the Irish answer back to English. 5.5 gave a pretty accurate response, while 3.5 outputted mostly gibberish.

This demonstrated that over 3 years, it has improved a lot. But Zach highlighted that while everyone focuses on training the model, the other steps in the process are where the gaps exist.

The models improve by putting more data through them. The process needs to start with Automatic Speech Recognition, or ASR, to turn spoken word into text. The model then needs to understand the inputs before applying Text To Speech (TTS), followed by a real-time agent to make it conversational.

Each of these steps requires high quality data that is not easy to capture. In particular, there is a real gap when moving from text to voice.

How to fix it

High Quality data

We need more high quality data and representation in the models. This is not just about having more translations, but actual high quality input.

Processes like transcribing voice to text is manual, it’s labour intensive and requires native speakers. Once it’s done, that data can get ingested and the model gets trained on it.

Government support

That transcription piece won’t just happen on its own, it can’t just be automated. Governments, non-profits and universities need to step in to support this work.

Small Language Models (SLMs)

Small language models offer some promise, especially in relation to compute power and the energy gap. Again, governments will need to provide supports to build SLMs and edge deployments.

Improved tokeniser

Even as the models improve, we won’t get language parity until the tokeniser improves and becomes more diverse, reducing compute power constraints for minority languages.

Accountability

As a society, we need to hold frontier models more accountable when they publish performance metrics. Applying pressure to disclose cross language performance metrics will help highlight the gap and, hopefully, will lead to further action.

Get creative

One of the most unique, creative ways to drive a minority language and culture into the modern age came from the Iñupiat, an Alaska Native people. Gloria O’Neill of the Cook Inlet Tribal Council explained how they created a puzzle-platformer video game called Never Alone (Kisima Inŋitchuŋa) which is based on a traditional story passed down through generations.

The game was created in partnership with E-Line Media. With over 15 million players worldwide, the reception of Never Alone: Kisima Ingitchuna launched a movement of social-impact video games. It went on to win a Peabody Award for its storytelling and a BAFTA for Best Debut Game. Eight years later, Never Alone 2 is on the cusp of being released.

I was inspired and blown away by the totally outside-the-box thinking of the Iñupiat people to preserve their language and culture.

A closing thought

AI has endangered more languages than ever before. However, there are still ways that we, as minority language speakers, can preserve our languages. We can create the high quality data required to train the models, push corporations and governments to accommodate and support minority languages, or think completely differently about how to make our language relevant in the AI age.

We are at an inflection point and we need to take ownership and accountability to get our languages onto the ark.

6 key insights from Startup Grind Global 2026

2026-05-15T00:00:00+00:00

Last week I attended Startup Grind Global in Redwood City, CA. I find it can be helpful to get boots on the ground to hear first hand what’s happening in the industry. Here are my six key takeaways, grouped by theme.

As you can probably guess, there was a lot of AI talk, so please bear in mind there is always going to be some hyperbole and exaggeration at conference talks; it benefits people to big up their industry. The core concepts shared in our “AI for Business” livestream series still ring true; start with a problem you want to solve, look at your processes from end-to-end and then look at tools that can help you.

Recordings of all the talks are available on Startup Grind’s YouTube.

Pace of change in AI

You don’t need to spend long walking the streets of San Francisco to see that change is afoot. The pace of this change is what surprised me most though, with many speakers at Startup Grind labelling companies formed pre 2022 as “legacy companies”.

It certainly feels like a land-grab is underway with enterprises under pressure from their boards to pick their AI tools in the next 6-9 months. It’s accelerating, and AI-native companies seem to have an edge (although I believe some of this is smoke and mirrors).

What seems to be more concrete is that we’re moving from “rented intelligence” to “owned intelligence”. Large frontier models have been used as a general purpose solution to solve many problems. Now though, smaller models trained on specific customer data are coming to the fore. This is because you don’t need frontier level intelligence to solve a lot of tasks. The question is not which model is the smartest, but which model is the most efficient at completing a task without compromising quality.

The future is likely some combination of the two approaches. Some problems will be solved by large frontier models, but many others will be better suited to models that are trained specifically on your own customer data. Therefore, it is important to own the stack; the model and the data. That’s the most valuable layer, and you need to own it.

What still matters

One thing I heard consistently across most talks is that taste and judgement are the most valuable skills to have in this rapidly changing space.

You may have expertise in a specific tool or process, but if that workflow gets replaced or automated, those expertise become less valuable. However, even if we reach a point where an individual is managing a team of productive agents, there could be even more work for you to do on the back of all that output. You’re going to have to make those critical judgement calls for all the agents’ work.

So it’s important to make AI work for you, not the other way around. It’s a tool, but you need to make the decisions. Being opinionated helps in this regard. And if you want to explore some of thoughtbot’s strongly held opinions, check out “The opinionated thoughtbotter” series.

Marketing & Pricing

It can also be challenging to market your company in such a fluid environment where new work is being shipped constantly. How do you keep a consistent message? Well, the best companies are now shipping fast and iteratively, but the narrative around their brand always stays the same. It’s consistent and is tied to the same company mission.

Your product marketing can be more functional but your brand marketing needs to be emotive; it’s about how you make people feel. The best marketing focuses on the problem, not the solution.

In terms of pricing, consumption based pricing is all the rage currently, while people have been predicting the downfall of SaaS for the last couple of years. But the sentiment I heard is that the pendulum will probably swing back to some form of bundle pricing because consumption based pricing is hard for enterprises to control. The trick here will be creating different consumption buckets that work for your customers, so the two pricing methods are merging to some degree.

Future founders

Given this was Startup Grind, a lot of the advice was focused on founders. This is an exciting time to be a founder, comparable to the opportunities that existed around the iPhone in 2010. As a founder, you have an opportunity to create an entirely new future and to bring customers along for the ride. The next great founders won’t just be bolting AI on something people already use, but they’ll be changing what people do completely. To pull this off, you need to be bold, opinionated and even contrarian.

Entrepreneurial spirit is in high demand in early stage teams too. With the pace of change, finding people who are resourceful, hungry and who get things done is more important than specific skills or impressive backgrounds.

Finally, if you are heading down the fundraising route, it is almost impossible to raise money with just a pitch deck (for software products at least). The conventional wisdom seems to be that, with AI coding agents, you need a working prototype and customers to raise capital.

Agentic havoc

While agents can be helpful, they can also create devastating problems. One example is supply chain attacks, like the recent one at Mercor. These types of attacks are becoming more prevalent and can be introduced, for example, when someone uses Claude Code to install packages that inadvertently create security issues.

The advice is to never connect a coding agent to production data because it can install, run or, worst of all, delete anything. Incident responses, design reviews, and auditing and tracking who made changes are all becoming even more important with agents in the mix. Security, therefore, is a real area of opportunity for companies to exploit.

The future of designers

As a Product Designer, I was particularly interested in hearing about the future of design at this conference. In the lead up to it, with the release of Claude Design, there have been a lot of click-bait articles and videos online predicting the demise of the design field.

While the “no UI” concept is a trendy idea, I saw some pushback against it. The feeling seems to be that someone, somewhere during the process, will have to do something, so there’s still going to be a need for a clean, human-centered UI. If we reach a point where an individual is managing a fleet of agents, having a simple, easy and beautiful UI for managing these agents will be the frontier of design.

In terms of UX, in a world where anyone can create anything, the experts actually felt UX is going to be more important than ever. So good design isn’t going away.

My favourite talk of the conference was a fireside chat between Karri Saarinen (CEO and co-founder of Linear) and Stephanie Zhan (a Partner in Sequoia Capital). They discussed design and AI. Karri began his career as a designer so I was particularly interested in what he had to say on this topic. While I recommend watching the talk in full, the key takeaways I pulled from it were:

Good design is a way to build trust and could be a competitive advantage. It shows you put lots of thought into your product, which is reassuring for potential customers. You still need to ship fast to test, but there’s a balance to be struck. This point was actually made during the Q&A they did after the original talk, so it’s not in the recording above.
In relation to AI design tools, Karri made the point that even if these tools can generate designs that look good, it doesn’t mean those designs work well. He still uses Figma at the planning stage when he designs because writing something out helps him organise his thoughts. This act gives you some real value that shouldn’t be overlooked in favour of “vibe-designed” applications.
Karri believes that output isn’t design. It’s not the act of producing that is valuable, it’s about understanding the problem well enough to understand what, how and if something should exist. Karri felt there could be a pendulum swing back, moving away from building loads of things quickly and towards being more thoughtful and intentional about what is being built.
Undoubtedly some aspects of design will change. AI is increasing the floor of design in some areas and automating others. The drawing of rectangles will be less important in future. But Karri made the point that if you don’t understand design you’ll use these AI design tools incorrectly. If you don’t trust AI to do your legal work, then why would you trust it to do design?
Finally, the default career direction seems to be that design and designers move closer to code. But Karri felt there is an opportunity for ambitious designers to move upstream into leadership positions where they can answer questions like what we should be building, whether we should build something at all, what’s the product direction and so on.

3 cool companies:

Finally, here are three cool companies that stood out to me from the conference that you may not have heard of. Definitely work checking out!

Hydram Research - An Icelandic company building novel, large-scale hardware that makes it more energy efficient to produce steam, which is critical in nearly all material manufacturing processes, from plastics to paper.
Samaya AI - As thoughtbot are experts in the regulated industries, including financial services, Samaya caught my eye. Samaya equips financial professionals with secure, market-fluent AI agents to answer questions, deliver insights, and automate workflows.
Condor - An AI-powered early detection system to prevent the spread of wildfires. They claim to reduce response time from between 30 and 120 minutes to between 1 and 10 minutes.

When to use (and not use) CSS shorthand properties

2026-05-14T00:00:00+00:00

Ana Tudor posted about this recently and I agree: CSS shorthand properties are genuinely useful, but they’re not universally applicable. There are no hard and fast rules here. The question to ask yourself isn’t “can I shorthand this?” but “will someone reading this later, including future me, understand what’s happening?” It comes down to readability and intention, and those are going to look different for everyone. Verbosity isn’t always the enemy.

What’s a shorthand property?

CSS shorthand properties let you set a bunch of related values in a single declaration. There are quite a few of them, some more widely used than others.

One you may be familiar with is the background property, which can set the image source, position, size, repetition rules, origin, color, clip threshold, and scroll behavior all at once:

.selector {
  background: url(“/images/my-image.jpg”) 1rem 1rem / 50% 75% no-repeat fixed content-box padding-box orange;
}

Do you know what each of those values corresponds to? Some are obvious. orange is clearly the background color, and the URL is the image. But the numeric values and the content-box/padding-box pair? I have to look those up every single time.

That’s exactly the kind of situation where I’d rather just write it out.

When to use it, when to skip it

When the ordering is intuitive

Directional properties like padding and margin are generally fine to shorthand. I’ve committed the ordering to memory (clockwise from the top side), which is what makes them feel safe. The number of values determines what gets applied.

One value applies to all four sides:

.selector {
  padding: 1vw;
}

Two values split into y-axis then x-axis:

.selector {
  padding: 1px 10%;
}

Four values apply clockwise from the top (top, right, bottom, left):

.selector {
  padding: 1rem 10rem 3rem 2rem;
}

The three-value version, though? I always forget that the second value applies to both right and left. I’d rather write them out individually than trip over that every time I read it back.

So this:

.selector {
  padding: 1px 5rem 2rem;
}

Becomes this:

.selector {
  padding-bottom: 2rem;
  padding-left: 5rem;
  padding-right: 5rem;
  padding-top: 1px;
}

An even more resilient pattern is to use logical properties rather than strict directional ones, to account for layout changes across different languages and writing modes. In a left-to-right language like English, padding-inline maps to left and right, and padding-block maps to top and bottom. In a right-to-left language like Arabic, the inline axis flips.

You can get more specific with padding-inline-start, padding-inline-end, padding-block-start, and padding-block-end to target individual sides. In this example, a left-to-right reader sees 2rem on the left and 6rem on the right; a right-to-left reader sees those values swapped, with the same top and bottom padding either way:

.selector {
  padding-block: 10%;
  padding-inline-start: 2rem;
  padding-inline-end: 6rem;
}

border-radius falls into this category, too. One value applying to all four corners is intuitive enough that shorthand may be fine:

.selector {
  border-radius: 8px;
}

And when we have a variety of values, it’s good to know what we intend with longhand syntax. Sometimes I’ll even write out a zero-ed out property (like border-bottom-right-radius) in this example to communicate exactly what’s needed for this element’s shape:

.selector {
  border-top-left-radius: 2rem;
  border-top-right-radius: 8rem;
  border-bottom-right-radius: 0;
  border-bottom-left-radius: 5px;
}

When each value is a distinct type

transition and animation are both shorthands that pack in a lot: duration, easing, delay, and the property being targeted. For simple cases, the shorthand may hold up when each value is a distinct type: a name, a duration, an easing function.

This example may be easier to parse without ambiguity:

.selector {
  animation: spin 1s ease-in-out;
}

But even when the types are distinct, ordering can become its own problem at scale. If one part of a codebase has:

.selector {
  animation: spin 1s ease-in-out;
}

And another one has:

.selector {
  animation: linear fade 2s;
}

Both are valid, but the inconsistency means you’re re-parsing the order every time you encounter the shorthand. Writing them out individually enforces a consistent structure by default. There’s no order to forget or vary.

When things get specific with different delays per property or timing, I’ll pull out the individual properties anyways. Ana’s post has a great example of this: if you have multiple properties transitioning at the same duration, writing the full shorthand for each one is just repeating yourself:

.selector {
  animation: 1s ease-in-out;
  animation-name: spin, fade;
}

animation in particular has enough sub-properties (animation-fill-mode, animation-iteration-count, animation-direction, and more) that the shorthand may get unwieldy fast. In practice, once I’m reaching for any of those, I just write them out all individually.

When the syntax has its own rules

Some shorthands have parsing rules specific enough that you may need to have the spec loaded to read them. These are the ones I almost always write out.

background is my go-to example. Unless you’re setting something dead simple like a solid color or a plain image, the full shorthand becomes a puzzle. This is still readable:

.selector {
  background: url("/images/my-image.jpg") no-repeat center / cover;
}

But once you’re reaching for position offsets, size, origin, and clip together, the shorthand stops carrying its weight:

.selector {
  background: url("/images/my-image.jpg") 1rem 1rem / 50% 75% no-repeat fixed content-box padding-box orange;
}

It fails here not because there are many values, but because the values are opaque without knowing the specific syntax. The / separates position from size, so 1rem 1rem / 50% 75% isn’t four coordinates, it’s two pairs with different meanings. The content-box padding-box pair sets origin and clip in that order, which isn’t something you can always intuit. And that’s a different problem from padding having too many values, because at least those follow a spatial logic.

.selector {
  background-attachment: fixed;
  background-clip: padding-box;
  background-color: orange;
  background-image: url("/images/my-image.jpg");
  background-origin: content-box;
  background-position: 1rem 1rem;
  background-repeat: no-repeat;
  background-size: 50% 75%;
}

border is also interesting because it’s a layered shorthand situation: border is a shorthand, and so is border-left. The catch is that border applies to all four sides. You have to go down to the directional properties or the individual sub-properties to set different sides. I usually write border shorthand when I want a consistent border all the way around, but I’ll break it out when I’m doing something more specific with colors or styles on individual sides.

You can also write the sub-properties directionally, which is a nice middle ground:

.selector {
  border-color: red blue green yellow;
  border-style: solid dashed;
  border-width: 10px 3px 50px;
}

grid falls into this category too. The shorthand syntax can be genuinely hard to parse at a glance:

.selector {
  grid: auto-flow dense 40px / repeat(3, 1fr);
}

This feels easier to read to me:

.selector {
  grid-auto-flow: dense;
  grid-auto-rows: 40px;
  grid-template-columns: repeat(3, 1fr);
}

I write grid and flex out fully, almost every time.

When you can’t retain it

Some shorthands just don’t stick, and that’s reason enough to write them out. This is also an honest admission that the thresholds I’m describing aren’t necessarily universal; they’re shaped by what I’ve internalized over time. These are conditions as I experience them and not objective rules.

I use the longhand syntax for text-decoration more often than not, even though the individual property names are fairly obvious. I just can’t seem to retain the shorthand structure.

I always have to think about this:

.selector {
  text-decoration: underline dotted red 2px;
}

And to me, this syntax reads like a list of decisions:

.selector {
  text-decoration-color: red;
  text-decoration-line: underline;
  text-decoration-style: dotted;
  text-decoration-thickness: 2px;
}

gap is another directional one: it only deals with row gap and column gap in CSS grid. I usually set the same value for both, so shorthand is fine. But when they’re different, I’ll often write row-gap and column-gap separately, mostly because I can never remember which order they go in. I’ve somehow committed padding and margin to memory but not this one.

font I have literally never written shorthand in my life. It just doesn’t feel natural, especially with font-family, which often has spaces and fallback stacks and needs its own line anyway.

font-variant is a fancy one I reach for when handling special typefaces, usually for turning on ligatures. I can never remember all the individual values, so I write them out. And since I’m typically only tweaking one or two things, it doesn’t add much overhead.

It’s not all or nothing

You don’t have to choose between going full shorthand or writing out every individual property (spoiler though: I often do make that choice). You can mix them by using the shorthand to set a baseline and then applying a specific longhand when you need precision for one value.

border is a solid example of this. Set the baseline with shorthand, then override what changes in a variant:

.button {
  border: 2px solid navy;
}

.button--destructive {
  border-color: red;
}

The goal is always clarity. Use the version that makes your intent most obvious.

Writing only what you mean

Despite what I’ve just written in the previous section, I don’t usually mix short and longhand and am most often choosing the latter.

Longhand can communicate scope, and is a key reason I often err on that side rather than brevity.

Even for something as simple as background color, I’d rather write:

.selector {
  background-color: green;
}

Instead of:

.selector {
  background: green;
}

The shorthand works, but leaves the door open. If I only mean to set a color, background-color says that plainly and there’s no slot for anything else other than that to accumulate.

The same logic applies when I want a handful of sub-properties. If I only want a selector to have a background image, color, and repeat value, I write exactly those three properties:

.selector {
  background-color: #b4da55;
  background-image: url(“images/my-image.jpg”);
  background-repeat: no-repeat;
}

A background shorthand would create a natural place for other sub-properties to creep in. Someone (including future me) might reasonably add background-size or background-position to that declaration later. And while those are fine additions, it signals intention to me when they’re written out as their sub-properties instead of values within the shorthand.

At the end of the day, shorthand properties are a tool, not a mandate. And if your answer differs from mine: yeah, well you know, that’s just like uh, your opinion, man.

Reflections on my conversation with Lord Chris Holmes MBE

2026-05-13T00:00:00+00:00

One of the best things about hosting the Giant Robots podcast is that I get to spend time talking to people that might otherwise pass me by. It’s an opportunity to turn casual small talk into meaningful conversation. After meeting Lord Chris Holmes at the DigiGov Expo in 2024, where I was ~~collecting free merch~~ attending on behalf of thoughtbot, I felt I wanted to dig deeper into our brief chat about AI.

It only took a year or two but it was a privilege to sit down with Lord Chris Holmes, a member of the UK House of Lords and a former Paralympic swimmer.

Much has changed across the AI landscape since we first met which made our conversation even more pertinent. Lord Holmes is an active voice in the UK’s conversations around artificial intelligence regulation and digital policy. In Parliament, he has focused heavily on technology and inclusion, including introducing a Private Member’s Bill on AI regulation.

It’s been nearly two months since our conversation which has given me some time to reflect.

We can’t do nothing

The UK is desperately in need of some AI legislation

This still rings true for me. I am sometimes surprised at the lack of conversation or guidance on such a society-shifting tool as AI. In my opinion, I feel like this is one of the major roles of government, to have a good overview of the big picture. What does society look like? Where is it heading? And what does it mean?

There’s been an unfortunate lack of political will when it comes to artificial intelligence in the UK. It’s not a party political point because it was the previous government as much as it was this government. It’s largely been a wait-and-see approach.

I find this slightly infuriating because I feel like these are the conversations that many of us are having around the country.

So we’re left suboptimal, confusing, opaque, abandoned…

For economic, for social, for psychological reasons, it can’t be allowed to continue. That’s the approach from our UK government.

Pragmatic Approach

I found Lord Holmes approach incredibly pragmatic and reasonable. This is by no means a conversation about anti-AI or heavy regulation.

Thus, good for investor, for innovator, for consumer, for customer, for creative, good for the country, and really to wrestle to the ground once and for all, that tedious falsehood that recurs time and again, that you can either have regulation or innovation, you can’t have both. You can, and in fact, it’s the role of parliamentarians and regulators to consider all of these factors, so we can bring about pro-innovation, pro-consumer protection, pro-investor, pro-citizen, pro-creative regulation legislation.

This is not about stifling growth or heavy-handed regulation, and it seems to me that the key to this is a principle based approach that Lord Holmes described, which removes the need for micromanagement.

Critical to take a principles based rather than a prescriptive approach, I think. It’s tempting always to be prescriptive, to think, if we can write everything down to the last dot and comma and spell it out, that will be the best control we can have.

But unfortunately, though beguilingly appealing, it’s an unfortunate trap which traps us at that moment in time, because we don’t live in a static society, technology, economy, polity. None of these things are static. But to have a principles-based approach, which can adapt, develop and be agile through time, through technologies.

We know how to do this. We have the great good fortune of common law, which is well constructed and understood in that sort of approach. So we can.

It’s worth reading the AI Regulation Report to get a better understanding of these principles.

We have agency

I do sometimes find myself feeling a sense of fatalism about where this technology might be taking us. I think it would be unnatural not to be concerned at times, when the narrative indicates abrupt change. However, it was somewhat reassuring to be reminded that we are not just passengers in this societal journey.

We spoke about some of the lack of guidance we felt around social media as a comparison.

What you set out there about social media is well observed. But here’s the thing. None of that was inevitable.

And none of that had anything to do with the technology per se. It was programmed, constructed, operationalized and monetized to do what it now does. Technology didn’t do that.

Humans determined to structure it in that way. Horrific, but not inevitable. Not inevitable at all, and the same with AI.

Looking forward with optimism

I still feel a sense of optimism following our conversation. I love the idea that we can be a part of shaping this technology and removing the existential threat perception that it sometimes brings.

We have a stunning opportunity to make a success of these technologies, but it’s down to all of us playing our part.

So much so that we have to take responsibility as well.

If it goes wrong, that won’t be a failure of the technology.

That will be a failure of us by not human leading, by everyone not playing their part.

I highly recommend taking a listen to the full conversation and if you live in the UK and would like to discuss the regulation of AI with Lord Holmes, you can connect with him via LinkedIn.