A small EU-based computational biology outfit is hiring a VP of Engineering. The company builds AI-driven predictive models that simulate biological experiments entirely in software — replacing wet-lab testing with learned approximations. And they need a human executive to manage the humans who write the infrastructure for the software that replaces the wet labs.
The same dependency appears twice in the argument: the company trusts models to replace lab work, but not management work. This is a company whose entire commercial proposition is that complex, messy, real-world biological systems can be accurately modeled by machine learning. They are betting that deep neural networks can stand in for pipettes and petri dishes. And they need a human executive to manage the humans who write the infrastructure for the software that replaces the wet labs.
There is an internal inconsistency here.
If you genuinely believe that biology — a chaotic, nonlinear, and still poorly understood domain — can be virtualized with sufficient data, compute, model design, and validation, then it is hard to argue in principle that a software engineering department cannot be.
What the role actually does
The VP of Engineering at a company of this size and stage is not a pure people-manager. This is a hands-on leadership role. The JD makes that explicit. The job includes several recurring functions:
Team building and staffing. Figuring out what roles the engineering org needs, writing job descriptions, interviewing, making offers, managing the pipeline of candidates. Then keeping the resulting humans motivated, aligned, and not actively looking at LinkedIn at 2 p.m. on a Tuesday.
System reliability. Owning uptime, incident response, and continuous improvement for the core platform. Something breaks at 3 a.m., someone pages the VP, the VP coordinates the response.
Standards and alignment. Establishing best practices across the engineering org. Code review norms. CI/CD pipelines. Architectural decisions. Preventing silos and technical debt from accumulating to the point where the platform collapses under its own weight.
Product partnership. Sitting with Product, looking at system and user analytics, and translating scientific vision into a technical roadmap. Being the bridge between "what the science needs" and "what the code can currently do."
The useful question is which parts are automatable, which require accountability, and which require trust.
The automated engineering org
Parts of staffing are already easier to automate. A language model reads the platform's architecture, identifies the capability gaps, drafts job descriptions, and screens candidates against a technical rubric it generates from the codebase itself. The model knows what stack you run, what your technical debt looks like, and what skills are missing — because it has read every commit, every PR, every incident postmortem. It may have broader access to written traces of the engineering org than the VP does. Candidate screening becomes a structured comparison between a person's public history and the org's actual gaps. Humans would still handle interviews, compensation tradeoffs, legal review, and final accountability.
Some reliability workflows are also candidates for automation. Observability tools already auto-detect anomalies. Some larger platforms already automate parts of detection, rollback, and incident communication. The VP's role in incident response is coordination and communication. A model can draft the incident report, post the update in the status channel, and notify stakeholders. The human "owns" reliability in the sense that their name is on the org chart when the auditors ask who is responsible. Automation can handle parts of the response, especially detection, rollback, ticket creation, and drafting updates.
Some engineering standards can be encoded as review rules or policy checks. Many standards can be written down, but applying them still involves tradeoffs, exceptions, and context. You write a system prompt that encodes your architectural principles, your review norms, your definition of done. Every PR is checked against it. Every new service is scaffolded from it. Parts of the standards document could become automated checks or templates. The model enforces it on every commit, more consistently than manual review in some routine cases. Technical debt is flagged when the model detects a divergence between the stated pattern and the actual code — and it can write the refactoring PR itself.
Product partnership is harder to reduce to workflow automation. This is where the VP sits between the scientists and the engineers, translating "we need the predictive model to handle this new assay type" into "here's the infrastructure change, here's the data pipeline, here's the timeline." But if the company's own thesis holds — that complex systems can be modeled well enough to be predictive — then some translation from product requirements to technical plans may be model-assisted. A model that has ingested the entire codebase, the product roadmap, the scientific literature, and the incident history can generate the technical plan from the product requirement with useful accuracy in constrained cases. Part of the VP's judgment comes from pattern recognition, but also from incentives, relationships, risk tolerance, and accountability. A model may have access to more recorded decisions than any single VP, but access to records is not the same as experience.
Where it breaks
The argument has limits.
Trust is much harder to automate than workflow coordination. A 40-person startup does not keep its engineering team because the systems are well-managed. It keeps them because there is a person they trust to make fair calls about priorities, to advocate for them in budget fights, to absorb the anxiety of a bad quarter without transmitting it downward. A model cannot be the person who looks a tired engineer in the eye and says "take the weekend off, I'll handle the rollout." That is a social and emotional function, not just an operational one.
Formal accountability remains difficult to delegate to software. When the platform goes down during a partner integration and the partner's CTO gets on a call demanding to know what went wrong, a model cannot be the name that takes the heat. Regulators, investors, and enterprise partners want a human signature on the org chart. Not because the human did something the model couldn't, but because current legal and commercial systems assign liability to people and organizations, not to models themselves. The VP is also a named accountable officer inside the organization.
There is also a deeper scientific limitation. The company is building predictive models for biology. Biology has many examples where plausible models failed under experimental validation. If the company's own engineering org were run by a model with the same epistemic limits, a high-confidence failure would quickly expose the need for human review and accountability. The VP may exist not only because of task execution, but because the company's entire premise is that models can do jobs humans used to do — and someone still has to own the consequences of model-driven decisions.
The inconsistency
This company is selling the idea that you can replace wet labs with neural networks. It is asking a human to run the department that builds the software that replaces the wet labs.
If the company believes its thesis generalizes beyond biology, it should specify which engineering-leadership tasks it expects to automate and which it keeps human. If it does not generalize, the limits of that claim should be stated explicitly.
