The Blogs: Programming in the AI Epoch: A Manifesto | Yosef B. Moran

We are no longer living in the age in which programming is defined primarily by writing code.
That age is ending.

For decades, the centre of the craft was manual implementation. The programmer was the one who knew the syntax, mastered the framework, structured the logic, and built the system line by line. Code was scarce because producing it was slow, expensive, and highly dependent on trained human labour.

That is no longer the world we inhabit.

In the AI epoch, code is abundant. It can be proposed, drafted, expanded, and refactored at a speed no individual programmer can match. The old bottleneck has weakened. The problem is no longer chiefly how to produce code. The problem is how to govern what is produced.

That is the shift.

Code is cheap. Judgement is expensive.

This does not mean that earlier forms of software engineering were simple. They were not. Distributed systems, infrastructure, fault tolerance, and large-scale architecture had already pushed programmers beyond mere coding. But AI changes the scale, the accessibility, and the centrality of that condition. What was once the burden of a narrower technical elite is becoming the general condition of programming itself.

Much of the conversation about AI and programming stops at speed. Tools like GitHub Copilot or GPT-4 can draft a function in seconds; what took an afternoon now takes minutes. That productivity gain is real and it matters. But it is not the transformation that concerns this argument. The transformation that concerns this argument is structural: software is increasingly becoming AI-driven.

An AI-driven system is not a normal application with an AI feature attached to it. It is a system in which model-based inference enters the operational core. The model does not merely decorate the product. It interprets, classifies, ranks, generates, recommends, decides, or acts within the system’s central flow. Intelligence is no longer only outside the machine, in the head of the programmer or the user. It is now embedded inside the system’s live behaviour.

That changes the craft at its root.

In classical software, behaviour was primarily defined through explicit rules. Input entered. Logic processed. Output followed. In AI-driven systems, behaviour emerges from a more volatile structure: model inference, context, constraints, tool access, memory, evaluation layers, fallback logic, and guardrails. The programmer no longer builds only deterministic logic. The programmer builds the conditions under which probabilistic intelligence may operate without corrupting the system.

That is why the role of the programmer is being redefined.

The programmer is no longer merely a producer of implementation. The programmer becomes an architect of conditions, a governor of boundaries, a designer of trust, a supervisor of machine behaviour. The essential task is no longer just to make the system do something. It is to decide what the system must never be allowed to do, how its outputs are to be judged, where its uncertainty must be contained — and to build those decisions into the system’s structure before the first user encounters it.

The machine proposes. The human governs.

The question of who governs is not philosophical. It is operational. The model does not bear consequence. The system does not answer morally for failure. The burden remains with the human builder, the institution, the team, the operator. AI can generate action, but it cannot carry accountability. That asymmetry is not going away.

And here lies the new danger.

The risk is not scarcity of output. Models already generate more code than most teams can review. The danger is in that surplus: too much plausible code, too many plausible decisions, too many plausible explanations. Plausibility is a different property from correctness, and the gap between them is where the failures accumulate. Human beings mistake fluency for reliability. They mistake acceleration for mastery. That mistake is already being made.

The systems that carry this risk do not announce themselves. Consider the pattern already visible in production deployments: a retrieval-augmented pipeline that passes internal review, earns user trust over months, and then surfaces a confidently stated falsehood that no one in the team can immediately trace to its source. Or a classification model embedded in a hiring system whose drift goes undetected until the demographic skew is statistically undeniable. These systems looked capable. They sounded coherent. They failed in ways their builders had not instrumented for, because the instrumentation assumed a different kind of system.

That is what becomes obsolete now: not the programmer, but the illusion that programming is mainly fabrication.

The programmer who only writes code is already becoming a weaker figure. Not because coding no longer matters, but because coding alone no longer defines the highest-value part of the work. The scarce skill is now judgement under conditions of generated abundance. The scarce skill is deciding what to trust, what to reject, what to verify, what to constrain, and what to keep out of the system entirely.

This raises the standard of the craft rather than lowering it. It demands architecture over improvisation, evaluation over excitement, control over seduction, and responsibility over spectacle. It requires programmers to think less like isolated coders and more like systems engineers, orchestrators, auditors, and custodians of operational intelligence.

The more common failure is institutional. An organisation adopts a large language model as a layer on top of an existing product. It ships faster. The demos are compelling. The engineering team grows to depend on generated output without building the evaluation infrastructure to audit it. The system becomes progressively harder to inspect, harder to correct, harder to explain to the people who depend on it. That path is already well-travelled. The institutions that resist it early are building something more durable, though it is slower to show.

That is the stake.

The AI epoch is not the end of programming. It is the end of programming as mere code production. What begins now is a harsher and more demanding discipline: the design of systems in which model-based inference enters the operational core — where the guardrails, the evaluation layers, the fallback logic, and the trust boundaries are not afterthoughts but primary architecture. Governing that intelligence without surrendering the system to it is not a posture. It is a technical problem. One that does not yet have a settled methodology.

The age of the programmer as solitary code producer is fading.

The age of the programmer as governor of machine intelligence has begun.

And those who fail to understand this will not simply build slower systems.

They will build systems they no longer truly control.

C

Dr. Yosef B. Moran is a writer and philosopher based in Antwerp, Belgium. He explores transcendence, human dignity, and the balance between inner growth, action, and the hidden structures of power. He is the author of Weekly Parashah, a series bringing Torah to life through existential and ethical reflection.