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.

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.

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.

That one is well known enough that you probably already know to look for its “second” image. There are many other examples where another view isn’t obvious until it’s pointed out. Even then it’s sometimes hard to see right away.

That is, I’m viewing something, certain I’ve taken it all in, thinking it’s unremarkable. Nothing suggests I’ve missed anything or should give it a second look. Once it’s pointed out, I finally see it. How did I miss that? It was right there the whole time.

Fluency illusion is like that and far more common than we’d hope.

It happens when you realize a detail you missed. You thought you understood, but you hadn’t. That confidence, never noticing what you missed, is the illusion of fluency.

Seduction

This illusion, that we understood what we read when indeed we hadn’t, is insidious. It draws us in without any sense of risk, without skepticism. For if we felt we might be misreading something, we’d look for it. But since we don’t, we move on, accepting our reading as an accurate one.

This isn’t about humility. Not a choice or a failure of attention. The process is automatic. We’re trying to get something done and nothing triggers us to look closer.

Our practice, experience, even education, has made us capable of reading quickly. Of following what may even be complex content and still picking up key elements. That very capability tricks us into thinking we’ve fully understood.

We’re shown a solution to a math problem on a whiteboard. We find out later we’re far from being able to solve it on our own.

And so we can’t just read text once and absorb it all. We have to re-read, study, wrestle with it. It’s why we take a risk when we skim contracts and fine print.

Or source code.

Desirable difficulties

We’re well acquainted with this phenomenon even if we didn’t have a name for it before. In pedagogical settings, we counter fluency illusions with desirable difficulties. The instructor intentionally forces the student to contend with what they read (discussions, exercises, exams, etc.). It helps internalize what they’re reading. It better ensures they’ve discovered what it might yield for them.

As with students, we can’t trust ourselves to capture enough detail merely from reading it. So we must admit we don’t know what we think we know. We need to find ways to illuminate details, most especially when we’re the only ones that may be in a position to do so.

We can create friction to supply that illumination. We want pull requests small enough to read in pieces. We do this not only to limit the scope of a change but to make it tractable to review without merely skimming. We write automated tests not only to verify correctness but to think through what must be considered. We write them to help us engage with the problem at hand. We deliberately create desirable difficulties by forcing a conversation with the situation.

I can lose the illumination I desire when I inadvertently abdicate my role. When I let an LLM produce code I haven’t sufficiently participated in. If an AI tool generates too much code at once, I can be seduced to think it’s doing fine when it isn’t. The pace at which an LLM can produce code can quickly overwhelm the pace of feedback I can handle. In trying to read through it I can easily fall victim to fluency illusion. It may be only later when it becomes plain how much I missed.

We can’t trust ourselves to catch the issues merely by reading the code later. What the AI comes up with might be opaque to us, even when it works well. Our illusion of fluency will tempt us to nod along either way.

Promises, promises

That sounds dire, but it isn’t really. We’re actually used to this. We start new fields of research from threads pulled on older questions. We come up with novel solutions and ways of doing what’s not been seen before. We’ve figured out how to fly.

Cranberries and nightshade may look alike, but one of those is poison. We figured it out not by merely looking at them more closely, but empirically. We tested and watched other animals for clues. We rely on checks and balances and processes, all to limit the cost of being wrong.

Here too we have an opportunity. An obligation really. To stay engaged, to understand in the moment what we’re trying to build. To recognize the success, or failures, of what we write.

Someday we won’t care what the AI explicitly wrote any more than we care about the ones and zeros in our code most days. We can instead focus on the pace of feedback so we can correct issues in time. We can find new ways to converse with the situations at hand. And we’ll want checks and processes to limit the impact of any mistakes along the way.

Someday AI will be good enough to let it do more on its own in writing code. But it still needs us heavily engaged and skeptical for it to become what we hope for.

And we still need everyone else to keep us honest about that.

In essence, I’m managing the pace I can handle. The pace at which I can perceive what is happening, decide what to do about it, and act on that decision. We follow a relentless perceive-decide-act flow in much of what we do every day. Driving a car, sewing a hem, painting trim, having a conversation.

We need a pace for perceiving that lets us have time to decide and then act. As we become more familiar and skilled, we can reduce the time it takes, but it always costs some time. We learn patterns and we learn what to watch for instead of everything overwhelming us all at once. No matter how practiced we are, we can only go so fast. I can responsibly drive faster than a new student, but I’m not ready for the Grand Prix (vroom-vroom noises aside).

In fact, we depend on controlling the pace of feedback so much that we add controls for it. Not only the brakes on our cars, but foot pedals on sewing machines, speed controls on mixers, squeeze handles on sprayers. We know we’ll make mistakes. Without room to react, those mistakes can be damaging.

This isn’t only when working with objects. We know all about rushing an arithmetic problem or typing out an email too fast. The risk of errors and poorly considered explanations is far higher. Being deliberate while working under pressure may feel slower, but it generally meets the need better and faster.

Of power tools and robots

The more manual our tools, the easier it is to handle the pace of feedback. If I’m using a handsaw, it’s unlikely that I’ll injure myself or miss a cut going crooked. The saw can’t go far before I notice an issue and I can stop immediately.

Compared to a handsaw, a circular saw’s blade rotation and cutting speed are orders of magnitude faster. The feedback comes too fast for me to perceive every moment of the cut. I can’t track individual rotations or react to each instant. To avoid mistakes, wasted material, and injury, I need to do more than just react in the moment.

A crooked cut isn’t just poor work—it can bind the blade and cause kickback. So I manage the pace of feedback to preserve room for my perceive-decide-act cycle. Before I even start, I set up the work to reduce risk. I can’t always see the cut going crooked in time, so during the cut I feel for binding and listen to the motor. I compensate for the faster pace by predicting more and preparing more.

Imagine a more complete machine that automates more steps, like those in mass-market cabinet shops. It might not only trim the wood, but also shape its edges and corners with dedicated bits. Our machine follows a predetermined combination of steps already well understood and tested. Now the machine’s pace far outstrips my perceive-decide-act cycle. By the time I perceive a problem and decide what to do, the machine has already completed several steps. I can only tell something went wrong after pieces have gone through or the machine jams or breaks.

To be fair, the process is well understood and preprogrammed. While the cabinets might lack artisan craftsmanship, they’re good enough, sometimes excellent. As a result, we accept less control for more speed and consistency. Our role shifts from directly shaping the work to monitoring and feeding the machine. But in a factory, this trade becomes stark. We cut, affix, trim, and package at breakneck pace. Pieces get ruined, workers even injured, before anyone can perceive, decide, and act to stop the line. We now program in acceptable error ranges and tolerances for the machine to follow.

We can separate ourselves even further from the perceive-decide-act cycle. If we add a robot with artificial intelligence, it will adapt as it works. Based on what it senses, it adjusts its path and compensates for variations. Because it adapts continuously, we can’t predict or observe its decisions in real time. Any one of those could be the start of a bad direction. By the time we realize a problem, it’s already made choices we never saw. We won’t know what path it took or why it chose its approach. By then it’s far too late.

Running blindfolded

Similarly, if an LLM is producing a lot of code for me without pausing, I can think it’s doing fine when it isn’t. I may not always realize in time the pace was too fast. Only upon closer examination will I find the code has become a mess. I wouldn’t easily know what changed or why. It can be like reviewing large, unfamiliar PRs in unfamiliar codebases.

It’s even worse than that. Because we imagine how good AI could be, we can imagine not needing to be part of the process. We’ve read where machine learning has found superior solutions experts can’t explain.

We’re tempted by a theoretical ideal: we don’t need to understand how something works as long as it works better than we could. But that would mean I relax my vigilance and abdicate my perceive-decide-act role. In other words, I not only am unable to keep up with it, I don’t even try.

AI coding tools aren’t ready yet for us to step that far back. They can outrun us and generate a tremendous amount of code quickly. That might be tolerable in an exploratory effort like prototyping.

But in production, especially in regulated industries, security, safety, and privacy are at stake. There we remain accountable for every line written and every behavior introduced. LLMs can do a lot, but right now they’re often better as task tools, like a table saw we can control. They haven’t proven themselves to be wholly autonomous agents worthy of our trust.

We can’t trust ourselves to catch the issues merely by reading the code later. Even if it does work well, we may find what the AI comes up with to be opaque. Although it’s tempting to let the tool set the pace, losing control means working blind and trusting blindly. To be responsible for our work means we have to be able to engage with it. As with power tools, we need to own the perceive-decide-act speed we can handle. Losing sight of that risks making mistakes compound faster than we can recover from.

If you’d like to better manage your pace developing software with LLMs, take a look at our rails-consultant open source project with skills for /slice, /challenge, socratic-review, and more. Or reach out to us to discuss your project and how we can help.