Why Large Language Models Threaten Component‑Based Software Development

Reading guide: How should software development respond to the operation of large models? We need truly explainable AI built from testable components.

Current AI systems lack meaningful internal structure linked to their functions; they cannot be developed or reused as components, nor can concerns be separated or development be segmented.

This post discusses using large language models (LLMs) as part of a product solution rather than as a development tool such as AI coding assistants.

Applying LLMs to specific software development lifecycle activities presents problems, and the way we build products often differs from how we sell them to customers.

LLM delivery resembles buying a whole car: you pay for the entire project without expecting it to be a set of composable parts. Cars are not meant to be disassembled for public road use, and large tech firms prefer selling monolithic products to keep control.

However, this contradicts the universal concept of computation, which assumes tasks can be decomposed. A workable software component, regardless of its internal construction, consists of code that can be unit‑tested and must cooperate reliably with other components.

Even when a product uses an Oracle database, persistence exists at the conceptual design level; later technical decisions determine the storage type, and testing regimes may already be in place while database innovation continues.

In academia, the lack of decomposability often accompanies a lack of explainability. Several business reasons hinder LLM‑driven software delivery:

We cannot separate an LLM’s operation from its training data; the training process is opaque, and the model is expected to behave as‑is, which is unsuitable for component development.

Safety and privacy become issues because there is no proven method to prevent an LLM from exposing sensitive information.

Legal ownership is unclear; while deterministic computation can be reproduced, LLMs carry an immutable training baggage that makes it hard to prove they have not stolen existing technology.

Companies aiming to reduce carbon footprints move against LLM creators, who require massive compute power for incremental improvements.

Thus, software developers need a concrete response. Components should have defined roles, be replaceable, and be testable alongside similar components. External components must be built to the same computational standards so they can be reconstructed.

Design a process that delivers required functionality and develop a platform enabling developers to sustainably build it. By embracing testable components, we open the door to truly explainable AI, ensuring that any trained model is monitorable, reportable, reproducible, explainable, and reversible.

In theory, there is no reason this situation cannot change in the future, but currently the gap resembles comparing the scientific method to faith in relics—both are fundamentally different and unlikely to reconcile.