The Vocabulary Inflation
Somewhere in the last two years, everything became a system. A Python script calling the OpenAI API and writing to a database? System. A Zapier automation pinging Slack on form submission? Integration. Two prompts chained together? Agent architecture. A dashboard with three widgets? Platform.
This shift in language is palpable across tech LinkedIn and Twitter. The vocabulary has inflated, and many of us, myself included, have contributed. A bio, a README, or a hackathon submission might have once described something as a "system" that, upon closer inspection, was merely a script with delusions of grandeur.
The AI era provided new terms, but it didn't automatically bestow the underlying complexity these terms usually represent. This gap between the words we use and the actual things we've built is turning much of the tech discourse into a costume party, where participants wear the labels of sophisticated creations without possessing them.
How Did We Get Here?
Two primary forces have converged to drive this linguistic inflation.
First, Large Language Models (LLMs) themselves can write like corporate blogs. They can generate sophisticated-sounding descriptions for even the most rudimentary functions. Feed an LLM a simple script that scrapes a website, and it can spin out marketing copy that describes it as a "dynamic data ingestion platform." This generative capability means that even if a developer isn't consciously inflating their project's description, the tools they might use for documentation or even code generation can inadvertently contribute to this trend.
Second, the sheer accessibility of powerful AI APIs has lowered the barrier to entry for creating complex-seeming applications. Previously, building a system that could understand natural language, interact with external services, and store data required significant engineering effort across multiple domains. Now, a few API calls and some basic scripting can achieve a semblance of this functionality. This democratization of sophisticated capabilities means more people can build more things, faster. However, it also means that the line between a well-architected system and a clever script becomes blurred.
The Distinguishing Features of a System
What, then, differentiates a true system from a script, however sophisticated?
A script is typically a linear sequence of commands designed to perform a specific, often singular, task. It executes, it finishes, and it's done. While it can be complex, its scope is generally limited and its execution path predictable.
A system, conversely, implies a set of interconnected components working together to achieve a common, often larger, goal. Key characteristics include:
- Modularity: Systems are composed of distinct, interchangeable modules. Each module has a specific responsibility and communicates with others through well-defined interfaces. This allows for easier maintenance, scaling, and upgrades.
- Scalability: A system is designed to handle increasing loads. This might involve distributing tasks across multiple processors, using load balancers, or employing asynchronous processing. A script typically scales poorly; you often just run more copies of it, which can lead to race conditions or resource contention.
- Resilience and Fault Tolerance: Systems are built with the expectation that failures will occur. They incorporate mechanisms for error handling, retries, and graceful degradation. If one component fails, the system as a whole should ideally continue to function, perhaps in a degraded mode. A script usually crashes entirely when an error occurs.
- Observability: Systems provide means to monitor their health, performance, and behavior. This includes logging, metrics, and tracing. Understanding what a system is doing, why it's doing it, and where it might be failing is crucial for operations. Scripts often lack this built-in introspection.
- Maintainability: The architecture of a system is designed for long-term support. Code is organized, documented, and follows established patterns, making it easier for different developers to understand and modify over time. Scripts can quickly become unmanageable "spaghetti code" as they grow.
A script might use an LLM to generate text. A system might orchestrate multiple LLMs, vector databases, user interfaces, and feedback loops to create a personalized learning environment. The difference lies in the architectural considerations, the robustness, and the interconnectedness of components.
The Danger of Mislabeling
Calling a script a system has consequences beyond mere linguistic inflation. It can lead to a fundamental misunderstanding of our own work and the expectations placed upon it.
For developers, this mislabeling can lead to a false sense of accomplishment. They might believe they've built something robust and scalable when they've actually created a brittle solution that will require significant re-architecture to grow. It can also lead to unrealistic expectations from stakeholders who assume a "system" possesses the resilience and maintainability of a true enterprise-grade solution.
For product managers and leadership, it obscures the actual technical debt being accumulated. If a "system" is actually a collection of loosely coupled scripts, its ability to scale, its potential failure points, and its maintenance overhead are vastly different from what the label implies. This can lead to poor strategic decisions regarding resource allocation, timelines, and feature development.
From a hiring perspective, it can be misleading. A candidate might list "built a customer support system" on their resume, implying extensive experience with complex architecture, when in reality, they wrote a few Python scripts that automated email responses. This makes it harder to accurately assess an individual's true capabilities and experience.
Navigating the Future
The AI revolution is undoubtedly enabling incredible new possibilities. We can build more with less, and the pace of innovation is accelerating. However, it's crucial to maintain clarity in our language.
Developers need to be honest with themselves and their teams about the nature of the software they are building. Is it a script designed for a specific, narrow task, or is it a system with modular components, fault tolerance, and scalability baked in?
The responsibility also falls on tech writers, marketers, and even executives to use terminology accurately. While it's tempting to adopt the latest buzzwords, doing so without understanding their technical underpinnings devalues the terms and misleads the audience. We should celebrate the ingenuity of clever scripting and automation without conflating it with the deliberate, architectural effort required to build true systems.
If you're building something, be precise. If it's a script, call it a script. If it's a system, ensure it has the components and considerations that justify the label. The clarity gained will benefit not just your own understanding but the entire technical community's ability to communicate and build effectively.