unknown

AI slop — code that works today but quietly degrades a codebase over time — is framed as a taste problem, not an AI problem. Developer taste is defined as the judgment to know what the right solution looks like before writing a single line of code. The post contrasts engineers who use AI to guess at solutions versus those who use it to iterate toward solutions they already understand. Practical techniques for developing taste include outside-in testing, small single-purpose commits, reading your own PRs as a reviewer, going to primary sources, defining data structures yourself before letting AI fill in bodies, and reviewing more code than you write. The career implication is that engineers who treat AI as a typing shortcut are becoming fungible, while those with strong judgment are becoming high-leverage orchestrators.

The engineer AI can't replace

All about Engineering Management, Leadership and Career Growth.

Engineering Leadership

“Review more code than you write.”
I suppose this is one way to go about it. Although code review is not only more time consuming, but it has proven to not be able to impart the same deep understanding that the friction from writing code creates. In fact, all real lasting and true understanding comes from experiencing friction and problem solving in the first place.
I agree that taste and orchestration are important, but something facing all of us is skill atrophy, which is a very real phenomenon happening to many individuals.
This is the constant contradiction that have people talking out of both sides of their mouth on: you can’t be the talented orchestrator who skillfully verifies and debugs the generated code…if you don’t practice coding any longer.
As an Anthropic <a href="https://www.anthropic.com/research/how-ai-is-transforming-work-at-anthropic#and-less-hands-on-practice" target="_blank" rel="noopener nofollow">study</a> quietly admits to:
“One reason that the atrophy of coding skills is concerning is the “paradox of supervision” … effectively using Claude requires supervision, and supervising Claude requires the very coding skills that may atrophy from AI overuse.”
The workflow I’ve personally found a balance with: I am using LLMs to help generate specs and plans, and I facilate the implementation.
This involves a blend of manual coding (anywhere from 0% on some tasks, upwards to 100% on others), along with ad-hoc LLM code generation and assistance, especially in the forms of an integrated research tool that I can constantly ask questions, iterate, refactor, and gain clarity around my approaches.
For certain tasks and certain projects, I’m able to engage with spec-driven development. But it’s not a one-size-fits-all solution. And I think it should just be one workflow out of many that we can select from. We shouldn’t be ashamed to code manually.

You can give clear parameters to AI agents and it can, eventually produce code with the style and quality you have a taste for. And then you become some sort of project manager with the responsibilities of a software engineer. It’s hard to find a balance when AI tools are getting new capabilities and wild features every other month.

The perfect balance is necessary. Using AI tools to much you will forget the coding. Avoid using it you will have a hard time keeping up with technology. While Ai generated code try to understand what each line does. When you do not know what it does break that line into smaller problem. Now prompt any assistance I am beginner in the topic give me a couple of tasks that I can solve. You solve this by yourself, now you go back to the previous line you know what it does. This is slow iteration but builds understanding.