Renaud Richardet - Blog

Verifiability

All relatively simple problems can readily be [[solved, coded]] by LLMs.

All problems that are complex but verifiable in one systematic way [[have, will]] fall to LLMs.

Only the problems that are too [[small, niche, complex]] to be easily verified will be solved by humans (with the help from LLMs)

Quote from Martin Fowler

"Any fool can write code that a computer can understand. Good programmers **write code that humans can understand"

Martin Fowler

current workflow to code with LLMs

my current workflow to code with LLMs

[[update: since summer 2026, agents needs way less hand-holding than described below]]

  1. provide a 200-lines context file to my project in AGENTS.md
  2. project objectives
  3. where to find relevant stuff (list of significant files)
  4. preferences ("don't rebuild the project, as i'm already doing it")

  5. have a clear mental model of what feature i want to build.

  6. i pretty much know how i would code it by hand
  7. i know that the size / scope / complexity is manageable for the LLM

  8. start dictating the new feature I want to work on. Dictating allows me to give more information and thus provide more context to the LLM. I've noticed that the LLMs are super good at sorting out my brain dump, and I get better results than typing it myself.

  9. terminate my initial message with: "Before you do that, ask me clarifying questions. Number your questions (1, 2, 3) and label answer options (a, b, c, ...). Keywords are fine. " --> same as "Plan mode"

  10. rinse and repeat until questions are trivial

  11. type "go", let the LLM cook for a few minutes

  12. review significant files (e.g. backend), skim medium important files (ts, html), skip a few (css)

  13. run some tests

not using: - on stuff that i don't know about (LLM will run me in circles) - biggest models (latest Opus), unless nasty bug - Claude code: i like the concept, but prefer to be in an IDE where i can follow the process more - parallel agents (too much brute force to me) - vibe coding (:= not look at the code), unless for tiny 1-shot projects

Older posts

All posts, by year -->