AI assisted development for life sciences software

How our engineers use it

Our engineers use Claude, GitHub Copilot, Codex and Lovable on client work that ships. They use the tools for code, tests, investigation and repetitive work. We give a model a defined task and the access it needs, then the engineer reviews the result and owns what goes into the product.

We are also building agents and MCP servers. We use agents for defined tasks. MCP servers give a model access to specific systems under rules we set beforehand. Each environment has its own idiosyncratic access rules. We have built several agents and MCP servers.

Where the tools fit in the workflow

Getting the tools running is usually straightforward. The harder part is deciding where they belong in the workflow, what the engineer needs to review, and how to use them without changing the way the team manages and ships software.

We can own the build, or work alongside the client's engineers on their codebase and within their constraints.

Generated code inside a validated system

What happens to the evidence, change control and release record when part of the code was produced with AI assistance.

What the reviewer signs for

The reviewer remains responsible for the code. For a change to a validated system, the review may need to be exacting enough that another person can see what was checked and why it was accepted.

What the model is allowed to see

Patient data, client repositories and regulated records each need a clear rule for what the model may see. That rule belongs in the policy, where it can be reviewed and changed deliberately.

Where AI should not be used

Some work carries a regulatory obligation. The team responsible for the software decides where AI can be used and where it cannot.

Testing

Test generation works well because the work repeats and the result can be checked by running the test. We use language models to draft test cases, find gaps in coverage, and keep the test suite consistent. The generated work stays inside the development and CI pipeline.

In a regulated context the evidence requirements stay the same. A generated test still needs a requirement, a version, a result and a record of the run so its provenance can be checked later. Our regulatory and validation practice runs that part.

We run the build

We own the build, and AI is part of how the team develops the software.

We work with your engineers

We put the tooling, working practices and review standard on your codebase with your engineers.

Define the controls

We define the policy and the supporting tools, then set the rules for where AI can be used and what the reviewer is responsible for.

Do you use AI to write our code?

Yes. Our engineers use these tools. They still review and own the code that ships. A validated system keeps the same evidence requirements when a model helps produce the first draft.

Can AI assisted development work in a regulated environment?

Yes. The rules need to be defined before the tools are used. They cover where AI can be used, what the reviewer is responsible for, what the model may see and what gets recorded.

What is SAIF?

SAIF is the policy we use for AI in software delivery. It covers the tools, where they can be used, and the review and record keeping around them.

What do you build with agents and MCP servers?

We use agents for defined tasks. MCP servers give a model access to specific systems under rules set in advance. We have built several agents and MCP servers.

Can you help our team adopt this?

Yes. We help with the tools, the working practices around them and the controls underneath.

Does our intellectual property go into a model?

We settle that before a tool is used. The policy names the permitted tools, the repositories they can access, and the agreements that apply.