don't let your coding agent slope towards slop
the challenge isn't getting coding agents to write code. it's knowing which code to keep. after a week of using claude code, here are my takeaways.
for each session, i broke my work into small, discrete tasks and used the agent to brainstorm solutions. i reviewed every code change line by line before it earned a place in the codebase. this deliberate back-and-forth with the coding agent accommodated my human limitations in holding context. i found myself committing changes with more confidence than if i had written the code myself.
over that week, i developed a simple litmus test for evaluating every proposed change. for me, deciding whether a change is signal rather than slop comes down to three dimensions: correctness, readability, and succinctness.
to be correct, a code change must satisfy:
technically sound
behaviorally aligned with the spec
technical correctness is largely a function of model quality. a strong model will generally produce syntactically valid, idiomatic code. behavioral correctness, on the other hand, falls squarely on the engineer. without full product context, the agent can produce code that compiles and runs without issue yet violates the intended behavior of the system. i make sure the agent writes focused unit tests for each function to cover key scenarios, acting as a safety net to catch any behavioral or technical regressions.
spec-driven development feels overkill for me; hence i've been experimenting with using doc comments for each function to describe what it is expected to do from a business behavioral perspective. these comments give the agent enough context to ensure new changes stay aligned with the function's intended behavior.
to be readable, a code change must satisfy:
change introduced must be understandable at my level of expertise
strictly follow the naming conventions and style established in the repo
if i can't read and follow a change on the first pass, it does not enter the codebase. that doesn't mean the solution is wrong. if the approach is sound but unfamiliar, the burden is on me to understand it before committing it. no code should live in a codebase that its maintainers cannot confidently reason about.
to be succinct, a code change must satisfy:
surface area of a change should be as small as possible
change should reuse existing libraries and functionality whenever possible
change must not introduce new dependencies unless absolutely necessary
the same principle applies to tests: they should prioritize coverage that validates correctness rather than padding the suite with redundant scenarios. every line the agent adds should justify its existence.
the goal of each coding session is to iterate with the agent, reshaping its suggestions until they meet the bar for correctness, readability, and succinctness.
stay away from slop. a large part of a software engineer's responsibility lies in owning and maintaining complex systems. careless code changes introduced through vibe coding will compound as technical debt.