How to Stay in Control When Coding with LLMs

Introduction

This guide is for developers and engineers building real systems with large language models. Tools like Claude Code and GitHub Copilot are powerful. They can read code, propose designs, and write large chunks of implementation. They are not decision makers. You own the architecture, the risks, and the final result.

Think of an LLM as a thinking partner. It explores options. It drafts plans. It points out gaps. You decide what path to take and where to draw the line.

Writing Before Coding

• Start with a document, comments, or a rough design.
• Write what you want to build, why it exists, and how it should behave.
• Do not write code if you cannot explain the feature in plain language.
• For example, define what is cached, how long it lives, and what happens when it is wrong.

Create a Plan with Claude Code / Copilot

• Give Claude Code your notes and the current codebase.
• Ask it to read everything.
• Ask it to explain what it thinks the system does.
• Ask it to list open questions.
• Use this to expose hidden assumptions.
• For example, catch wrong ideas about state or data flow early.

Persist the Plan in a Markdown File

• Store the plan in a single markdown file in the repository.
• Update this file after every completed step.
• Treat it as the source of truth.
• Ask the LLM to always read this file before proposing changes.
• Ask the LLM to update it after each phase.

Turn the Plan into a To Do List

• Break the plan into small, testable tasks.
• Give each task a clear outcome.
• Add endpoints, migrations, and tests as separate items.
• Review and merge in small steps.

Read Code More Than You Write

• Use LLMs to summarize flows and explain legacy logic.
• Look for risky areas before changing anything.
• For example, trace how billing or pricing works before modifying it.

Think in Failure Modes

• Ask what breaks first.
• Check timeouts, retries, and partial failures.
• Plan for slow or missing downstream systems.

Measure Before You Optimize

• Add logs, metrics, and traces first.
• Use data to find bottlenecks.
• Do not rely on intuition.

Design for Deletion

• Keep every abstraction easy to remove.
• Avoid components that require a rewrite to delete.
• Prefer simple designs.

Make Trade Offs Explicit

• Write down latency versus consistency.
• Write down speed versus safety.
• Write down cost versus accuracy.
• Use this to keep decisions clear.

Write Code for the Next Reader

• Use clear names.
• Keep functions small.
• Make control flow obvious.

Use Constraints on Purpose

• Set memory limits.
• Set timeouts.
• Add rate limits.

Refactor Continuously

• Improve small things every day.
• Avoid waiting for big rewrites.
• Use LLMs to refactor safely.

Test at Every Level

• Write unit tests for edge cases.
• Use Claude Code and Copilot to generate test scaffolds.
• Run integration tests after each phase.

Document the Implementation

• Explain how the system works.
• Explain why it was built that way.

You Own the Code

• Treat the model as a tool.
• Make the final decisions yourself.
• Read and review every line before committing to git.

Conclusion

Large language models change how teams build software. They speed up planning, reading, and coding. They do not remove the need for judgment, testing, and ownership.

Developers who write before coding, question assumptions, design for failure, and keep systems simple get the most value from LLMs. The result is software that is easier to trust, easier to change, and easier to scale.