Agentic coding

After playing with the latest wave of AI coding agents (Claude Code + Claude Opus 4.5, Copilot, Codex, opencode, AmpCode), I became completely convinced that the code production asymmetry has reached a new milestone — code that can be generated is in such amounts and of such high quality, and is generated in such a short amount of time that the previously existing workflows are failing to make sense anymore, and this requires all of us to reprioritize our efforts and update our workflows.

So, what changed? Claude Opus 4.5 became available on Nov 24, 2025. Comparing it to the previous “waves” of AI tools:

• agents vs Tab-based completions — agents automatically making changes means that it's hands-off for a dev, most of the time, so it requires far less dedicated focus from a dev
• agents are just built differently — they can edit multiple files vs previously a single file, agents can use tools and be in a feedback loop of making changes and then testing those changes (by themselves) which automates the process tremendously, they plan things and then execute in chunks rather than doing it all at once, they can also specialize with subagents
  • coding can be in a feedback loop — compared to using AI for writing plain text and docs, it's much easier to construct robust feedback loops for agentic coding, which makes “AI for coding” far more meaningful and reliable than just “AI for docs”
• progressive disclosure — agents progressively and on-demand load things into context (whether it be files and folders, or skills and subagents) and this makes them seem really smart
• models and harnesses are better — the code quality is simply higher, and with the entire feedback loop process, things are extremely reliable. Things... Just Work™.

Code production asymmetry reaching this new milestone means that...

• ...it's becoming feasible to consider throwing away entire codebases and (re)writing them from scratch. The code itself is now truly and completely commoditized. If you haven't succeeded on the first try, just reset to some earlier point in time, or to the very beginning, and try again, but now armed with the things that you have learned since, rather than upgrading the existing code (the existing code would trash and fill up the context either way).
• ...human code reviews are becoming (extremely) questionable. If an expert were to spend the same amount of time they would spend reviewing the code, into rewriting the PR, it would almost certainly guarantee better quality. It had become more valuable (for an expert at least) to just iterate, rather than review. (see The Expertise Gap™)

Not all things can benefit equally, and not all teams can benefit equally, and not all engineers can benefit equally:

• less popular libraries and frameworks (new, or with unstable and frequently-changing APIs) are at a disadvantage
• libraries and frameworks for which it's easy to write non-idiomatic code are at a disadvantage
  • examples: React vs SolidJS vs Web Components, Tailwind vs CSS
• programming languages that are not sound are at a disadvantage
  • JS and Python vs TS and type-heavy Python and Go vs Rust
• fragile things such as tooling configs and custom DSLs with implied assumptions (e.g. Terraform HCL and YAML configs) are at a disadvantage
• fragmented implementation and business logic are at a disadvantage — if an AI cannot progressively discover and alter things it depends on, it's doomed to produce a subpar output
  • all sorts of security concerns and implications, in a single service or fragmented across multiple services
• legacy code is a liability — the code that suffers from some or all of the points above is not just a static burden, it's something that impedes further multiples of the velocity improvements since all of the improvements are compounding (as well as the disadvantages)
• UX is still impossibly tricky for AI to figure out — AI is really bad at figuring out microinteractions that are consistent, let alone delightful (even with Playwright MCP, Chrome Extension e.g.)
• The Expertise Gap™
  • It's easier for an expert to know what to prioritize and tell what even needs prioritizing, to judge the level of quality of something, than for a junior — and as this compounds over time and code size, the gap between an expert's output and a junior's will grow ever larger
  • more junior engineers are more likely to write code that may work functionally at first, but will degrade very quickly and is not isolated enough for its degradation to eventually start impacting other components as well
  • experts know better how to think about architecture
  • experts know better the tooling available, and how to reason on how they can make sure to prevent all sorts of issues for themselves or an AI agent
  • the effects of using AI are compounding and amplifying — having good judgment stemming from a lot of expertise and having built robust feedback loops with dev tools will make a massive difference

What this means for engineering teams

• doing large-scale migrations of the existing legacy code might not be the best approach at all, and instead, full rewrites from scratch might be a more viable option (ensuring feature parity via testing and canary deployments e.g.)
• using more sound programming languages with stricter type systems and error handling could be beneficial, and if you are already rewriting your codebases from scratch, you have new opportunities to consider your choices
• monorepo setups should be heavily favored over polyrepo setups (monorepos > polyrepo with git submodules > polyrepos with published libraries > polyrepo with deps via e.g. HTTP as interfaces only) as they'll play better with progressive disclosure capabilities of AI
• code review loops will need rethniking (although, it's not clear what exactly the best option is)
• in general, what are the actual moats for any company in this new age? probably things that cannot be [easily] output by AI (yet), such as — delightful experiences (UI, UX, [human] customer support), innovative ideas and deep insights, network effects and strong relationships with other companies and individuals, performance of the systems, reliability and being able to deal with very fragile APIs,... but a pretty large chunk of technical moats is erased or needs rethniking