Agentic coding: a great pair programmer, if you know what to ask for

This whole site was built with a coding agent. We used Claude Code in VS Code, over a single long session. It ported the theme to a new version of Zola, wrote and tested every code example in these posts, built the deployment script, and checked the nginx configuration on the live server, header by header.

It was genuinely impressive. It was also a good reminder that an agent amplifies what you bring to it. Here’s what we learned.

What “agentic” means

A chat assistant answers questions. An agent does the work: it reads your files, runs commands, edits code, runs the tests, reads the errors and tries again, until the job is done or it needs you.

That loop is what makes it powerful. When we asked why the site wouldn’t build, Claude Code didn’t guess. It ran the build, read the error, worked out that Zola 0.23 had moved to a new template engine, checked the migration guide, rewrote the templates, and rebuilt until everything was green. Then it inspected the generated HTML to make sure the output was actually right, not just error-free.

What Claude Code does really well

• It checks its own work. Every code example in our posts on Python, uv, testing and C++ was actually run, and the output in the posts is the real output. When an example didn’t pass a type check, it fixed the example and told us.
• It finds things you’d miss. Running the C++ example revealed that the logging library was writing into the middle of the JSON output. Property-based tests found that one version of a function silently drops letters like “ª”. A read through Gogs’ source code showed that it closes issues from commits on any branch, unlike GitHub.
• It looks before it touches anything. Before syncing the site to the server, it listed what was already there, noticed a .well-known folder used for certificate renewals, did a dry run, and made a backup. When the site went down minutes later, it read the logs and showed it was a config change, not the deploy, before anyone panicked.
• It knows a huge amount. nginx header inheritance, CMake presets, Conan lockfiles, Atom feeds, Hypothesis strategies. It rarely needed anything explained.
• It stays inside the lines. Claude Code asks permission before doing things that could cause harm, and you decide what it may do on its own. When it needed to run PHP inside Docker, we allowed one small wrapper script, not Docker in general.

Be specific about what you want

The single biggest factor in how well it goes is how clearly you say what you want. The agent will do something with a vague request. It does exactly the right thing with a precise one.

Vague	Specific
“Make the site faster.”	“I’m using nginx’s zstd_static on; and gzip_static on;, so have the build precompress the files.”
“Deploy it.”	“rsync to server:path/to/sites/html/.”
“Write about testing.”	“What Go, Python, C++, Rust and PHP use for tests. Use GoogleTest. Tests never prove there are no bugs, but they do prove what works as expected.”
“Fix the spelling.”	“Use US English spellings, not UK English.”

Good requests usually include:

• The goal, and why. “So nginx can serve precompressed files” tells it what “done” looks like.
• Constraints. Versions, tools you already use, things it must not touch.
• Where things are. Paths, hosts, which config file.
• How to check. “Show me the response headers” or “the tests must pass” gives it a target to verify against.

Corrections work the same way. When the first posts came out in British spelling, one sentence fixed every post, and the preference was remembered for the rest of the session and beyond.

You still need to know what’s out there

Here’s the catch. An agent is brilliant at how. It’s much less help with what, when you don’t know what to ask for.

Every good outcome in this project started with a choice a person made:

• Precompressing with zstd came from knowing nginx has a zstd_static module, and wanting it.
• Conan and Ninja for the C++ post came from years of building C++. “I forgot Ninja, definitely include that!” arrived halfway through the work.
• Self-hosting with Forgejo or Gogs came from already running them.
• Putting summaries in the feed came from looking at the build output and deciding a 393 KB feed was too big.

If you’ve never heard of Conan, you won’t ask for it. You’ll get a working build, probably a reasonable one, but not necessarily the one an experienced C++ developer would choose. The agent works within the frame you give it. It doesn’t know that your real problem would be better solved by a tool you never mentioned.

To be fair, it does fill in a lot within that frame. Once we’d asked for precompression and caching, it brought up the Vary header, the way nginx’s add_header silently drops other headers, and cache lifetimes for files without version hashes. Ask in the right area, and it knows the neighborhood well.

So the developer’s job shifts. Less typing, more:

• Knowing the landscape. Which languages, libraries, tools and services exist, and what each is good at. Our post on choosing the right tool matters more with an agent, not less.
• Making the choices. Picking the approach, then letting the agent do the legwork.
• Asking “is there a better way?” Agents are good at listing alternatives when you ask. They’re less likely to stop and say “you’re solving the wrong problem.”

Are agents creative? Not yet, or not quite

In our experience, agents are superb at recombining what’s known: applying a pattern from one place to another, following best practice, connecting documentation to your exact situation. That covers a huge share of everyday programming.

What they didn’t do was have the ideas. The Red-Green name, the theme and the voice of this site came from people. The agent didn’t decide that a post on testing should be built around the idea that tests prove what works but never prove the absence of bugs. It didn’t decide what the site was for. Taste, judgment about what’s worth building, and the leap to an approach nobody has written about yet all came from people.

Will that change? Maybe. The tools have improved remarkably quickly, and it would be foolish to say never. For now, the most effective way to work is as a partnership: you bring the direction, the knowledge of what’s possible and the judgment; the agent brings speed, breadth and tireless checking.

Working well with an agent

A few habits made a big difference:

• Use version control. Commit before big changes, and review the diff before you commit. Every change is then easy to inspect and easy to undo. See Git for every project.
• Ask it to verify, and read the verification. “Check the live headers” caught an nginx setting of expires 1m, which is one minute, not one month.
• Grant permissions narrowly. Allow the specific commands it needs, not everything. Claude Code’s permission rules make that easy.
• Give it lasting context. Project notes and memory carry preferences and conventions between sessions, so you don’t repeat yourself.
• Stay in charge of anything outward-facing. Deploys, server configuration and anything others can see deserve a human look. The agent’s dry runs and backups help, but the decision is yours.
• Keep learning. The better you know the field, the better your requests, and the better the results.

The bottom line