will__ness

Great questions. For me, high quality code is code that: 1) works (is functional, no bugs) 2) is secure (no security vulnerabilities) 3) is extendable (I can quickly and easily build new features with limited refactors)

I argue the code still matters because of these 3 reasons. If the code doesn't work, your product won't work. If its not secure, there's obvious consequences. If you can't build new features quickly, you will end up wasting money/time.

Here is my exact workflow: https://willness.dev/blog/claude-code-workflow

This is very true. My biggest frustration is people who use LLMs to generate code, and then don't use LLMs to refine that code. That is how you end up with slop.I would estimate that as a SDE I spend about 30% of my time reviewing and refining my own code, and I would encourage anyone operating a coding agent to still spend 30% figuring out how to improve the code before shipping.

> it's orders of magnitude worse

This is not my experience *at all*. Maybe models from like 18+ months ago would produce really bad code, but in general most coding agents are amazing at finding existing code and replicating the current patterns. My job as the operator then is to direct the coding agent to improve whatever it doesn't do well.

> But there are serious limits. [Your coding agent] will lie to you, they don't really understand things, and they often generate bad code.

I think that really high quality code can be created via coding agents. Not in one prompt, but instead an orchestration of planning, implementing, validating, and reviewing.

Its still engineering work. The code still matters. Its just a different tool to write the code.

I'd compare the difference between manually coding and operating a coding agent to the difference between a handsaw and a chainsaw - the end result is the same but the method is very different.

Author here. I kept hitting the same tradeoff with Claude Code: 1) move fast, ship bugs, slow down feature development due to bad code 2) manually review all code and move super slow

This post covers the workflow I landed on: 1) sub-agents for plan review and code review (each gets fresh context) 2) persistent memory across coding sessions (not just markdown files) 3) a closing session protocol that handles tests/lint/format/cleanup/commit/push/merge conflicts.

The key insight: your main agent juggles too much. Sub-agents specialize. Each starts fresh, does one job well, returns findings. Example: Code Review Sub-agent = detailed document about my exact code standards. When it spins up, it has a brand new context window and its only job is to ensure the `git diff` matches your code standards.

There's an interactive demo showing how it works.

Happy to answer questions about the setup.