.png)
When evaluating any AI coding assistant, the key consideration is not whether it can produce scientific software (it can) but rather the quality of the underlying foundation on which it operates.
Working from a blank slate, an AI assistant produces code. What it cannot bring is seven years of codified scientific knowledge: the conventions for how a plate reader schema must be structured, the reusable components covering most of what every lab data integration requires, the design patterns tested and refined across hundreds of production deployments. Tetra OS provides that foundation. The difference shows immediately in the quality and consistency of what gets built.
We demonstrated this at our September Technical Showcase. The use case: a Molecular Devices FLIPR fluorescence imaging plate reader that TetraScience had not seen before. The goal was a complete bidirectional data flow: plate layout from a Signals ELN to the instrument, raw results from the instrument back through the Tetra Data Foundry, a new IDS schema to represent the data in a vendor-neutral format, calculated results written back to the ELN, and a visualization app for scientists to inspect plates and read dose-response curves. Everything automated. Nothing transcribed by hand.
We built it in one session, using Claude Code with Tetra plugins installed. (Here’s a clip from the Showcase in which I share why it’s essential to ground your AI tooling on well-engineered and contextualized data for end-to-end builds.)
The starting point was a prompt file, a use case transcript from a meeting with the scientists, and a sample data file from the instrument. From there, Claude handled the assembly: designing the IDS schema to TetraScience conventions and building the pipeline using the Tetra Data Assistant plugin, then wiring the Signals connector, scaffolding the plate visualization app, and creating Jira tickets to track each component as it was built. Steps like these draw on other TetraScience plugins and skills, which our internal teams also use to accelerate this kind of build.
The Tetra Data Assistant plugin is critical to the schema design step. It draws on the IDS core documentation, which lays out the rules for organizational context, scientific measurements, datacubes, sample links, primary and foreign keys, and applies them consistently. The result is a working schema that conforms to the same shape as every other plate reader IDS in the Tetra library, which means it is maintainable, extensible, and usable by the next person building on top of it.
That consistency compounds. Each new use case built this way adds to the library. Each improvement to a skill or MCP immediately helps the next builder. The AI is accelerating not just one build but the entire program of builds, because the foundation it draws from gets stronger with each one.
Flexibility is the part worth understanding. During the live session, we extended the use case mid-stream — adding a new standalone pipeline to extract target names from incoming file names and apply timestamped metadata labels, submitted as a plain-English prompt while the visualization app was running. It worked in minutes. That kind of real-time iteration, building on a governed foundation rather than from scratch, is what the combination of AI tools and Tetra OS enables.
Watch the full recording here.
Register here for the October showcase: Applying Scientific AI to Upstream Bioprocessing -- October 15 -- Sessions at 9 AM / 12 PM ET. We'll have live demos showing what AI-assisted workflows look like on top of three production use cases: clone and media titer prediction, image-based cell culture analysis, and natural language querying of bioprocess data. Real models, real data, real workflows.