Software Engineering for Pre-Trained Models

What changes about software engineering when the reused component is a learned model?

Reusing a model introduces new engineering obligations
A model moves through a familiar reuse lifecycle — registry, select, integrate, validate, evolve — but several assumptions of conventional dependency management stop holding. Reuse is familiar while the artifact is not; the ecosystem keeps moving and must be re-measured; identity and interoperability are not guaranteed; reuse requires reengineering downstream; and risk travels with the artifact.

Developers have been reusing software components for decades; pre-trained models inherit many of the same engineering problems, but also introduce new ones, because their identity, behavior, provenance, and interfaces are less explicit than those of conventional software packages.

We study pre-trained model reuse as a software-engineering practice. Our work asks which lessons from conventional component reuse still apply, where learned artifacts break those assumptions, and what new engineering methods are needed for selecting, integrating, validating, securing, and evolving models obtained from public registries.

Pre-trained models are a distinct kind of software dependency

Early work in this programme established that reusing a pre-trained model is not simply a machine-learning convenience. Engineers must discover, interpret, adapt, validate, and maintain artifacts whose interfaces and provenance are less explicit than those of conventional software packages.

The model ecosystem must be measured

Pre-trained model ecosystems change quickly: registries grow, conventions shift, new model families and formats appear, and downstream reuse practices evolve with them. Engineering guidance therefore cannot rest on a static picture of how models are produced or reused. We build datasets and conduct ecosystem-scale studies so that emerging practices, failure modes, and developer needs can be measured as they change.

Model identity and interoperability cannot be assumed

Conventional dependency management assumes a named artifact can be identified, and that declared interfaces delimit how it composes with the rest of a system. Pre-trained models weaken both assumptions. Nominally equivalent models can differ, names can be inconsistent, and supposedly portable representations can fail when moved across tools and frameworks.

Reuse shifts substantial engineering work downstream

Reusing a trained model does not eliminate engineering work; it relocates it. Downstream developers often have to reproduce results, adapt artifacts across frameworks and hardware, reconstruct missing assumptions, and determine whether the model remains valid for a new use.

Security is part of the reuse contract

A reused model is not only a learned function. It arrives as a software artifact with provenance, serialization formats, dependencies, and assumptions about how it will be loaded and executed. Those properties make security part of the reuse contract.

Funding and support

This work has been supported by: