AI 코딩의 젠

Dedicated to all those who are sceptical about the significance of agentic coding, and to those who are not, and are wondering what it means for the future of their profession. The title is an homage to Zen of Python by Tim Peters. Unlike Tim, I am not a zen master. My only aim is to take stock of where we are and where we might be heading. I have been building with coding agents daily for the past year, and I also help teams adopt them without losing reliability or security. - Software development is dead - Code is cheap - Refactoring easy - So is repaying technical debt - All bugs are shallow - Create tight feedback loops - Any stack is your stack - Agents are not just for coding - The context bottleneck is in your head - Build for a changing world - When considering Buy vs. Build, the answer, more often, is build - Fast rubbish is still rubbish - Software is a liability, a product is an asset - Moats are more expensive - Build for agents - Anticipate modes of failure Software development is dead You do not need to write another line of code if you do not want to. Coding agents can accomplish most coding tasks with the right direction. Software development, as the act of manually producing code, is dying. A new discipline is being born. Your role in it is vital, but it is no longer centered on typing code. It is centered on framing problems, shaping context, defining constraints, and judging outcomes. The marginal cost of code is collapsing. That single fact changes everything that follows. Code is cheap The economics of software have changed. When coding is cheap, implementation stops being the constraint. You can build ten things in parallel. You cannot decide, validate, and ship ten things in parallel, at least not without changing the rest of the pipeline. Cost of delay shifts. It is no longer about developer days. It is about time stuck in other bottlenecks: product decisions, unclear requirements, security review, user testing, release processes, and operational risk. Agents can flood these queues. Inventory grows. Lead time grows. Delay becomes more expensive, not less. This changes prioritization. The highest leverage work is what unblocks shipping: tight feedback loops, tests, evals, guardrails, observability, and clear acceptance criteria. Anything that turns “we can build it” into “we can trust it”. Agents can help alleviate some of these bottlenecks. The challenge is applying them outside of coding (see Agents are not just for coding) Refactoring is easy The cost of changing your mind is lower than it has ever been. Architectural decisions that once felt permanent are now provisional. You chose React. Two months later, you regret it. Ask an agent to rewrite the project. Making imperfect decisions is no longer fatal. In fact, it can be productive. A flawed reference implementation provides better context than a pristine specification. Agents reason more effectively from concrete artifacts than from abstract intent. Rapid iteration is now the default mode. Over the last three months, we rebuilt our CMS four times from scratch, each with a different architecture. Each time we learned more about what we actually needed and what works. When code is cheap, you can run more small bets. So is repaying technical debt There is little excuse for stale dependencies or ignored security patches. Updating libraries, migrating APIs, modernizing patterns. These are prompts away. Prune your code regularly. Upgrade aggressively. Keep the surface clean. Technical debt has not disappeared. But the cost of servicing it has dropped. That changes the incentive structure. Neglect becomes less defensible. All bugs are shallow Linus’s law states that “given enough eyeballs, all bugs are shallow.” Those eyeballs are now abundant. Ask one model to review your code. Ask another. They may find different issues. Ask them to fix what they find. Often they will succeed. How “dense” are bugs given a piece of code is a philosophical question. Bugs are not magically gone. Agents do not achieve perfection. From a practical perspective, however, the limiting factor is no longer the number of reviewers. It is the tightness of your feedback loops. The claim here is profound: comprehension of the codebase at the function level is no longer necessary. At the same time, relying entirely on the models is a recipe for disaster. You still have a job! (see: create tight feedback loops, anticipate modes of failure) Create tight feedback loops Agents can sometimes one-shot a task. We’ve built agents that create a complete custom-made marketing website in one shot, but this is by far the exception. In most cases, agents operate best when iterating towards a well-defined goal, guided by feedback. Good tests are the first feedback loop. The agent will iterate until the tests pass. It is your responsibility to make sure the tests are adequate (by instructing the agent to create good ones) and to make sure the agent does not cheat (by weakening th