Operation SEAL
Do We Still Need Programming Languages in the Age of AI
Imagine asking an AI coding agent to build a program without ever requesting Python, Java, or C++. You describe what the program should accomplish, where it will run, which failures are unacceptable, and what results would persuade you that it works. The agent generates an executable, runs it in a controlled environment, examines the output, and keeps revising until the agreed tests pass. Only then does it produce a detailed description of the implemented logic for an engineer to review.
If that process works, why should the engineer care whether the agent wrote Python along the way? Why not let the AI produce machine code directly and judge the program by its behavior?
This question sounds more radical than it is. Software teams already trust layers that most engineers do not inspect: compilers, operating systems, database engines, numerical libraries, cloud services, and processor firmware. Reading application source has never provided complete visibility into the system that actually runs. The arrival of capable coding agents simply makes the old division of labor clearer.
My argument is that high-level programming languages may no longer be the main interface between engineers and computers. They will probably remain inside the machinery because they provide precision, portability, and access to mature libraries. But the engineer’s primary work could move elsewhere: defining purpose, specifying operating conditions, designing credible tests, examining evidence, and deciding whether a generated executable is fit for release. I call this development model Operation SEAL: the Specification, Execution, and Assurance Loop. It is an outcome-centered form of program synthesis in which execution supplies evidence and assurance controls release.
What High-Level Languages Actually Do
A processor does not understand Python. It executes machine instructions. Python is useful because it lets a person express an operation without managing registers, memory addresses, calling conventions, and thousands of hardware-specific details. It also gives that expression stable meaning. A loop, a function call, or a data structure behaves according to shared rules that programmers, tools, and runtimes can rely on.
That combination of abstraction and precision matters. Suppose a developer writes a few lines that sort customer records, remove duplicates, and notify an analyst when a risk score crosses a threshold. Those lines may trigger sorting routines, database queries, authentication checks, network calls, error handlers, and optimized native instructions. The high-level language preserves the task's recognizable structure while an enormous software stack handles execution.
An AI agent can take over writing those lines. It can also call the same libraries and compilers. Once that happens, Python may no longer be necessary as a language that a human must learn and type. Yet Python's functions do not vanish. The system still needs exact data definitions, deterministic operations, versioned interfaces, reproducible builds, and a way to diagnose failure. If Python is removed, something else must carry that precision.
Natural language alone cannot do it. “Remove duplicate customers” leaves open what counts as a duplicate, which record to retain, how to handle missing identifiers, and whether the process may modify the original data. Conversation is excellent for discovering these questions. It is a poor final executable contract unless the unresolved terms are made precise.
This creates a practical paradox. Informal pseudocode is easy to review but cannot be compiled without further interpretation. Pseudocode that defines every term and behavior precisely enough to compile has become a programming language, even if it looks like English. We may eliminate conventional source code from the engineer’s view, but we cannot eliminate formal meaning from the system.
The human interface can move from source code to purpose, evidence, and release decisions while formal implementation layers remain underneath.
Operation SEAL
Traditional development usually places the program at the center. Requirements are translated into source code, the code is compiled, and tests check the result. Operation SEAL places the acceptance problem at the center. The engineer describes the intended result and the boundary within which that result must be achieved. The AI searches for an implementation and treats each execution as an experiment.
The three named stages describe where responsibility lies. Specification records the purpose, operating environment, constraints, and acceptance criteria. Execution covers AI synthesis and controlled runs of candidate implementations. Assurance evaluates the results, checks the implemented logic, and determines whether the evidence supports release. The final word, Loop, matters because a failed evaluation sends the candidate back for diagnosis and refinement rather than ending the process.
Consider a program that predicts whether an industrial bearing will require intervention within seven days. The first request might be conversational: “Use vibration and temperature data to identify bearings at risk. Missing a critical failure is much worse than sending an unnecessary alert. If the evidence is weak, refer the case to a person.”
The agent should not immediately generate a final program. It should ask what “critical” means, which sensors are available, how much data may be missing, how quickly the answer is needed, and what happens when a device falls outside the conditions represented in the test data. Through that conversation, the engineer and the agent construct an acceptance contract.
For sensor models A and B, recall at least 98 percent of critical failures while keeping false alerts below 5 percent. Return a result within 30 seconds. Never classify a bearing as healthy when required sensors are unavailable. When confidence is below 90 percent, refer the case for human inspection. Do not alter the original records.
The AI can now try different implementations. One candidate may use engineered vibration features and a statistical classifier. Another may use a temporal neural network. A third may combine a learned model with explicit fallback rules. Each candidate is run against held-out histories, simulated sensor failures, rare operating regimes, and resource constraints. A candidate that reaches high recall by flagging almost every bearing fails the false-alert requirement. A candidate that performs well only when all sensors are present fails the missing-data tests.
This is still programming, but the unit of human authorship has changed. The engineer authors the problem, constraints, and evidence required for acceptance. The AI authors and revises the implementation.
Operation SEAL uses execution as a feedback loop. The release decision remains a separate engineering judgment.
A Program That Passes Can Still Be Wrong
The most serious objection to this model is not that AI may write bad machine code. Human programmers also write bad code. The deeper problem is that a generated program can satisfy the stated test while violating the real purpose.
Get Rong Pan’s stories in your inbox
Join Medium for free to get updates from this writer.
The bearing predictor might exploit a variable that accidentally reveals which machines later failed. It might perform well on common operating conditions and miss a rare but dangerous regime. If the agent repeatedly sees the same evaluation set, it may gradually optimize for that set rather than for future equipment. If “success” is defined by one aggregate accuracy number, the program may sacrifice the exact cases the organization cares about most.
These are failures of the test oracle: the mechanism that decides whether the program is correct. They already occur in conventional software and machine learning. Outcome-centered synthesis makes the oracle even more important because the AI is explicitly optimizing against it.
The generator therefore should not be its own only judge. Evaluation can still use AI, but it should include evidence the generator does not control: held-out cases, deterministic invariants, adversarial tests, simulations, independent review, and post-deployment monitoring. For a financial program, the books must balance exactly. For a safety controller, check prohibited states as invariants. AI can help discover surprising failure modes, but mechanisms that do not depend on the model’s opinion should enforce known rules.
Passing a test also says little about conditions that were never tested. An approval must state the operating boundary: supported devices, expected inputs, workload limits, data quality assumptions, and permitted actions. When the program encounters something outside that boundary, the correct response may be to stop or ask for human judgment rather than improvise.
Can the AI Explain What It Built
After a candidate passes, the AI can generate precise pseudocode for engineering review. This is useful, but you cannot trust the explanation merely because it is detailed and coherent. The AI may misunderstand a low-level behavior, omit an interaction with a dependency, or produce a plausible account that does not match the evaluated binary.
Asking the AI to avoid hallucination is good practice, but it is not verification. The problem is correspondence: how do we know that the reviewed description represents the executable that actually ran?
This concern does not invalidate the model. Source code has never been a perfect guarantee of intent or runtime behavior. A readable Python program can implement the wrong requirement too. A compiler can introduce a defect. A library can behave differently than the programmer expects. The appropriate response is to construct traceability across the layers rather than treat any one layer as infallible.
Each requirement should connect to tests or invariants. Each major step in the pseudocode should connect to an executable component. The evaluation record should identify the exact binary, configuration, data, and environment that produced the observed result. Reproducible builds, execution traces, binary analysis, translation validation, and cryptographic identifiers can strengthen the link. The goal is not certainty in every application. It is enough justified confidence for the consequence of failure.
The Engineer Becomes the Assurance Layer
In this model, describing the engineer as a quality controller is close but incomplete. Quality control often suggests inspecting a finished product. The engineer’s work begins much earlier and continues after release. Quality assurance is the better term because it includes designing the entire process by which confidence is established. This is why assurance, rather than testing alone, occupies the central A in SEAL.
Before synthesis, the engineer defines the purpose, users, authority, inputs, environment, and unacceptable outcomes. During synthesis, the engineer examines whether the evaluation can be gamed, adds difficult cases, and resolves ambiguities exposed by failed runs. At release, the engineer reviews the logic and the evidence, accepts the remaining risk, and limits operation to the conditions covered by that evidence. After software release, the engineer monitors drift, incidents, and violations of the operating boundary.
The engineer is no longer responsible for manually constructing every instruction. The engineer decides what the system is allowed to do and what evidence is strong enough to justify deployment. That responsibility must come with authority. An engineer cannot reasonably sign off on an opaque executable without access to test provenance, known limitations, monitoring rules, and the ability to reject or restrict the release.
The required assurance should scale with consequence. A script that renames personal files may need only a preview, a backup, and confirmation. A program that controls a medical device, transfers money, or operates industrial equipment needs independent evaluation, hazard analysis, stronger traceability, redundant safeguards, and possibly formal verification. The workflow can stay the same, but the burden of evidence changes substantially.
Some engineers will still program in the familiar sense. Platform engineers must build the synthesis, sandboxing, verification, and monitoring infrastructure. Low-level specialists will remain important when security, hardware behavior, latency, or energy consumption requires close control. But many application engineers may spend far less time writing syntax and far more time defining behavior and evaluating evidence.
Programming Languages May Move Out of Sight
Will Python and other high-level languages disappear? Probably not. They are valuable interfaces to immense ecosystems, and they give AI agents convenient building blocks. An agent can generate Python as an executable reference model, replace slow components with optimized native code, and use a trusted compiler for the final translation. The human may never need to inspect the intermediate source unless a problem demands it.
Direct machine-code generation may also be less attractive than it first appears. Machine code is tied to a processor and difficult to analyze or transport. A typed intermediate representation, WebAssembly module, or constrained domain-specific language may offer a better internal target. It can be verified, sandboxed, optimized, and compiled for different hardware. The processor still receives machine instructions, but the development system retains a more manageable representation.
The important change, then, is not the disappearance of formal languages. It is the disappearance of mandatory human authorship in those languages. Natural conversation becomes the entry point. Formal representations become generated artifacts. Execution supplies evidence. Engineering judgment controls release.
This shift would change what it means to learn software engineering. Syntax and framework knowledge would matter less for many roles. Greater value would attach to specifying operational boundaries, choosing meaningful metrics, designing tests that resist gaming, anticipating failure modes, and constructing defensible assurance cases. Those skills are already essential. AI coding agents make them inescapable.
What Remains Necessary
We may reach a point where an engineer can create sophisticated software without writing a conventional program. That does not mean the engineer can simply describe a wish, watch one successful run, and approve the result. The less visible the implementation becomes, the more disciplined the assurance process must be.
A credible Operation SEAL system must preserve four connections: between human purpose and measurable requirements, between requirements and evaluation, between the reviewed logic and the executable, and between laboratory evidence and the conditions encountered after release. Weakness in any one of them can produce a program that appears successful while doing the wrong thing.
High-level programming languages solved as much a human problem as a machine problem. They gave us a way to express intent precisely enough to execute, inspect, share, and revise. AI may let us express the initial intent in ordinary language instead. But precision, reproducibility, traceability, and accountability still have to live somewhere.
The future of programming may therefore look less like writing code and more like designing an experiment whose result is an executable system. Operation SEAL gives that experiment a disciplined cycle: specify, execute, assure, and loop until the evidence supports a decision. The AI proposes implementations. The engineer defines the conditions of success, challenges the evidence, and decides when the result deserves to be trusted. Programming languages may move behind the interface. Engineering responsibility will not.
