BHFT has opened a role the market has no standard name for: an engineer who runs several AI agent pipelines in parallel and delivers the output of a whole team. We know the position will be hard to fill, but we believe in the idea. Our Co-Head of Platform, who mentors the first hires, explains how the role came about and how we assess candidates.
Most engineering job descriptions assume a team around the hire: a lead who sets priorities, colleagues who review pull requests, a QA team that owns regression testing. This year BHFT’s Platform team opened a vacancy that does away with most of that. The working title is LLM engineer.
The role combines the functions of a team lead and an engineer. The person sets their own priorities, works directly with other departments and delivers projects through several AI agent pipelines that write and run code in parallel. To the business, one such person should look like a whole team.
The vacancy is an experiment. We accept that the ideal candidate may not exist, so we have been refining the requirements as we go, with the long-term vision in mind. This article covers how the role came about, what the person does, where the profile’s boundaries lie, how BHFT interviews for it, who owns the code and what is expected in the first months.
Where the role came from
BHFT’s Platform is organised around teams, each with a lead and several engineers. The lead combines two functions:
-
Product ownership: deciding where the team’s effort should go, setting priorities, working with stakeholders in trading and driving projects to completion.
-
People management: keeping the team motivated, removing blockers, collecting metrics and improving tooling.
Engineers pick up the work the lead has scoped and implement it independently. They resolve their own blockers where possible and refine technical requirements as needed, but they do not own delivery end to end. The lead carries the accountability.
Each role has its typical failure patterns. For a lead, it is work nobody uses: a project that ships but never makes it into anyone’s workflow. For an engineer, it is missed deadlines, long periods blocked, poor architectural choices and bugs.
The new role grew out of watching a couple of engineers inside the company whose output rose sharply once they started working with LLMs. It is not uncommon for engineers to have four repositories cloned side by side and run four unrelated tasks through four separate pipelines. Previously, those tasks would have gone to four people.
The idea that followed was simple: take a team lead, remove people management and use the freed capacity for hands-on implementation through LLMs. The result is part lead, part engineer.
What the person does
With LLMs, speed comes from parallelism. The gain appears when the engineer stops waiting on the agent and works on something else in the meantime. A randomised trial by METR in early 2025 showed what the waiting costs: experienced open-source developers using AI tools took 19% longer to complete their tasks, with the extra time spent on prompting, waiting for the model and reviewing its output. Running several streams puts that idle time to use.
Parallel streams require decomposition: breaking a project into subtasks that can be handed to several people. A project that takes one engineer three months can take four engineers about a month. The skill lies in knowing where the bottlenecks and dependencies are and which parts can run independently.
Fred Brooks made this evergreen point over 50 years ago in The Mythical Man-Month: people and months are interchangeable only for work that can be partitioned without much communication between the performers. The LLM engineer applies the same analysis to agents. Done well, this increases throughput and shortens lead time.
Figure 2. With one stream, the person waits while the agent runs. With four, they brief and check one stream while the others run. Durations are illustrative.
Agents can also help with planning and organisation, but there is a catch. Without experience, a person slides into “vibe coding”: handing the task to the model, accepting whatever comes back and not checking where it ends up.
Andrej Karpathy, a computer scientist and co-founder of OpenAI, coined the term in 2025 for exactly this way of working. The result may be good enough for a prototype or even an MVP, but it is unreliable and hard, if not impossible, to scale.
GitClear’s analysis of 211 million changed lines of code found that as AI assistants spread, the share of copy-pasted code grew while refactoring declined. An experienced engineer can tell, at the level of architecture and abstractions, when a stream is heading in the wrong direction and course-correct it. Simon Willison, who writes extensively on AI-assisted programming, sets a simple rule for production code: never commit anything you could not explain to someone else.
Verification is where the person’s expertise matters most. An agent may work on its own for a day or two and then report that the task is done, and the LLM engineer confirms that it is. In established parts of the system, these checks are already automated. New features are often not yet covered by tests, so the person checks them by hand until the checks can be automated too.
The amount of manual review has been shrinking. Six months ago BHFT’s engineers read almost every line an agent produced. Since then the teams have tightened their QA gates and strengthened test coverage, partly with LLMs. For less critical tasks, engineers now skim the code; for short-lived prototypes, some code is not reviewed at all.
This works even for routine engineering tasks run in parallel terminals. On larger projects, other departments join the agents as asynchronous contributors, and the person manages the project as a whole, keeping track of every workstream.
How many streams can one person run? There is no fixed number. Engineers at BHFT already run 4–5 at a time, and the figure grows as the safeguards around them improve. Each check that moves into the automated pipeline and each module that switches to risk-based review frees attention for another stream. If a project turns out too large for one person, the LLM engineer sees it at the decomposition stage and splits the work across teams before it starts.
The LLM engineer sits between teams and operates as a team of one. Every two weeks, at a general meeting, each lead reports what the team delivered over the past two weeks and what it plans for the next. The LLM engineer reports in the same format and demos each finished project. If several people take on the role, their updates may be combined into a single project portfolio.
With other departments, the person acts as a lead: gathering and clarifying requirements, agreeing the definitions of Ready and Done and setting up processes where needed. Their counterparts include traders, market data, PRE, DevOps and the project and delivery managers in the PMO. On technical matters, they work with other engineers as a peer, since they change the shared codebase and build on existing solutions.
Not just a senior engineer with a subscription
A senior engineer who generates a lot of code with LLMs is a different profile. The LLM engineer needs all four of the following:
-
Domain knowledge
-
Product ownership
-
A sense of priority
-
A strong technical background
The technical bar is high. BHFT expects hands-on systems programming, including low-level work, and experience designing system architecture, ideally for trading or trading-adjacent systems. Someone who spent two or three years as an engineer and then moved into product management will not meet it. The person has to live and breathe development and keep up with what is happening in the field.
At the other extreme, a pure technician who handles well-defined tasks but will not own a product, or who tends to get lost in the details along the way, will not fit either.
The candidate also needs a genuine interest in trading. “I don’t mind what I work on, I’ll manage” is a poor sign. A candidate whose pipelines already run at full speed and who is keen to learn the domain is off to a strong start.
How BHFT interviews for the role
The process has three stages:
-
HR screening
-
Technical and product interview with a platform lead
-
Culture-fit interview with the PMO and an HR business partner
The interviews are built around cases from the candidate’s own work. Interviewers ask which projects the person contributed to, what exactly they did in a given situation and how they dealt with the obstacles they hit. Soft skills carry as much weight as hard skills, and an ownership mindset is essential.
Figure 3. The selection process for the LLM engineer role.
Who owns the code
If one person delivers a team’s volume of work, code review and production ownership need a fresh setup. The mentor is accountable for the first tickets the person ships. After that, review depends on how critical the code is. Critical parts of the system have designated codeowners: engineers who own a module and approve changes to it. They are brought in to review the key changes. For non-critical code, the person either self-reviews or requests a review from the team.
BHFT’s codebase is too large for any one person to hold in their head, and different parts were written and developed by different people. Many engineers have enough context to be called in for a review; only a handful can develop a module as a product.
The rule of thumb at BHFT is to keep two codeowners per module, so that no module has a bus factor of one. In some places a single person still owns the context, but the average engineer at BHFT is strong enough to take over any part of the system. Reviews may be slower for a while, and the engineer will need two or three days to get up to speed on the missing context. With LLMs, that has become much easier.
Responsibility shifts to the hire quickly. The LLM engineer is fully accountable for the quality of what they ship. Testing used to be a separate department, with two automation teams and manual testers. Now quality sits with the teams themselves: some have a dedicated QA engineer, while in others engineers cover regression testing with LLMs.
Figure 4. Review and accountability for the LLM engineer’s code.
A venture with limits
The real test is the work itself. The first three months are decisive, and the assessment can extend to six. BHFT gives the person the tools and authority they need and, in return, expects business value within the first weeks. That is what makes this hire a unicorn: an ordinary hire may take six months to ramp up before contributing, and the one-person team does not have that luxury.
Three months in, the person should be able to prioritise work and defend their scope, commit to deadlines and ship regularly. By then, two or three small projects and one or two medium ones should be closed, each with tangible business value. The main red flag is scope creep: the project keeps expanding and the deadlines keep slipping. If that pattern continues after the first round of feedback, the person may not pass probation.
Role checklist
In short, this is what the role requires and what BHFT expects from the person who takes it.
- Product ownership. The person picks the right priorities, commits to deadlines and ships work that enables the firm to unlock new revenue.
- Technical depth. Hands-on systems programming, including low-level work, and experience designing system architecture, ideally for trading or trading-adjacent systems. The person still writes code and keeps up with the field.
- Decomposition. The person can break a project into parallel streams, identify dependencies and blockers, and run several agent pipelines at once.
- Judgement over agent output. The person steers agents at the level of architecture, verifies what they report as done and can explain every change they merge.
- Interest in trading. The person either understands trading or clearly wants to. Domain knowledge or LLM skills can be partly developed on the job, but every finalist so far has had both.
- Evidence from real work. Claims count only when backed by specific cases that show the person’s own contribution.
- Clear expectations from day one. Over the first three months, two or three small projects and one or two medium ones, each with business value. Full responsibility for quality and incidents. A probation period of three to six months.
Sources
- Becker, J., Rush, N., Barnes, E., Rein, D. (2025). Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity. METR. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
- Brooks, F. P. (1975). The Mythical Man-Month: Essays on Software Engineering. Summary on Wikipedia. https://en.wikipedia.org/wiki/The_Mythical_Man-Month
- Willison, S. (2025). Not all AI-assisted programming is vibe coding (but vibe coding rocks). https://simonwillison.net/2025/Mar/19/vibe-coding/
- GitClear (2025). AI Copilot Code Quality: 2025 research. https://www.gitclear.com/ai_assistant_code_quality_2025_research
- Google Cloud / DORA (2025). Announcing the 2025 DORA Report: State of AI-assisted Software Development. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report
- Sackett, P. R., Zhang, C., Berry, C. M., Lievens, F. (2022). Revisiting meta-analytic estimates of validity in personnel selection. Summary in SIOP’s The Industrial-Organizational Psychologist. https://www.siop.org/tip-article/is-cognitive-ability-the-best-predictor-of-job-performance
- Bird, C., Nagappan, N., Murphy, B., Gall, H., Devanbu, P. (2011). Don’t Touch My Code! Examining the Effects of Ownership on Software Quality. Microsoft Research. https://www.microsoft.com/en-us/research/?p=161465