DEV Community: Kamil Chmielewski

Let It Crash - Turning Failure into Your Most Reliable Signal

Kamil Chmielewski — Mon, 04 Aug 2025 00:00:00 +0000

The Story: Thirteen Failures, One Flashback

I shipped thirteen broken releases before I remembered the one-line fix.

Each failure looked different—misleading CLI output, race conditions, unmet dependencies—but the aftermath felt identical: a new layer of Bash gymnastics glued on top of the old one.

By version 1.1.17 my release script looked over-engineered: a multi-line retry loop packed with debug echos, four separate grep/sed filters, and a blind 10-second sleep between attempts. Nothing worked.

Version 1.1.18 swapped 26 lines for just 8:

# Simple retry loop — succeeds when the dependency appears.
for i in {1..12}; do
  cargo publish -p zod_gen_derive && break || sleep 10
done

It passed on the first run.

The Setup

I maintain two Rust crates: zod_gen and zod_gen_derive. The second depends on the first, so a release needs to:

Publish zod_gen.
Wait until crates.io accepts it.
Publish zod_gen_derive.

Where It Went Wrong

I paired with an AI agent to automate the sequence. Here's where things went sideways: the AI kept proposing reasonable-sounding incremental fixes. "Let's add the --registry flag." "Maybe we need better pattern matching." "How about more debug output?" Each suggestion looked logical in isolation, so I kept saying yes.

This created a dangerous feedback loop. I wasn't thinking about the problem the way I would if coding manually—I was just reviewing and approving AI suggestions. The script ballooned through versions 1.1.8 → 1.1.17, adding:

cargo search, cargo info --registry, and half-dozen flags.
Three layers of regex filters plus debug logging.
Sleep statements tuned by guesswork.

The reality? I'd preached "let it crash" for years, but I thought this was a trivial script we could create in minutes and forget about it. I completely off-loaded the thinking to my AI assistant for this "small thing." The AI's incremental "improvements" kept me in a rabbit hole I would never have entered manually.

Result? A trail of tags on crates.io—and zero successful dependent publishes.

Only after thirteen failures did the old Erlang lesson resurface.

The Principle: Failure as Signal, Not Enemy

Why Engineers Avoid Failure

Engineers hate red. We instinctively add checks to avoid the red X before it appears. That reflex feels safe, yet it breeds hidden costs:

Complexity: Each avoidance layer creates more states to debug.
Brittleness: Tools change output; your regex doesn't.
Time drain: You debug the detection logic and the real problem.

Red flags that signal "prediction gone wild":

"Let's just parse the CLI output first …"
Multiple health-check endpoints before every API call.
Deeply nested if/else chains sprinkled with sleeps.

If you spot those, you're predicting instead of observing.

The Erlang Alternative

The Erlang/OTP runtime treats process failure as routine. A crashed process restarts under a supervisor; the system stays healthy. Joe Armstrong's mantra: "Let it crash."

For the technical details: Fred Hébert's "The Zen of Erlang" explains beautifully how Erlang's supervision trees and error handling work in practice.

Translate that philosophy to automation:

Attempt the operation now.
If it fails and the failure is recoverable, wait and retry.
Success ends the loop.

Why it works universally:

Note: A genuine failure is the most accurate readiness probe you will ever find.

Fewer moving parts → fewer bugs.
Self-correcting: The loop ends itself when conditions are right.
Clear feedback: The error message tells you exactly what is missing.

The Working Implementation

Here's the final Bash snippet that finally shipped zod_gen_derive:

for i in {1..12}; do # 2 minutes total
  if cargo publish -p zod_gen_derive; then
    echo "zod_gen_derive published successfully!"
    exit 0
  else
    echo "Dependency not ready—retrying in 10s…"
    sleep 10
  fi
done
echo "ERROR: Failed to publish zod_gen_derive after 12 attempts"
exit 1

Key details:

Retry budget prevents infinite loops.
Immediate feedback (cargo publish's own error) shows why it failed.
No parsing—we trust the tool to tell the truth.

Broader Applications: When to Let It Crash

The Decision Framework

Before building prediction logic, ask yourself:

Am I trying to predict whether an operation will succeed?
Is the failure recoverable and informative?
Would the failure tell me exactly what I'm trying to detect?

If yes to all three → let the operation fail and retry.

The pattern scales from shell scripts to distributed systems—failure as signal works at every level.

Prompting Your AI Assistant to "Let It Crash"

LLMs seem to default to "failure avoidance" patterns. The "let it crash" philosophy is probably too niche for their general training—most programming tutorials teach elaborate error checking, not embracing failure as signal.

This means we need to explicitly guide them with prompts. Here are my initial attempts (still experimenting):

If the operation can fail safely, propose a retry loop instead of a readiness check.

Prefer capturing and reacting to the real error message over predicting success.

Show me a version that removes parsing and relies on direct retries (let-it-crash style).

Full disclosure: These prompts are untested. I just learned this lesson myself and will be refining them as I inevitably get kicked again by "avoid failure" thinking. Consider them starting points, not proven solutions.

Conclusion

Thirteen failed attempts tried to avoid failure; one succeeded by trusting it. The core lesson: failure itself is often the most reliable signal you can get. Instead of building elaborate prediction mechanisms, let the operation tell you when it's ready by trying it directly.

The AI collaboration angle was just how I ended up forgetting this principle—but the principle itself is universal and timeless.

Next time you automate a workflow, start with a naive attempt, watch it crash, and wrap it in a controlled retry. Your future self (and your CI budget) will thank you.

Read the original article on Chm.ski Labs Blog →

Bridging Rust and TypeScript with zod_gen - End-to-End Type Safety at Cimatic

Kamil Chmielewski — Fri, 25 Jul 2025 00:00:00 +0000

Building [Cimatic]'s MVP sent me down several technical paths—some more interesting than others. The big architectural picture deserves its own post next week (subscribe to the RSS feed to catch it), but here's a smaller piece that turned out pretty useful: unified types between Rust and TypeScript. Write a struct once in Rust, then use it safely everywhere – API, server-side rendering, front-end validation, tests, docs.

As a side-effect, I ended up building two small crates that handle this—turned out pretty useful:

Crate	What it does
`zod_gen`	Library + helpers for building Zod schemas in Rust
`zod_gen_derive`	`proc-macro` implementing `#[derive(ZodSchema)]` so the boilerplate disappears

Together they let me infer Zod validation and TypeScript types directly from the Rust structures that already power the backend.

The Problem

You know how it goes. You start with clean Rust structs for your API:

Rust structs defined the DB models and HTTP payloads.
TypeScript interfaces duplicated that shape on the front-end.
Zod schemas duplicated it again for runtime validation.

Three sources of truth → triple maintenance pain. Change a field in Rust? Better remember to update the TypeScript interface. Add validation? Don't forget the Zod schema. Miss one? You get those annoying type mismatches that could've been caught at build time.

The Solution in 30 Seconds

The idea was simple: make the Rust struct the source of truth for everything else.

// backend/src/models/user.rs
use zod_gen::ZodSchema;
use zod_gen_derive::ZodSchema;

#[derive(ZodSchema, serde::Serialize, serde::Deserialize)]
pub struct User {
    id: u64,
    name: String,
    email: String,
    is_admin: bool,
}

That's it. One derive macro.

Running a tiny generator binary…

cargo run -p generate_zod_types  # part of Cimatic

…spits out frontend/types/generated/user.ts

// Generated User.ts
import { z } from 'zod';

export const UserSchema = z.object({
  id: z.number(),
  name: z.string(),
  email: z.string(),
  is_admin: z.boolean(),
});

export type User = z.infer<typeof UserSchema>;

No manual syncing. No drift.

Inside the Crates

I kept the design deliberately simple. Two small crates, each with a focused job:

zod_gen – the core

ZodSchema trait – every Rust type that can emit a schema.
Helpers (zod_string, zod_enum, zod_object, …) return ready-to-embed Zod snippets.
ZodGenerator – collect many schemas and write a single .ts bundle.

zod_gen_derive – the icing

Parses structs (named fields) & enums (unit variants).
Generates a ZodSchema impl that calls back into zod_gen helpers.
Fails fast on unsupported shapes so your build never lies.

Both crates are MIT licensed and <20 KB combined. I wanted something you could drop into any project without thinking twice about dependencies.

How It Worked Out

The migration went smoothly:

Replace old hand-rolled TS interfaces with generated ones.
Swap z.object({...}) declarations for imports from generated/*.ts.
Delete 1,300 lines of duplicated type and schema definitions – 🔥.

Build time impact: +0.4 s (proc-macros are cached anyway).
Runtime impact: zero.
Bug impact: vanished – type inference works at both ends now.

The best part? That nagging feeling of "did I remember to update the frontend types?" just disappeared. The compiler handles it now.

Current Limitations

Only supports named-field structs and unit enums right now. Tuple structs/enums are on the todo list.

This covers all the cases I've needed so far. Most API types are just structs with named fields anyway. KISS!

What's Next?

Coming next: "SSRUI + Partials Architecture"
where I'll show how [Cimatic] renders HTML on the server, streams small HTML partials for dynamic updates, and why I ditched a fat CSR build entirely. That's where the real architectural magic happens.

If you end up trying these crates out, I'd love to hear what you build with them. Always curious to see how others solve the same problems.

Useful Links

Repo: https://github.com/cimatic/zod_gen
Docs: https://docs.rs/zod_gen

Happy hacking! 🚀

Read the original article on Chm.ski Labs Blog →

Vibe Coding is Cheap, Show Me The Demo: How I Code with Playwright UI as My Co-Pilot

Kamil Chmielewski — Thu, 17 Jul 2025 00:00:00 +0000

In the era of AI-generated code, vibe coding has made writing code effortless but proving it works crucial. Learn Show Me The Demo Development - a methodology that treats demos as specifications using Playwright UI for real-time feedback.

The Evolution of My Development Philosophy

Throughout my career—first as an engineer, then as a product manager—I practiced what I called "Demo-Driven Development." This approach stemmed from a core belief that shaped my entire career: our work is only done when the user says so. We're not producing code—we're solving problems. This user-centric philosophy meant every sprint was planned around the next demo where I tried to show how we were solving a user's problem, every backlog item was prioritized by its demo impact, and every feature was built with the end presentation in mind. The demo wasn't just a showcase—it was the north star that guided all development decisions.

Now, as a solo founder building MicroSaaS products, I've pushed this philosophy to its logical extreme. I'm no longer just the product manager planning demos; I'm the developer, QA engineer, designer, and marketer all rolled into one. This reality has forced me to evolve my approach into what I now call Show Me The Demo Development.

Why Solo Founders Can't Afford Bugs

When you're building alone, every bug is a crisis. There's no QA team to catch regressions, no dedicated support team to handle customer complaints, and no development team to quickly patch issues. If I ship a broken feature, I'm the one who has to drop everything to fix it. As a solo founder building multiple products, I can't afford that kind of disruption.

This constraint led me to a crucial realization: the scenarios I need for product demos are exactly the scenarios I need for regression testing. Why write tests separately when the demo flow IS the test?

This becomes even more critical when working with AI agents to modify your code. While AI is incredibly capable of writing code, it can also break existing functionality in unexpected ways and unexpected places. Without solid regression guardrails around the process, you'll find yourself running in circles, fixing one thing while unknowingly breaking another. Believe me, I've been there a few times in the last month alone.

Enter Show Me The Demo Development

We're living in the era of vibe coding, where developers rely on AI to generate code without reviewing the output. Vibe coding—the practice of letting AI write code based on rough intentions and good vibes—has made code generation effortless but verification crucial. When AI can generate endless code based on intentions alone, the old saying "talk is cheap, show me the code" has evolved into "vibe coding is cheap, show me the demo." Proving your software actually works has become more important than just writing it. Show Me The Demo Development embraces this vibe coding reality by making working demonstrations the foundation of your development process.

Just as Infrastructure-as-Code (IaC) revolutionized DevOps by treating infrastructure as versioned, testable code, Show Me The Demo Development treats your product demonstrations as first-class development artifacts. Like Configuration-as-Code (CaC) ensures consistent environments, and Policy-as-Code (PaC) codifies business rules, this methodology codifies your user scenarios.

Show Me The Demo Development is built on a simple premise: every feature starts as a Playwright test that demonstrates the complete user scenario. Unlike Behavior-Driven Development (BDD) which focuses on creating business-readable specifications for stakeholder communication, Show Me The Demo Development creates visual, interactive demonstrations that can be directly shown to customers and prospects. While BDD helps teams align on requirements, Show Me The Demo Development creates actual sales materials—though it's especially powerful for solo founders.

My Show Me The Demo Workflow

Here's how I actually work:

Open Playwright UI alongside my code editor
Write the complete scenario flow - codifying what the user does and the expected outcomes as my specifications
Run the scenario in Playwright UI to see which parts fail
Implement the functionality (often with AI assistance) to make the scenario pass
Refine the scenario with more detailed checks and edge cases as needed

It's like TDD, but instead of unit tests, I'm building complete user journeys. The Playwright UI becomes my real-time feedback loop, showing me exactly what the user will experience.

You can even point an AI agent to run the tests via command line and ask them to fix failing tests. Just watch carefully that they don't change the demo scenario code to make tests pass—the scenarios are your specifications and should remain unchanged.

But What About the Test Pyramid?

I know what you're thinking: "This violates the Test Pyramid! E2E tests are slow and brittle. You should be running fast unit tests during development, not heavy browser automation."

You're absolutely right about traditional E2E testing. But Show Me The Demo Development isn't traditional E2E testing—it's specification-driven development that happens to use browser automation. The key difference is that I've developed several techniques to make these tests run fast enough for real-time development feedback.

I'm not abandoning unit tests entirely, but for solo founders building B2B SaaS products, the demo scenarios ARE the most critical tests. When your entire business model depends on live customer demonstrations, ensuring those scenarios work perfectly is more valuable than having 100% unit test coverage on utility functions.

I'll be sharing my specific techniques for fast Playwright development workflows in an upcoming blog post. Subscribe to my RSS feed to get notified when it's published—these optimizations are crucial for making this approach practical.

A Real Example: Building GitHub Actions One-Click Analytics

When building Cimatic (my GitHub Actions analytics platform), I started with this scenario:

Left side: The test scenario and the implementation open in Vim
Right side top: Playwright UI, with the browser window showing the scenario
Right side Bottom: AI agent CLI and a terminal showing logs from services

This visual demonstrates the core concept: writing the demo scenario first, then building the product to make the scenario pass.

The Magic of Incremental Development

With Playwright UI open, I can run just the first few lines, see the page load (or fail), then code the /analyze route. Run again, see the form appear, then implement the form handling. Each step builds on the previous one, and I always know exactly what the user experience looks like.

This approach has several unexpected benefits:

👁️ Immediate Visual Feedback. Unlike unit tests, I see the actual UI as I build it.
🌐 Real Browser Environment. No mocking—I'm testing in the same environment users will experience.
🎯 Demo-Ready Code. When the test passes, I have a working demo scenario.
🛡️ Regression Safety Net. Future changes can't break the core user journey without me knowing.

From Test to Demo Video in Minutes

Here's an unexpected bonus I discovered: once my scenario test is working, creating a demo video becomes trivial. Just like Documentation-as-Code keeps docs in sync with code, my demos stay perfectly synchronized with actual functionality. I just:

Record the Playwright test execution using screen recording
Add voiceover explaining what's happening
Edit for pacing and add captions

The result is a polished product demo that shows real functionality, not mockups or staged data. Customers see exactly what they'll get.

Conclusion

As a solo founder, I can't afford to build features that don't work, create demos that don't convert, or waste time on separate testing infrastructure. Show Me The Demo Development solves all three problems with a single approach.

Working this way feels incredibly productive because I don't need to manually click through the same demo flow for the 82nd time while coding—this alone is life-changing! Every change is instantly visible and testable, I'm building sales materials as I code, and regressions are caught immediately instead of in production.

Like how Security-as-Code embeds security into every development step, Show Me The Demo Development embeds customer validation into every feature. Every line of code I write serves multiple purposes: it implements the feature, tests the user experience, and prepares the demo. This isn't just efficient—it's essential for competing against well-funded teams while working alone.

The next time you're building a feature, try opening Playwright UI alongside your editor. Write the scenario first, then make it real. You might find, like I did, that your best development tool was hiding in your testing toolkit all along.

Want to see Show Me The Demo Development in action? I'm documenting my journey building multiple MicroSaaS products using this approach. Follow along as I build Cimatic (GitHub Actions analytics), and other products using Show Me The Demo Development.

Read the original article on Chm.ski Labs Blog →