Context
Who is talking, what the setup is, and what a scientist's job becomes when the AI does the building.
The framing for this talk
Prof. Ethan Mollick, Professor of Management, The Wharton School, University of Pennsylvania. @emollick on X, September 12, 2026 · Faculty profile · One Useful Thing
This talk sits in that gap. The capability is real enough to build on today; the unevenness is real enough that the checks are not optional.
About me
AI Engineer (Life Sciences); Global Head of AI / GenAI Practice at 20/15 Visioneers. Columnist at Drug Target Review; Editor at SLAS Discovery. PhD, Newcastle; BSc, Imperial College London. I build software appliances for R&D scientists, including project fred and Compound Insights. I am a systems engineer by training and a business person by trade, not a professional software developer. What is on this page is reachable from where a working chemist already stands.
My environment: one browser tab and one terminal
No developer tooling to learn. The app writes the code; I download the file, run the command, and paste the result back. That paste-back step is where control lives.
On the two models. These apps are complex by nature: the science, the data structures, and answering a question sufficiently rather than plausibly. So I run Fable 5.1 Medium on everything until my weekly tokens for it run out, then switch to Opus 5 High for the rest of the week. The principle is to use the strongest model you can afford to run all day, not to match a model to a task. This balance will change as Anthropic releases new models.
The services on the right are the ones I reach for, not requirements. Where a tool runs is a choice made per tool, and "application" does not mean "website." I run all three ways: locally on the laptop for anything with confidential data, on my own server when it needs to keep running unattended, and on a hosting service when other people need to reach it. The same build method produces all three.
The same choice applies to the data. Build and demonstrate on synthetic or public data, then point the finished tool at the real thing once it has earned that. Nothing in the method assumes production data on day one.
Scope: you become the product manager
Claude does the building. You own the decisions, the guidance and the bias. A product manager does not write the code; they decide what gets built and whether it is right. "Managing the bias" means: the model will run ahead, agree too easily, and fill gaps with plausible guesses. Your job is to notice and steer.
What stays with you
- What the tool is for, and what it must never do
- Which of two readings of a request is the one you meant
- Whether a result is scientifically plausible
- When to stop building and step back
What moves to Claude
- Design, code, documentation, GitHub, testing, deployment
- Writing the checks that verify its own work
- Drafting the specification you then argue with
The challenges for a scientist who does not code
Click a challenge to see how the consumer apps now cover it. None of this removes the scientist's judgment; it removes the developer bottleneck.
From vibe coding to AI coding
1. Assisted
You write the code. The AI suggests, completes, explains. Your effort: typing.
2. Directed
You describe. The AI writes. You still open and edit files. Your effort: editing and fixing.
3. Generated
You specify and review. The AI writes everything, including the checks. You never edit code. Your effort: specifying and verifying.
As you move right, the unit of work stops being a line of code and becomes a specification, a change script and a verification. Speed goes up sharply; so does the cost of a vague ask, because the AI will build the vague thing confidently. Control does not disappear. It moves from the keyboard to the settings, the spec and the checks. That is the Principles section.
Principles and guidelines
What the app actually is, and the three habits that keep a capable junior partner pointed at the objective.
The app is more than the model
Claude.ai and ChatGPT wrap a model in a harness. The harness is what turns a text predictor into a colleague. Both products now have this shape; the component names differ between vendors.
Together: a junior partner
- World knowledge across chemistry, statistics, software and writing
- Broad, strong skills: reads, codes, calculates, drafts, checks
- Remembers your setup and your project, and can act, not just talk
What the scientist brings
- The question worth asking, and the data
- Domain judgment: what is plausible, what is not
- Accountability for what gets published or used
Principle 1: control lives in the settings, not in the chat
Behavior is set once in Personalized settings and Project instructions, then enforced on every reply. Four layers, from most general to most specific: Personalized settings (every chat), Project instructions (this application), the continuation document (this session, written by the last one), and the conversation itself. Neither of the two standing files is code. Both are plain English, and anyone could write theirs in an afternoon. When behavior drifts, the fix goes into one of these two files, not into the chat.
Who I am, how I work, how every answer must be shaped
- My machines, my shell, my download folder, my tools
- Every reply opens with the objective and whether the last step advanced it
- Name any deviation from what I asked, or say there was none
- Give honest answers, never optimistic ones. Include the risks and the contrary view.
- When you ask me a question, state your own lean and why
- Files arrive as downloads with a checksum I can verify; no code in chat unless I ask
- One command block per turn; I paste the output back before you continue
- An item I have closed stays closed. Do not re-list it.
- Do not give me timelines or sizings
- Never give me a command that can kill my terminal
Principle 2: Claude is my junior partner
Freedom to do the work, paired with the monitoring that comes with that relationship. It is fast, capable and confident, and it needs supervision exactly where a bright new hire would. Trust the work you can verify.
Freedom
- Chooses the approach and says why
- Writes all the code, every document, every commit message
- Writes the checks and probes that test its own work
- Runs reconnaissance without asking permission
Monitoring
- Every file carries a checksum; I verify it before it goes anywhere
- Every change runs as a dry run first; I say apply
- It must read the real file, not remember it
- I approve each step; nothing deploys without me
Principle 3: force the step-back conversation
Chats have limits. The record does not. Left alone, a project drifts toward whatever is tractable rather than whatever matters; the step-back is where the human re-asserts priority.
What the step-back captures
- Open items with a stated lean, grouped by priority; science items outrank engineering items
- Hypotheses that turned out wrong, kept in the record rather than deleted
And what it enforces
- Every fix landed in the workflow, not in a one-off command: if it only works this once, it is not finished
- What is closed, so the next session does not reopen it
What goes wrong, and it will
Failure patterns from my own chat history on Compound Insights, and the check that catches each one. None of these is a reason not to use the tool. Each is a reason to keep the checks.
It reasons from memory instead of the real file
Four times in one session. All four caught by the guards on the change script before any write.
It says it reviewed when it only re-read
Asked directly, it admitted no independent review had run. The real review then found a defect that fails every run.
It announces a deliverable that is not there
"Probe presented" with no probe in the reply.
It quietly narrows or widens the task
Adjacent defects become the task; the objective stalls.
The base rate is worth stating. In one session, the adversarial read caught my assertions three times; my own confidence caught them zero times. That sentence was written by Claude, about itself. The lesson is not that it lies; it is that fluent confidence and correctness are uncorrelated, so the process has to supply the correlation.
Case study: compoundinsights.dev
Rigorously cited drug-compound dossiers from public data and literature-grounded inference. Built with Professor Andreas Bender (domain review) and Dr Jack Scannell (co-author); being submitted to SLAS Discovery. Every line of code written by Claude; every decision mine.
Three compounds
Imatinib CHEMBL941 | Gleevec
The pilot. Data-rich kinase inhibitor with many approved indications. Ran end to end first; now a frozen reference used only to check that the pipeline still behaves.
Governing principle: attribute, never assert
Every inferred value shows the prompt version, run identifier, number of lookups, the state of each citation check and a grounding verdict. Nothing is endorsed beyond what its evidence supports.
How it works, in plain terms
Rows versus claims
A database gives you a binding affinity; the dossier gives you "binding mode X, kinase class Y", each sentence with its paper attached.
Declining is a result
For elecoglipron the engine mostly says "no data found". Whether it declines where it should is the test, and it is reported, not hidden.
Inside fred: it looks things up, it does not recall
A reasoning loop with a record of every lookup. fred is a component, not the product. A model that recalls can invent; a model that looks up leaves a trail, and the trail is what a reviewer can check without trusting me or the model. The same question twice may take a different route; that is the nature of the engine, so we test by repetition.
How I used Claude: design, coding, testing
1Design: spec before code, then an adversarial cold-read, then code
Conversation (what, why, for whom; Claude asks, I decide) → Specification (written by Claude, argued over by me) → Cold-read (a fresh prompt attacks the spec as an adversary) → Amended spec (defects fixed; the falsified claims stay in as a record of their withdrawal) → only now, code.
What the cold-read actually finds. One spec, one pass: eleven defects. Five were structural: a field defined at the wrong granularity, labels colliding with existing item names, a circular step that used a prompt a later step produced, and a "measurement" that was really a docstring reading. All found before any code existed.
The rule that came out of it. Checking while writing is not a review. Mechanical checks (brace balance, encoding) are not a review. The review is a separate pass, with a prompt written to find fault, and it runs before I read the document myself. Ask Claude to write the attacking prompt too.
2Coding: every change is a script Claude wrote and I ran, with checks built in
One turn, one change, one verification: I paste the current state (checksums, versions, health) → Claude writes a change script, not a blob of code to paste → dry run shows exactly what would change and changes nothing → I read it and say apply → checksums confirm the result; anything unexpected aborts → commit and push, so the record matches the machine.
A change script refuses to run if the file is not what it expected. One aborted correctly when it found four matches instead of two: two were historical record and must not change. That refusal is the single most valuable behavior.
3Testing and iteration: never let it mark its own homework
For the inference engine: three questions, asked three times each, with answers that must be exact values a database holds today → every citation re-resolved (invented or missing is a violation) → an independent second model scores each answer, calibrated first on deliberately corrupted answers → compared cell by cell against a stored baseline, refusing if the yardstick itself moved.
The one that got caught. Asked for human SOD1, the engine returned a real, resolvable UniProt entry for the wrong protein: an unreviewed 134-amino-acid record instead of the reviewed 154. The citation was genuine; the protein was not. The citation check flagged it and the run was refused before the judge saw it. A test the engine had written for itself would have passed.
Iteration in plain words. I say what is wrong in my own language. Claude proposes the fix and the probe that proves it. I approve the probe before the fix. For the published pages, Claude writes spot-check probes against the HTML so I never inspect a page by eye. If the probe cannot go red, it is not a probe.
The live walkthrough, in order
- Landing page: three compounds, one comparison
- One dossier: a claim, its citation, its verdict
- The comparison page: where evidence is missing and it says so
- My Claude project: the standing instructions
- A spec and its adversarial cold-read
- A change script run: dry run, apply, checksum
Items 1 to 3 are the product; 4 to 6 are how it was built.
Three habits to take home
Small habits, not a programming language. Tick them off as you try them; this list lives only on this page while it is open.
Describe before you build
Talk through what you want, in your own scientific language. Let it ask questions. Most failures are vague asks, not bad code.
Iterate in plain words
When something is wrong, say what is wrong. Let it fix the code. You never touch the code yourself.
Never trust its own test
It will write a test that confirms its own mistake. Make it prove the work independently, and make the proof capable of failing.
If you have never coded: yes, this works for a prototype on your own data, real or synthetic. The discipline in the Principles section is what gets it past prototype, and that discipline is learnable in a few weeks of use.
Slide by slide, with presenter notes
All 23 slides in order, each with the note I speak from and the running clock. Download the PDF for the diagrams at full size.
Filling the gaps
Where to go next, and how to reach me.
Eric Ma's blog
Practical writing on scientists working with AI tools.
Learn Anything: agentic programming
An event for taking the next step beyond this talk.
Paperless Lab Academy USA workshop
Hands-on AI coding for scientists, October 12-14, 2026, Cambridge, Massachusetts.
SLAS Discovery special issue
Real-life AI case studies in drug discovery; Compound Insights is being submitted.
Compound Insights
The case study from this talk.
project fred
The inference engine underneath it.
Five free registrations for Paperless Lab Academy USA
Scan for a free registration. Five are available, first come first served. I am running a workshop on AI coding for scientists there; the talk is the short version.
October 12-14, 2026, The Charles Hotel, Cambridge, Massachusetts.
Contact
Dr Raminderpal Singh
raminderpal@20visioneers15.com
raminderpalsingh.com