DataJoint is a validated Built-on partner in the Databricks Brickbuilder Partner Network (Bronze tier)

  • Why scientists reject AI outputs they cannot reproduce

    Why scientists reject AI outputs they cannot reproduce

    AI adoption across biotech and pharma drops sharply in the areas closest to discovery decisions. The reason is not resistance to change. A scientist who acts on an output they cannot trace or rerun is absorbing risk the organization has not priced; so refusing is the correct professional judgment.

    A line worth pushing on

    The line I keep hearing this year, in some version, from every corner of the industry:  we no longer have a data problem. We have a confidence problem.

    Half the industry now says a version of that, which usually means the phrase has stopped doing work. So the better question is where the confidence problem lives, because it is not evenly distributed.

    It lives at the bench

    Across biotech and biopharma organizations, reported AI adoption reaches 42% for generative molecular design, 40% for biomarker analysis and 29% for ADME prediction, as reported by Drug Discovery News in February 2026.

    Benchling 2026 Biotech AI Report, a November 2025 survey of ~104 biotech and biopharma organizations. Reported by Drug Discovery News.

    Those are the places where discovery decisions get made. Adoption falls as the stakes of the decision rise, which is the opposite of what a technology adoption curve normally looks like.

    Refusing is the correct professional judgment

    The standard reading of that data is scientist resistance, and it leads to more training and more change management. I think the standard reading is wrong.

    Declining to act on an output you cannot reproduce is not caution.
    It is the job.

    A scientist who acts on a confident answer they cannot reproduce is not being efficient. They are absorbing risk the organization has not priced and will not acknowledge until something goes wrong. Declining is not conservatism. It is the job.

    Confidence is a property of the system, not a state of mind

    Which means it cannot be trained into people. It comes from the same inputs and the same code returning the same result, every time, with a record of how it got there. When that is true, adoption follows without a campaign. When it is not, no amount of enthusiasm from leadership will move the number.

    This is also why the confidence problem and the data problem are not separate. Confidence is what a well-built foundation feels like from the outside.

    Would your most careful scientist stake a program decision on this output? If not, what would have to be true?

    The second sentence is the useful one. Whatever she names is your roadmap, and it will be shorter and more specific than any maturity assessment you could buy.


    Sources

    Benchling, 2026 Biotech AI Report, November 2025 survey
    Survey of ~104 biotech and biopharma organizations, US and Europe. 

    Drug Discovery News, The 2026 AI Power Shift, February 2026
    DDN’s coverage of the same report

  • Was your data made ready, or did it come out that way?

    Was your data made ready, or did it come out that way?

    Scientific data becomes AI-ready in one of two ways: as a consequence of how the work runs, or by being described after the work is finished. On paper the two look identical. The guarantees are not, because a retrofit depends on someone correctly describing afterward what happened, and it is never finished while new work keeps arriving.

    Two routes to the same document

    Scientific data becomes AI-ready in one of two ways, and the resulting documents can look nearly identical. What they guarantee could not be more different.

    The first route makes readiness a consequence of how the work runs. Structure is enforced as the work happens, and provenance falls out of execution instead of being a separate task somebody owns.

    The second attaches readiness to work that has already finished. Someone goes back, describes what happened, and records it.

    The same four stages. Two different points at which readiness is established.

    Why a retrofit does not stay finished

    When I ask teams deep into a retrofit what happens to work that ran before the project started, the answer is prioritization. When I ask what happens to the work running now, the pause is longer.

    That is the whole problem in one exchange. A race against production, and production does not pause.

    It is not an argument that retrofit fails. Retrofit works. What it cannot do is stay finished, because the process that created the backlog is still running.

    Retrofit is often the only honest option

    Nobody rebuilds twenty years of research because a strategy deck asked them to. For historical work, describing what happened is frequently the only route available, and doing it carefully is real work worth funding.

    The distinction that matters is between choosing retrofit for the past and choosing it for the future. The second choice usually gets made without anyone noticing it was a choice.

    Retrofit works. What it cannot do is stay finished.

    What the two approaches guarantee

    Work that produces itself in a ready state carries a record of what the system did. Work made ready afterward carries a record of what somebody believed the system did. Both are useful. Only one of them cannot disagree with the work it describes.

    Data that was made ready afterward carries one more assumption: that whoever did the describing understood what happened. Sometimes they did. The work that produces itself in a ready state does not need the assumption.

    For the work your team ran last quarter, did readiness happen as part of the work or after it?

    If the answer is different for last quarter than it will be for next quarter, that is progress. If it is the same, the retrofit is not a transition. It is the operating model.