Taking the right kind of vibe-coding risk

2 min read Original article ↗

Taleb once said that it’s easy to take the risks you can measure rather than measure the risks you can take.

Vibe-coding is fast becoming pejorative in industry circles. But that’s mostly because people take risks that they can’t measure with coding agents.

The level of risk you take with these tools is very context dependent. For example, you might use Claude Code very differently in your weekend side project, than you’d use in your day job where you’d have to seek an approval in your PR.

Therefore, I maintain the lens we apply to coding agent usefulness must also be context-dependent.

Generally:

  • Cost or the probability of getting the output wrong is negligible
  • Output can be easily pattern matched by myself and the reviewers (either via eyeballing or asserted by existing behaviour)

Coding Agent Usefulness

  • Short-lived Tests as Scaffolding - Often when I work with legacy / poorly tested part of a codebase that’s been running in production for a while, I go overboard on getting LLMs to assert the correct behaviour with tests as scaffolding. These tests are very verbose, and make little sense in being maintained. However, they provide a safety net over the commits to ensure no risk of regression. They are cheap to generate, and easy to tear down (scaffolding style) when the task is completed.

  • Generating UI artifacts - I don’t go hunting for small svg icons when I have to do a quick frontend tasks. I ask the LLM to generate me one. (For example, the icons that you see on the front-page of this site are all LLM generated)

  • Reducing dependencies - I don’t import dependencies like lodash anymore. I create small functions in a utils file. Given the recent string of supply chain attacks, this is looking more and more like a good idea.

  • Ops Work - I’m somewhat divorced from maintaining dev scripts and Makefiles. It’s just easy to ask an LLM to generate script (sometimes with a --dry-run mode) and document itself on make help or equivalent.

[1] All good code forces you to become your own reviewer down the line. To get more philosophical- one must not vibe-code what one doesn’t want to review.

[2] This is not to say you shouldn’t vibe-code your whole weekend project. After all, if it’s extremely low stakes, it doesn’t make sense to pay the cost to verify things.