The Frontier Engineer Experiment
On 2 October 2026, Anthropic announced that it would invest $100 million in the Claude Frontier Academy, with the aim of training 10,000 Frontier Deployed Engineers by the end of 2027. The scale of the investment is striking, but the more interesting part of the announcement is Anthropic's diagnosis of the problem it is trying to solve.
Access to increasingly capable models is no longer enough. Anthropic argues that a relatively small number of people inside an organisation can create disproportionate value if they understand both what the business needs and how to turn frontier AI into working systems. Its description of the Frontier Deployed Engineer is therefore considerably more ambitious than somebody who knows how to prompt a model or build a demonstration. The engineer is expected to identify an important problem, determine how AI might address it, connect the model to the necessary data and tools, navigate security and governance, deploy the resulting system and establish whether it has actually improved anything.
That raises a question which interests me rather more than the credential itself:
What exactly is Anthropic spending $100 million to teach these engineers, and how much of that capability can an experienced domain engineer acquire independently?
This project is an attempt to find out.
From using AI to engineering with it
There is already an enormous amount of material devoted to becoming proficient with generative AI, although much of it concentrates on prompting, model selection, code generation and relatively simple applications. Those skills are useful, but they are not sufficient for the problem Anthropic describes because the difficult part begins when a capable model has to become part of a dependable system.
An enterprise system has data that the model needs but should not necessarily be free to explore. It has tools that may be useful but whose use must be constrained, and it has users who need to understand why a conclusion was reached rather than merely being presented with a plausible answer. There are permissions, identities, logs and security boundaries, while incomplete or contradictory evidence has to be handled without allowing probabilistic reasoning to quietly manufacture certainty. Even when all of that works technically, somebody still has to demonstrate that the system is better than the process it replaces or assists.
The experiment, then, is not whether I can learn to use Claude more effectively, but whether I can learn to engineer with it.
That distinction provides the boundary for the project. Completing courses will not be sufficient, nor will producing an impressive demonstration in which an agent performs a complicated task once. The objective is to move from familiarity with frontier models towards the ability to design, build, constrain, evaluate and defend a system that uses one.
Starting from the other end
There is another aspect of the experiment that makes it interesting to me.
Enterprise AI is often discussed from the perspective of the AI engineer who needs to learn enough about a business or specialist domain to build useful systems within it. I am approaching the problem from the opposite direction because my starting point is industrial and operational technology cybersecurity, supported by a much longer background in networks, telecommunications, computing and security.
OT cybersecurity is a useful proving ground precisely because it resists simplistic solutions. Apparently straightforward technical questions can sit inside a mixture of legacy technology, operational constraints, security requirements, safety considerations, governance and human judgement. An answer can be technically plausible while still being operationally wrong, and evidence matters because decisions frequently need to be explained and defended.
This creates a second question alongside the first:
When frontier AI is deployed into a specialist environment, which is easier to acquire: the AI engineering capability or the domain expertise?
I am beginning with the latter and will spend the next twelve weeks trying to acquire enough of the former to connect the two. This is obviously an N=1 experiment rather than evidence from which broad conclusions can be drawn, but an experiment does not have to establish a universal rule to reveal something useful.
Establishing the baseline
The starting position needs to be recorded before the learning programme begins because otherwise hindsight will make it very easy to redefine what I already knew.
I am not starting as a novice engineer. My career has involved telecommunications, networking, computing and security, and in recent years my work has concentrated on cybersecurity in industrial and operational technology environments. I can program, understand software architecture and APIs, and am familiar with identity, infrastructure, security boundaries and the less tidy reality of integrating technology into established organisations. My academic and professional work has also covered areas including cryptography, distributed systems, machine identity, IIoT and industrial cybersecurity.
Nor am I new to large language models. I use them extensively and have experimented with local models, inference environments and coding agents, while exploring how models behave when they are given tools and more complex technical tasks. That provides a useful starting familiarity, but familiarity is not the capability this project is intended to test.
At T₀, I would not claim established practical mastery of production retrieval systems, MCP-based tool architectures, agent orchestration, systematic LLM evaluation or LLMOps. Neither would I claim experience of operating a substantial agentic system against enterprise data and tools, where permissions, observability and failure behaviour become as important as the quality of the model's answers.
Those gaps are important because they are the experimental space. If I already possessed the capabilities Anthropic associates with a Frontier Deployed Engineer, there would be very little point in conducting the exercise.
What would count as success?
Success needs to be defined before the system exists, otherwise the criteria can conveniently move towards whatever eventually gets built.
Course completion is therefore an input rather than an outcome, and certificates are evidence of having studied something rather than evidence that the resulting capability can be applied. Likewise, a polished prototype may be encouraging without demonstrating that it is trustworthy, measurable or suitable for use beyond a demonstration.
By the end of the project I want to be able to take a meaningful problem from my own domain and construct a defensible AI system around it. Doing that will require controlled interfaces to information and tools rather than simply placing large quantities of copied data into prompts, while retrieved evidence will need enough provenance for a reviewer to determine where a conclusion came from. The system should distinguish what the evidence says from what the model infers from it, and it should expose missing, contradictory or ambiguous information instead of concealing uncertainty behind fluent prose.
The same standard applies to action. Permissions should reflect what the system genuinely needs, while decisions or actions with material consequences should remain behind explicit human boundaries. Behaviour must also be testable and failures observable, because an agent whose successes are impressive but whose failures cannot be characterised is difficult to defend as an engineering system.
Ultimately, however, the test is not architectural elegance. There must be evidence that the system improves the process it was designed to support, whether through reduced review time, improved evidence coverage, more consistent identification of gaps or some other measurable result. If the AI makes an existing process slower, harder to trust or more difficult to govern, technical novelty will not rescue it.
Choosing a proving ground
The initial proving ground will be an AI-assisted OT cybersecurity assurance system, provisionally described as an OT Assurance Analyst.
Assurance work provides an interesting test because it frequently requires information from several sources to be assembled and interpreted against defined requirements before a defensible assessment can be made. A language model can obviously summarise documents, but summarisation is not the problem I want to investigate. The harder question is whether an agentic system can participate usefully in the reasoning process while preserving enough of the evidential trail for a human reviewer to inspect, challenge and, where necessary, reject its conclusions.
The desired chain is therefore something resembling:
Requirement → evidence examined → observations → missing or conflicting evidence → reasoning → proposed finding → confidence → human decision
The final element is deliberate. The system is not intended to become the authority, and it will not autonomously approve risks, declare compliance or alter operational infrastructure. Instead, the experiment will examine whether AI can perform enough of the cognitive assembly surrounding those decisions to make the human reviewer more effective without obscuring how the assessment was produced.
That immediately creates a richer engineering problem than document summarisation because the system needs controlled retrieval and tool access while maintaining provenance between requirements, evidence and conclusions. It must handle uncertainty and contradiction, and its output has to be evaluated against known cases. Its own permissions and attack surface also become part of the security problem, while the boundary between machine recommendation and human authority has to be explicit rather than assumed.
Public development and documentation will use synthetic, generic or appropriately redacted material, so the engineering problem can be explored without exposing operational information.
Learning while building
The learning programme has been organised around the capabilities that this system will require rather than around course providers.
It begins with agentic AI because the first conceptual transition is from conversational model use towards systems that can decompose work, use tools, inspect intermediate results and execute controlled multi-step processes. Model Context Protocol follows because the system needs a deliberate interface between Claude and external capabilities rather than unrestricted access to whatever happens to be available.
Retrieval and tool use then become central as the Assurance Analyst begins to work from evidence, while agent orchestration addresses the question of how increasingly complicated workflows should be structured without turning every component into an agent merely because agents are fashionable. LLMOps introduces evaluation, testing, observability and operational behaviour, and the final strand concentrates on requirements and acceptance so that the system can be judged against criteria defined independently of its most impressive demonstrations.
The courses supporting those areas are therefore inputs to the project rather than the project itself. Study and engineering will proceed together, so a technique learned during the programme should, where appropriate, be applied to the developing system and tested against the problem that motivated learning it.
Some ideas will presumably work, while others will prove unnecessary or fail when exposed to the constraints of the use case. Both outcomes matter, which is why the project journal will record changes of direction and discarded approaches rather than retrospectively presenting the final architecture as though it had been obvious from the beginning.
Claude as both instrument and subject
There is a useful recursion in conducting the experiment with Claude.
Anthropic's announcement provides the catalyst, its description of the Frontier Deployed Engineer provides a benchmark, and Claude is one of the principal technologies being investigated, while Claude Code can also participate in constructing the software around it.
That does not mean the objective is to discover ways of putting Claude into every part of the system. In fact, one measure of progress should be knowing when not to use it. Deterministic software remains preferable where a deterministic answer is required, and conventional controls should constrain probabilistic components where their freedom provides no corresponding benefit.
If twelve weeks of studying agents leaves me inclined to turn every function into an agent, the experiment will have taught the wrong lesson.
Twelve weeks
The project will run for approximately twelve weeks, which should be long enough to move beyond tutorials while remaining short enough to force architectural decisions and expose the difference between learning about a technique and making it work.
The broad progression is:
Foundations → Tools → Retrieval → Orchestration → Evaluation → Deployment
That sequence describes capability rather than a fixed architecture, because deciding the final architecture before acquiring the knowledge needed to evaluate it would defeat part of the purpose of the experiment. Components may disappear, merge or become less important as the work develops.
The destination, however, is less negotiable. By the end of the twelve weeks there should be an implemented system whose architecture I can explain and defend, including how it accesses information and tools, how evidence remains connected to its conclusions, and where human authority begins and ends. There should also be an evaluation set capable of exposing at least some of its weaknesses, a documented understanding of its important security and trust boundaries, and measurements that allow its performance to be compared with the process it was intended to assist.
Only then does comparison with Anthropic's proposition become meaningful.
The hypothesis
Behind the experiment is a broader hypothesis.
Frontier models are making some forms of software construction dramatically more accessible, but deploying those models into specialist environments still depends upon knowledge that the model itself cannot conveniently supply. The difficult part is often knowing which problem matters, what evidence means in context, which mistakes are tolerable, where authority should stop and what a successful result actually looks like.
If that is true, deep domain expertise may become more valuable as frontier AI improves rather than less valuable, because the scarce engineer may not be the person who knows the greatest number of agent frameworks. It may instead be someone who understands a difficult domain well enough to recognise the right problem, possesses enough engineering judgement to constrain the model appropriately, and can acquire sufficient frontier-AI capability to connect the two.
Anthropic appears to be making a $100 million bet on something close to that proposition. This project makes a much smaller one.
Can an experienced industrial cybersecurity engineer acquire the practical capability to take frontier AI from an interesting model to a defensible enterprise system?
At T₀, the answer is unknown, which is precisely where an experiment ought to begin.