Giant Robots Smashing Into Other Giant Robots

Copy as Markdown: AI-friendly blog posts

2026-06-03T00:00:00+00:00

Our blog posts now have the option to Copy as Markdown to help our robotic friends more easily consume our content.

(It’s just up there, below the title)

Click the button and you will get this blog post copied to your clipboard in cleanly formatted Markdown. Then paste it into any prompt to give your AI the context it needs.

Speaking their language

Markdown is the lingua franca of LLMs and giving them the ability to read Markdown simplies their job (and uses fewer tokens) compared to parsing HTML directly.

We’ve done a few things to make their lives easier:

The Copy as Markdown button - this is mostly for us humans, to more easily pass context to the AI
The Markdown version of any blog is available by appending .md to the URL
A hint in the of each post lets requesters know the markdown alternative is available

 rel="alternate" type="text/markdown" href="https://thoughtbot.com/blog/copy-as-markdown-ai-friendly-blog-posts.md">

That’s it. No setup, no plugin, no incantation. Just click, paste, and happy contexting.

The Bike Shed Ep 501: What makes for good technical writing?

2026-06-02T00:00:00+00:00

Sally and Joël get technical as they lay out their thoughts on blog posts.

The Four Signals of AI Observability

2026-06-01T00:00:00+00:00

A few months ago we shipped a chat experience to production. Users ask a question, our app routes it through an LLM model, the model calls a few internal tools, and an answer comes back from it.

It worked. Sort of.

When the model answered well, we had no idea why. When it answered badly, we had no idea either. The model was a black box attached to our app, and our best debugging tool was reading logs and guessing.

We realized our app could not answer a very normal operational question:

Show us every chat where the user said the answer was bad, group them by which version of the system prompt was loaded, and let us read the whole conversation, including which tools the model called.

It’s the AI equivalent of “show me every 500 errors on this endpoint after deploy X.” But our app couldn’t answer it.

That was the trigger to stop looking for a smarter model and start looking to add an observability layer. We ended up using Langfuse, but the specific vendor matters less than the capabilities. Helicone, Arize Phoenix, LangSmith, and Braintrust all solve versions of the same problem.

After a couple of months of iteration, we noticed that the things we need came in four flavors. I call them the four signals that every AI feature needs to emit about itself.

A version on every prompt. Which exact words did the model see today?
A trace shaped like the actual work. What did it call, in what order, with what arguments?
A score from the user. Did the human like the result?
A score from another model. When the human is quiet, who is grading?

Of course we can build an AI feature without all four. We just can’t improve it on purpose.

A version on every prompt

The first thing we did was move every prompt out of the code and into a versioned store the app fetches at runtime.

# The code never references a version. It asks for a label.
template = PromptRepo.compile(name: "classify_question", label: "production")

# A human moves "production" between versions in the Langfuse UI.
# Promotion is a click. Rollback is a click. No deploy.

The first time we rolled back a bad prompt by clicking a button instead of reverting a PR and waiting for CI, we knew this was the right shape.

Once prompts became content, the people closest to the problem became the people writing the prompts. The feedback loop got much shorter, and the quality went up.

A trace shaped like the actual work

A chat is not a single call. It is a small program. Classify the question, load the right prompt, call a tool or two, then compose an answer.

If your trace is one row, you only know that something happened. A trace tree tells you what actually happened. If your trace is a tree of calls, you have a database of decisions the model made.

# Before: one log line, no shape
[INFO] chat_completed user_id=123 duration_ms=4200 tokens=1840

# After: a tree of decisions
trace: "chat"
  span:       load-prompt                  (version=production:v12)
  generation: classify-question            (model=haiku, category="billing")
  generation: compose-answer
    span:       tool-call.lookup_invoice   (200ms)
    span:       tool-call.lookup_customer  (180ms)
  generation: final-response               (model=sonnet, 1.2k tokens)

Each node carries the prompt name and version, the model id, token usage, and a set of metadata fields we control. The customer it ran for, the category the question was classified as, which tools ran, whether the conversation was new.

That metadata is the part that turned out to matter most.

The first time we filtered traces to “every chat in scope X where a particular tool ran and the user said the answer was bad”, we had a small realization. The trace list was not a log anymore. It was a queryable database of decisions the model made.

The rule we would write on a sticky note: tag your traces with the dimensions you will want to filter on later. It is cheap up front and impossible to add later, once you wish you had it.

A score from the user

Every assistant message in the UI has a thumbs up and a thumbs down. When a user clicks one, we save a row and post it back to the observability tool as a score on the trace.

A thumbs-down on its own isn’t actionable. A thumbs-down attached to a trace tells you what the model saw, what it called, which prompt version produced it, and what category the question fell into. Now you can ask: are downvotes concentrated in one category? On one prompt version? After one specific tool call?

You should review downvoted traces. It takes time, sometimes they’re noise, the user wanted something we don’t support, or hit thumbs-down by accident. But maybe one in ten is a real signal, and that’s the one that turns into a prompt change, a new tool, or a bug fix.

The point of all this plumbing is one new query.

Show us every trace a user labeled bad.

Once you can run that query and read the entire conversation that produced it (prompt version, tool calls, model, latency, everything), you stop the guessing game.

A score from another model

Human feedback is useful but rare. Most users do not click anything.

So we added a second model to grade the first one. A background job pulls finished chats, runs them through a separate “judge” prompt (versioned and labeled in the same store as the production prompts), and writes the result back as a score on the same trace.

Now the trace carries two streams of judgment. When the user and the judge agree, our judge is in sync with real users. When they disagree, that is the most interesting trace in the system. Either way, the judge runs on every chat, so a regression shows up the same day we ship the prompt that caused it, not a week later when somebody complains.

Our judge scores things like factuality, instruction-following, completeness, hallucination, and whether the assistant actually used the right internal context.

We underestimated this one. A judge that catches a regression before it ships is worth more than a faster or smarter model. It is the only signal that scales when nobody is clicking thumbs.

The lesson we had to learn: the judge is just a prompt. It can be wrong. It needs versioning and a Playground and a rollback button, exactly like a user-facing prompt.

Each signal writes back to the same trace. That’s the whole trick

Four signals, one idea

The four signals overlap, and that’s on purpose. The prompt version shows up on the trace. The user score attaches to the trace. The judge score attaches to the trace too. They are not really four separate things. They are the same idea viewed from four different angles.

Make the AI feature observable, then you can change it on purpose.

For a while I treated AI features like a different category of software: less debuggable, less testable, less under our control. An AI feature is software. It has inputs, makes decisions, produces outputs, and can be observed like anything else.

The four signals overlap on purpose. They are one idea, make the system observable, viewed from four angles. What changes once you have them isn’t that the model gets smarter. It’s that you stop hoping. You ship a prompt change knowing the judge will tell if it regressed. You read a downvote knowing you can replay the exact conversation that produced it. You promote a new prompt to production knowing you can roll it back in one click if it breaks.

The model is the engine. The observability layer is the dashboard. You can drive without one. You just can’t drive on purpose.

Can you really launch a tech business with a no-code app builder?

2026-05-29T00:00:00+00:00

Sometimes AI really does feel like magic, and right now just about any no-code app builder provides that magical experience for entrepreneurs with big ideas but no coding skills.

You can spend half an hour typing a few details about your app into Lovable and create a simple, functional app with a polished user interface. Then add six new features over the weekend without ever hiring a developer or talking to a real user.

Besides Lovable, there’s Bolt, Base44, Bubble, Replit and others. These AI app generators allow just about anyone to build software by describing it through text-based prompts. No technical knowledge, design sprint or VC funding required. Many even allow you to export the code, so you can continue your project outside the tool.

It’s exciting to mockup ideas so quickly, but can you launch a real business with a no-code app builder? Are non-developers really creating high quality, production-ready code?

Making money with AI-built apps

Startup culture loves to celebrate the outliers, the big, against-the-odds success stories. Lovable’s own ad campaign hypes ShiftNex, a healthcare staffing platform that hit $1 million annual recurring revenue (ARR) in five months, and Plinq, a background check app for dating built in 45 days that achieved $465,000 in ARR.

Not to be left out, Replit publicizes GEN AIPI, an AI education platform with training courses, payments, certifications and an admin system that was originally built in just three days with no dev team. The business achieved $180,000 in revenue in the first six weeks.

But the ad campaigns don’t include all the entrepreneurs who encountered big—or even impassable—roadblocks attempting similar business results. There’s often a point of diminishing returns with no-code app builders. At first, there’s instant gratification, but eventually, it becomes slower, harder and sometimes impossible to refine existing features or add new ones.

Are AI-generated apps production ready?

Unless you’re in a highly regulated industry, you can push software created with a no-code app builder to production. But that’s just the first challenge on the road to a stable and profitable tech business. Will performance hold up when you hit 1,000 or 10,000 users? Can you easily add new features? When do you add an engineering team?

AI app generators allow you to bring an MVP to life quickly, but scaling a successful, long-term tech business is much tougher. It’s nearly impossible for non-technical founders to evaluate potential risks in a code base or to even know what risks to look for in the first place. A big one is data security: How hard would it be for a bad actor to tap into sensitive data or user information?

And even when a founder does identify a bug or issue, it can be hard for an AI app builder to solve. If you already have users and things start breaking, it can easily become a hair-on-fire emergency. One that might leave traditional developers trying to get up to speed on thousands of lines of code with no context.

Then there’s an even bigger issue. Entrepreneurs are often so focused on what they can build that they forget to think about what they should build. With traditional development barriers gone, it’s easy to skip the strategic work of identifying a real problem to solve for real users. We’ve honed an entire Shaping Sprint process to work with founders on solidifying a product strategy and direction.

Despite these concerns, no-code app builders may be a fit for small businesses in industries with relatively low volume, regulation and security risk. We’re just at the beginning of AI app builders evolving and growing in capability, so it’s impossible to know exactly what the future holds.

No-code app builders 2.0

Right now, most software created by no-code app builders amounts to a prototype: useful for learning, but often difficult to scale into a successful long-term business. The current generation of tools is optimized for speed and instant gratification, but not necessarily for helping founders build the right product or make thoughtful product decisions along the way.

We think there’s an opportunity for the next generation of AI product tools to evolve beyond pure “vibe coding.”

Not just generating interfaces and features faster, but helping founders and teams:

Think through product direction
Validate assumptions
Prioritize the right problems
And move from idea to real product more intentionally

That’s part of why our team has been experimenting publicly with new workflows and AI-assisted product design approaches through our ReadySetGo initiative and weekly AI in Focus livestream series.

We’re still early in exploring what this category could become, but one thing already feels clear: as AI lowers the barrier to building software, the ability to identify the right thing to build may become even more important.

Giant Robots Podcast Ep 612: Do fish drink?

2026-05-28T00:00:00+00:00

The Giant Robots trio are back to discuss the development of thoughtbot’s ReadySetGo app, and whether AI might be causing developers to go backwards.

This week in #dev (May 15, 2026)

2026-05-28T00:00:00+00:00

Welcome to another edition of This Week in #dev, a series of posts where we bring some of our most interesting Slack conversations to the public.

Alternative Text for CSS-Generated Content

Matheus Richard learned that the CSS content property accepts alternative text for screen readers, separated by a /:

.warning::before {
  content: "⚠️" / "Warning";
}

Without the alt text, assistive technology either reads out the emoji name or skips it entirely. More details in Stefan Judis’ article.

A Faster UI for Large GitHub Diffs

Matheus Richard shares diffshub, a tool that renders PR diffs GitHub struggles with. It’s a drop-in replacement: swap github.com for diffshub.com in any PR URL, like https://diffshub.com/oven-sh/bun/pull/30412.

Aube, a New JavaScript Package Manager

Jared Turner shares Aube, a JavaScript package manager from the creator of Mise. It’s pitched as fast, compatible with existing lockfiles, and security-focused, including a 24-hour cooldown before newly published versions can be installed.

Thanks

This edition was brought to you by Jared Turner and Matheus Richard. Thanks to all contributors! 🎉