DEV Community: Leo Yang

A Practical Guide to Claude Code for Backend Engineers

Leo Yang — Thu, 11 Jun 2026 16:33:18 +0000

Claude Code has become my default for backend work that involves more than a single file. Here is the workflow I settled on after a few false starts.

The setup that matters

Two things made a real difference for me:

A clean AGENTS.md that lists the project conventions, the test command, and the things it must never touch.
A Makefile target that runs the full check, not just the unit tests, so the model sees failures it can react to.

The shape of a good task

I try to write every prompt as a small story: what I want, why I want it, and how I will know it works. Something like:

Add a POST /v1/sessions/:id/cancel endpoint. It should be idempotent, return 204 on success and 404 if the session does not exist. Add tests for both paths and make sure the existing webhook tests still pass.

The more concrete the success criteria, the less I have to argue with it later.

When I do not use it

Anything that touches money, auth tokens, or production data does not get pasted in. The risk is not worth the time saved.

Happy to compare notes if you have a different setup that works for your team.

How I Use Codex CLI to Ship AI Features Without Losing My Mind

Leo Yang — Thu, 11 Jun 2026 16:32:44 +0000

I have been using Codex CLI as my daily driver for AI-assisted coding for a few months now, and I keep coming back to a handful of patterns that made my work faster and less error-prone. This post is a short, opinionated tour of the workflow that finally clicked for me.

Why another AI coding tool?

I bounced off several chat-only assistants because they forget context the moment I switch files. Codex CLI runs in the same terminal where my project lives, so it can actually read what I am looking at, run tests, and propose diffs I can review line by line.

The three commands I actually use

codex "explain this function in plain English"
codex --edit to let the model propose and apply small refactors
codex --plan when I want a written plan before any code changes

Lessons from the trenches

Always commit before letting it edit. It is rare, but it does occasionally nuke something.
Treat the first response as a draft, not an answer. I almost always ask for a second pass.
Keep the change scope tiny. The smaller the diff, the better the review.

What is next

I am still figuring out how to use it well for non-code tasks like writing tests, reviewing PRs, and triaging issues. If you have a workflow that works for you, I would love to hear it in the comments.

Probe Tags

Leo Yang — Thu, 11 Jun 2026 16:07:39 +0000

body

text

Probe Title

Leo Yang — Thu, 11 Jun 2026 16:07:06 +0000

Hello body

This is the body.