Test Heading
Test paragraph with bold text.Borrowing loosely from the Buddhist idea of the "Age of Dharma Decline": the form remains, but the essence is easy to forget. This is only a metaphor, not a doctrinal interpretation.
A Rejected Loan Applicant, and a Room Full of People Who Can't Explain Why
Picture a newly deployed loan-approval system. It runs to spec, tests pass, dashboards are green. A customer gets rejected. They file a complaint. When the team sits down to explain, no one can say why the system reached that decision.
The product person says the rules were signed off. The data person says the model's accuracy is solid. The engineer says most of the code was AI-assisted and covered by tests. No one made an obvious mistake at any single step. And yet no one truly understands the entire path that led to that outcome.
The anxiety IT people feel here isn't simply "AI writes code faster than I do." It's more unsettling than that: if code can be generated without being understood, what exactly are the people who understand it being paid for?
I'll call this the Latter Days of Code.
Not because code is disappearing. On the contrary, there has never been more of it. The "Latter Days of Code" is the moment when code becomes so cheap that producing it no longer proves much about competence.
Three Ages of Code
Borrowing the "three ages" structure from the idea of Dharma decline, we might view the programming profession like this.
The Age of True Code was when writing and understanding were almost the same thing. With assembly or C in early systems, you couldn't write a line that ran correctly without understanding what the machine was doing. Writing code was a deeply physical act: how much memory, what the CPU was doing, where each byte lived.
The Age of Semblance is the era of frameworks, libraries, Stack Overflow, and copy-paste. Everything became more accessible, and that was real progress. But it's also when we grew used to running code we'd never carefully read. Still repos, still commits, still pull requests — only the gap between "writing" and "understanding" kept widening.
The Latter Days of Code is when that form gets generated almost without limit. A single prompt can become a service, a website, a test suite, a bug analysis. Fast enough that we might mistake it: something that runs must have been understood.
AI didn't create this separation from nothing. It just pushed an old trend to its extreme and put it right in front of us.
What's Losing Value?
The tasks losing value fastest are exactly the ones AI does best: boilerplate, CRUD, generic interfaces, syntax lookup, or turning a clear requirement into runnable code.
That doesn't make those skills useless. An engineer still needs to know code to read, fix, and evaluate it. But they're no longer enough to create a real difference. Lines of code, typing speed, or features shipped per week were already poor metrics; now they're even poorer.
AI performs well when the goal is clear, the data is sufficient, and right-or-wrong criteria can be stated explicitly. Real life is usually the opposite: vague requirements, messy data, conflicting goals, rules that change mid-stream, and budgets that are never enough.
Back to the loan-approval system. AI can help write it. But AI doesn't decide whether the company should prioritize profit, credit access, or fairness. And when someone is wrongly rejected, AI isn't the one who sits down to explain, fix the fallout, or absorb the loss of trust.
Still, we shouldn't comfort ourselves with the line "value will simply shift to judgment." An industry can create more value per person while needing fewer people overall — that's a real possibility. The opposite is equally real: cheaper code leads to more systems, and with them more operational, security, integration, and maintenance burden. No one knows which way the balance will tip. Only one thing seems fairly clear: the old kind of work won't return intact.
The New Bottleneck: Generating Is Easy, Verifying Is Hard
This might be the most important shift.
The capacity to generate code is growing extremely fast. Humans' capacity to read, understand, and verify it isn't growing at the same rate. The profession's bottleneck is shifting from production to verification.
Anyone who has reviewed a few-hundred-line pull request produced by AI knows this feeling. Names are well-chosen, comments are thorough, the structure looks reasonable. It's smooth enough to lull a reviewer into a nod of approval. Then in production, some small assumption nobody questioned starts to break.
So perhaps the Latter Days of Code will favor those who read code over those who write it. The valuable person is the one who looks at five hundred lines that "seem fine" and can ask: which assumption here hasn't been proven? What happens when data is missing, a service is slow, or a user does something unexpected?
When scripture can be printed without limit, what's rare isn't the scripture — it's the reader who understands it. That metaphor, as it happens, fits code today rather well.
Two Questions That Can't Be Skipped
Is "accountability" a real capability, or just a place the law hasn't caught up to yet?
This is a strong counterargument. Perhaps humans still put their names on decisions simply because the law doesn't yet allow blame to be assigned to an AI system. If the law changes, this "moat" could narrow very quickly.
But accountability isn't only about who gets sued. It's also about trust. When a decision causes harm, customers, colleagues, and society need someone who can explain, listen to feedback, and change how things are done. That's a social need, not just a legal formality. Even so, this boundary will certainly keep shifting.
If AI takes away junior work, where will senior engineers come from ten years from now?
This is a very real paradox. Judgment doesn't appear on its own; it's accumulated through small tasks, silly bugs, and botched deployments. Meanwhile, those very tasks are the first to be automated.
There's no neat answer. But the path of learning the trade has to be redesigned: juniors can't just receive a prompt and submit the output. They need to learn how to verify, how to observe real systems, and how to trace a decision back to its original assumptions. This is work for seniors and organizations, not a vague piece of advice like "upgrade yourself."
So What Should We "Cultivate"?
Not cultivation to stand outside AI. Cultivation so we can use it without losing our own judgment.
Cultivate the ability to verify. Read AI's output with methodical skepticism. Write tests not to tick a checklist but to block dangerous assumptions. Watch the logs, observe production, and after every incident ask: what did we believe without checking?
Cultivate clarity and contextual understanding. With AI, a clear problem statement is often most of the solution. Practice writing problem statements, success criteria, and constraints before the first line of code exists. At the same time, go deep into a specific domain — finance, logistics, education, healthcare — deep enough to understand why a requirement exists in the first place. Only then can you say: "This request sounds reasonable, but we shouldn't build it this way."
Cultivate integrity. If you don't know, say you don't know. Don't ship something you can't explain just because it runs and the deadline is close. There will be moments to choose between "just deploy it, it looks fine" and "stop, I don't understand this part yet." Choose the second option often enough, and you become the person the team wants to hand the hard problems to.
AI should be a lever that lets us experiment faster and understand faster. It shouldn't be the place we outsource our capacity to think.
The Latter Days of Code Isn't the End of the Profession
The idea of Dharma decline, seen as a metaphor, isn't an invitation to despair. It's a reminder that when circumstances change, practice must change too.
Programming isn't disappearing. What's gradually ending is the era when we mistook typing code for creating value.
In the Latter Days of Code, perhaps don't try to become the fastest coder. Try to become the person the whole team turns to when the system breaks — because you understand what's happening, know which questions to ask, and dare to put your name on your decisions.