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 the tests or simply skipping them).
Give your agent access to your CI to create a second feedback loop. Give it access to your server logs to create a third. Giving the agent away to visually inspect a UI is yet another example.
Your job is to design environments where iteration converges toward correctness instead of drifting toward plausible nonsense.
Velocity without feedback is chaos.
Any stack is your stack
Agents are competent across most major stacks where training data exists. Since you are not writing the code, your attachment to a specific stack becomes less relevant.
Do not limit yourself to what you personally know. Your conceptual understanding transfers more than you think.
When you lack terminology or domain knowledge, ask the agent to brief you. The barrier to entry into unfamiliar ecosystems is lower than it has ever been.
Agents are not just for coding
Coding is only the beginning.
Agents can assist with business analysis, UX, infrastructure, operations, ad campaigns, analytics configuration, even accounting workflows.
I migrated four WordPress blogs from an overpriced host to Hetzner in minutes after postponing the task for years. The blocker was never a technical difficulty. It was attention. Claude completed the task in 15 minutes.
Agents reduce the activation energy required to execute tedious but valuable work.
Grant access carefully. Limit scope. Audit results. Direction without oversight is reckless.
The context bottleneck is in your head
Context engineering has improved. Tooling has improved.
Yet when running multiple agents in parallel, the real bottleneck is human coordination.
You must track what each agent is doing. You must remember which assumptions were made. You know what questions to ask next.
As agents become better at managing their own context, your ability to supervise them becomes the limiting factor.
The constraint is no longer tokens. It is cognition.
Build for a changing world
New models. New capabilities. New frameworks. New skills.
The ground shifts daily. Some models are better at reasoning. Some at coding. Some at translation.
Flexibility is not optional. It must be built into your workflow and products. Both must be engineered for experimentation and adaptability.
When considering Buy vs. Build, the answer, more often, is build
When code was expensive, buying made sense. When code approaches zero marginal cost, the calculus changes.
Every paid API is now a question. Could we replicate this internally? Should we?
For our QA agent, we needed full-page screenshots of live sites. Many APIs offered this. Instead, we deployed Playwright to AWS Lambda, tailored to our needs, and hardened.
This is not a blanket argument against SaaS. Maintenance, security, and scale still matter. But many small and medium services that once required vendors are now within reach.
Some call this the end of SaaS.
Fast rubbish is still rubbish
Speed is intoxicating. It is also dangerous.
You can generate enormous amounts of code quickly. But velocity and lines of code written were always terrible indicators of progress.
Refactoring is cheap, but it is cheaper to detect flawed direction early.
Discipline matters more, not less, when execution is frictionless.
Software is a liability, a product is an asset
Software costs money to maintain. It only becomes an asset when it produces value for someone.
This was always true. It is harder to remember now because building is so easy.
It is tricker then ever to resist the temptation to add features. Resist it. Build what is used. Kill what is not.
Moats are more expensive
Feature gaps close quickly. What once took years to replicate can now take months. What took months can now take days.
A feature set is no longer a durable moat.
Moats shift toward distribution, data, brand, network effects, regulation, and ecosystem integration.
The barrier to entry falls. The barrier to defensibility rises.
Build for agents
There is a new hierarchy.
At the base are models (Opus 4.6, GPT-5.3-codex). On top of them sit agents (Claude Code, OpenClaw). On top of agents sit services.
Today, agents use services designed for humans. It works, but it is inefficient. The next step is services designed for agents (Moltbook being the harbinger).
Make your services accessible to agents. Expose structured context. Provide machine-readable surfaces.
Agentic commerce is emerging. In some cases, a markdown endpoint is enough. In others, the service itself must be designed agent-first.
Agent-first is not a tooling choice. It is a product decision. It changes your interfaces, your reliability model, your metrics, and what you build next.
We are building an agent-first CMS. If we succeed, humans will not need to use it, though they can.
AX is the new UX
Anticipate modes of failure
Do not assume competence implies perfection.
Like an engineer overseeing the construction of a bridge, your job is not to lay bricks. It is to ensure the structure does not collapse.
Agents will make mistakes. They will drift off course. They will introduce subtle flaws. They will create security vulnerabilities. One of mine attempted to commit a .env file to git. They can be inventive in how they self-sabotage.
Be one step ahead. Ask yourself how this could break. Where could it leak. What could it expose. What assumptions is the agent quietly making.
Play the what-if game relentlessly. Then build guardrails.
Automate checks. Lock down permissions. Isolate environments. Add monitoring. Create recovery paths. Make rollback trivial.
Remember, code is cheap, and you have new superpowers. Build tools to allow you to probe deep, discover vulnerabilities, and test for anticipated failure modes. Design systems that expect failure and degrade gracefully.
This is the distinction between software development and software engineering.
What I do
I work with engineering and product teams adopting agents. The goal is simple: ship faster without lowering standards.
I usually help in two ways:
Agent-first software engineering
We turn agents into part of the system, not a novelty. We design workflows, guardrails, and supporting tools so the team can delegate confidently.
If you want to operationalize coding agents without turning your codebase into a casino, get in touch.
Agent-first product strategy
I help companies shift products from human-centric interfaces to agent-accessible, and where it makes sense, agents-first. That means clarifying what agents should be able to do, what constraints they must operate under, and what needs to change in your APIs, permissions, reliability model, and product surface area to support them.
This typically results in an agent-access roadmap, an operating model, and a prioritized set of product changes that make agents a first-class user.
I’m the co-founder of WhiteBoar, where AI agents build your brand and launch visually striking marketing websites, complete with professional multi-lingual content, in minutes, not months. Contact me at [email protected].