The "AI Engineer" is Just the "Software Engineer": A Manifesto

The Fork in the Road for Engineering Leadership

Engineering leaders today find themselves at a strategic crossroads. Boards, CEOs, and the market at large are exerting immense pressure to "do AI," creating a frenetic rush to adopt Large Language Models (LLMs) and integrate them into products. This pressure has spawned a confusing and rapidly proliferating set of new job titles, chief among them the "AI Engineer". In response, organizations are scrambling to hire for this seemingly new role, often with the intention of creating specialized teams dedicated to building the "AI parts" of their applications.

This presents a critical decision point for every VP of Engineering: Do you chase the hype, create a new "AI Engineering" silo, and attempt to bolt it onto your existing organization? Or do you recognize this technological shift for what it is—an evolution of the craft of software engineering—and invest in evolving the team you already have?

This manifesto argues that the latter path is the only one that leads to sustainable, scalable, and reliable innovation. The "AI Engineer" is not a new profession; it is the 2025 evolution of the Software Engineer. Creating a silo for "AI Engineering" is a grave strategic error that ignores decades of hard-won software development wisdom. This approach will inevitably lead to brittle, unmaintainable systems plagued by a new and virulent form of technical debt, one that extends far beyond messy code into the very data and models that power these new applications. The core principles of our craft—rigor, discipline, and a focus on reliability—are not obsolete. In the face of the probabilistic chaos introduced by LLMs, they are our primary defense.

Your First Question: "Do I Need to Hire an 'AI Engineer'?"

For many engineering leaders, the most immediate question is one of headcount and team structure. The pressure to deliver AI features translates into a perceived need to hire specialists with "AI Engineer" on their resume. However, a closer examination of the role reveals that this title is more of a market-driven re-branding than a fundamentally new discipline.

Deconstructing the Role: Specialization, Not Separation

A typical job description for an AI Engineer calls for expertise in machine learning frameworks like TensorFlow or PyTorch, a strong foundation in data science and statistics, and an understanding of neural network architectures. While these are indeed specialized skills, they are best understood as a new specialization within the broader field of software engineering, not as the basis for a separate profession.

Consider an analogy from a previous era of technological change. When relational databases became the backbone of enterprise software, organizations did not create a separate "PostgreSQL Engineering" department. They hired software engineers and expected some to develop deep expertise in the data layer—mastering query optimization, schema design, and performance tuning. The fundamental role remained "Software Engineer"; the specialization was "database expert." The same logic applies today. The core competencies of a great engineer—system design, architectural thinking, writing clean, maintainable, and testable code—remain the indispensable foundation. Building an application that uses an LLM is, at its heart, an act of software engineering in the AI era.

The real challenge in building AI-powered applications is not the esoteric art of model training, which for most companies will mean using a pre-trained model via an API. The most difficult part is the system integration and orchestration: safely and reliably incorporating the probabilistic, non-deterministic outputs of an LLM into a deterministic, resilient software system. This is a classic software engineering problem, one of managing complexity, handling failure modes, and designing robust interfaces. As research from MIT highlights, real-world software engineering is far broader than the narrow task of writing a single function; it involves architecture, design, and the masterful use of a wide suite of tools to build complex systems. LLMs are a revolutionary new tool in that suite, but they do not replace the craft itself.

The industry's creation of the "AI Engineer" title is a symptom of a deeper misunderstanding. It conflates the scientific, research-oriented role of a Machine Learning Scientist—who might have a PhD and focuses on creating novel algorithms—with the applied, product-building role of an engineer. Most organizations do not need to invent new models; they need to build reliable products using existing ones. That task does not require a new type of employee; it requires existing software engineers to learn a powerful new technology stack. This reframes the challenge from a difficult and expensive hiring problem to a more manageable upskilling and organizational design problem.

The Real Question: "How Do We Build Reliable Products with Unreliable Components?"

Once the focus shifts from who to how, engineering leaders can address the central technical challenge of this new era. The fundamental property of LLMs that separates them from all prior software components is their non-determinism. A traditional API, given the same input, will always produce the same output. An LLM might not. As Martin Fowler has astutely observed, the "hallucinations" and unpredictability of LLMs are not a bug to be fixed but an inherent feature of the technology that must be managed. This reality demands a renewed and even more rigorous application of timeless software engineering principles.

The Primacy of Engineering Principles

Core architectural principles like modularity, abstraction, high cohesion, and loose coupling are no longer just "best practices"; they are essential survival mechanisms. In an LLM-powered system, these principles are the primary tools for isolating the "blast radius" of the non-deterministic component. A robust, architecture-first approach is critical. The system's stable, deterministic scaffolding must be designed and built with resilience in mind before the volatile LLM component is plugged in. The LLM should be treated like a powerful but unpredictable third-party service: wrapped, isolated, and never fully trusted.

The New Face of Technical Debt

This need for architectural rigor is amplified by the unique and insidious forms of technical debt that AI systems introduce, which extend far beyond code into the realms of data and models.

• Data Dependencies & Model Decay: Traditional software logic is stable until a developer changes the code. An LLM-powered feature, however, can degrade silently and invisibly over time. This phenomenon, known as "model drift," occurs as the real-world data the model sees in production ("inference") begins to diverge from the data it was trained on. "Concept drift" happens when the relationship between inputs and correct outputs changes, while "data drift" occurs when the statistical properties of the input data itself change. Without a system designed for continuous monitoring and retraining, a feature that worked perfectly at launch can become unreliable or fail completely, creating a maintenance nightmare.
• The CACE Principle: In machine learning systems, there is a principle known as CACE: "Changing Anything Changes Everything". Because the features and signals used by a model are often deeply entangled, a small, seemingly isolated change—altering a prompt, tweaking an input feature, or updating a data source—can have unpredictable, cascading effects on the model's behavior. This makes a mockery of isolated changes and piecemeal bug fixes if the system is not built on a foundation of strong abstraction boundaries.
• Glue Code and Black Boxes: The temptation to quickly stitch together multiple AI services and data pipelines can lead to a massive, hidden accumulation of "glue code". This supporting code, which often lacks business logic of its own, becomes a brittle, untestable morass that makes it nearly impossible to evolve the system. This problem is compounded by the "black-box" nature of many models, whose internal reasoning is opaque, making debugging a matter of guesswork without rigorous engineering discipline.

• 

Creating a separate "AI Engineering" team is the surest way to institutionalize this new form of technical debt. When a specialized team is responsible only for the "model" and "throws it over the wall" to a "traditional" software team for integration, a critical ownership gap is created. The AI team, focused on model-centric metrics like accuracy, lacks a deep understanding of the constraints and failure modes of the production software environment. The software team, in turn, treats the model as a magical black box whose bizarre failure modes they cannot predict or mitigate. When the system fails in production due to subtle model drift, a blame game ensues. The software team will say, "the model is wrong," and the AI team will retort, "it worked on our test data." This organizational silo is not just inefficient; it is the architect of future failure. The only way to build a reliable system is to have a single, cross-functional team of software engineers who own the entire problem, from data pipeline to API endpoint, and are skilled in both traditional code and applied AI techniques.

The Modern Engineering Playbook: Applying Rigor to LLM Systems

To navigate this new landscape, engineering leaders must adapt their existing playbooks for testing, observability, and security. The challenges are new in their specifics, but the underlying principles of risk mitigation and quality assurance remain the same. The goal is to wrap the probabilistic core of the LLM in a deterministic shell of rigorous engineering.

"How Do We Test This?": From Deterministic to Probabilistic Testing

The most immediate casualty of non-determinism is the traditional unit test. A test that asserts assertEqual(llm_output, "expected_string") will fail intermittently, becoming a source of noise and frustration. As Martin Fowler warns, such non-deterministic tests are a "virulent infection" that can ruin an entire test suite by eroding trust in the results.

The solution is not to abandon testing, but to adopt a more sophisticated, multi-layered strategy:

1. Harness Testing (Deterministic): The application code that surrounds the LLM call must be tested using traditional methods. Use mocks and stubs to simulate the LLM's API. Write unit and integration tests to verify how your code handles the full range of possible responses: valid outputs, error codes, malformed JSON, slow responses, and timeouts. This ensures the deterministic logic of your application is rock-solid, regardless of what the LLM does.
2. Model Behavioral Testing (Probabilistic): The LLM's output itself requires a new testing paradigm. Instead of asserting equality, test for properties and invariants.
   • Property-Based Testing: Define the characteristics of a valid response and test for them. For example, does the LLM's output always parse as valid JSON? Is a generated summary always under 200 words? Does a classification output always belong to a predefined set of categories, like ['positive', 'negative', 'neutral']?
   • Statistical Validation: For certain use cases, it's possible to test the distribution of outputs. This involves running the same prompt hundreds of times and asserting that the frequency of different outcomes matches an expected statistical profile, a technique similar to the Multinomial test used in scientific computing.
   • Evaluation Suites (CI/CD Integrated): The most powerful technique is to create a "golden dataset" of representative prompts and their desired qualitative outcomes. In your CI/CD pipeline, this suite is run against every proposed model or prompt change. The outputs can then be scored for qualities like relevance, coherence, and factual consistency. This scoring can even be automated by using another, more powerful LLM as an impartial "judge" to evaluate the quality of the responses from the model under test.

"What Do We Monitor?": The New Pillars of Observability

In production, standard observability metrics like latency, error rate, and CPU/GPU usage are still necessary, but they are dangerously insufficient for managing LLM-powered applications. A feature can be fast, error-free, and resource-efficient, yet be failing silently by producing low-quality or nonsensical results.

A comprehensive observability strategy for LLMs must include new pillars:

• Resource & Cost Metrics: LLM APIs are often priced per token. Monitoring token usage per transaction, per user, or per feature is not just a performance metric; it is a critical cost management and business metric.
• Model Behavior Metrics: The quality of the LLM's output must be tracked as a primary health indicator. This involves capturing metrics on response quality, factual correctness, coherence, and relevance. This data can be sourced from explicit user feedback (e.g., a "thumbs up/down" button) or from automated evaluation systems running in the background.
• Drift Monitoring: This is arguably the most critical new category of monitoring. Engineering teams must implement systems to detect Data Drift (changes in input distributions), Prediction Drift (changes in output distributions), and Concept Drift (changes in the underlying relationships between inputs and outputs). These drift metrics are the earliest leading indicators that a model's performance is degrading in production and that retraining or intervention is required.

"How Can This Break?": Adapting Security for a New Threat Model

The introduction of LLMs creates new attack surfaces and requires an expansion of the security mindset. The OWASP Top 10 for Large Language Model Applications provides the essential framework for understanding these new risks. However, these new threats are often new manifestations of familiar security challenges.

• Prompt Injection (LLM01): This is the most well-known new vulnerability, where an attacker crafts input to trick the LLM into ignoring its original instructions or executing malicious commands. This should be understood as a sophisticated form of input validation failure. The engineering solution is conceptually the same as for preventing SQL injection: treat all input, especially input from users or third-party sources, as untrusted. Sanitize it, constrain it, and never blindly pass it to sensitive downstream systems.
• Training Data Poisoning (LLM03): An attack where malicious data is inserted into a model's training set to compromise its integrity is fundamentally a supply chain vulnerability. The defense is to secure your data pipelines with the same rigor you use to vet third-party code libraries. Verify data sources, implement integrity checks, and prevent the model from scraping data from untrusted sources.
• Insecure Output Handling (LLM02): This occurs when an application blindly trusts the output of an LLM and passes it to other parts of the system. This is a classic failure to sanitize outputs. An LLM's generated output—whether it's code, HTML, or a command—must be treated as untrusted user input before it is executed or rendered to prevent attacks like Cross-Site Scripting (XSS) or Server-Side Request Forgery (SSRF).

These new challenges do not require an entirely new field of security. They require the diligent application of established security principles to a new and more complex set of inputs and outputs.

The New SDLC: Treating Prompts and Models as First-Class Code

To operationalize this level of rigor, the very processes of software development must evolve. If LLM-powered features are to be treated as reliable software, they must be managed within a disciplined Software Development Lifecycle (SDLC). This marks the end of ad-hoc prompt engineering, where prompts are tweaked in a web-based playground and then copy-pasted into the codebase.

The "Prompts as Code" Revolution

Prompts are not merely text strings; they are a new form of source code that directly controls application behavior and logic. As such, they must be managed with the same discipline as any other code asset.

This "Prompts as Code" philosophy requires a fundamental shift in practices:

• Version Control: Prompts must be stored in a version control system like Git, not hard-coded into functions or hidden away in database tables. This ensures every change is auditable and reversible.
• Code Review: Any change to a production prompt must go through the same pull request and peer review process as a change to application code. This review should assess not just the prompt's wording but also its potential impact on performance, cost, and security.
• Automated Testing: As detailed previously, every prompt change must automatically trigger the execution of the probabilistic evaluation suite to guard against regressions in quality.
• Continuous Integration & Deployment (CI/CD): The deployment of a new prompt version should be a fully automated, low-risk event managed by the CI/CD pipeline, not a manual, high-stakes update.

The Management Challenge and Modern Tooling

Managing this new asset class at scale, however, presents unique challenges. Prompts, fine-tuning datasets, and evaluation examples can be large text assets that are not ideally suited for review in a standard Git diff. Furthermore, effective prompt engineering often requires close collaboration between technical engineers and non-technical domain experts, a workflow that can be clunky when confined to a code-centric process.

This is where the traditional SDLC toolchain starts to show its limitations. Managing a growing library of versioned prompts, complex evaluation datasets, and collaborative feedback from domain experts requires more than just a Git repository. This is the gap that platforms like TextAgent.dev are designed to fill. By providing a specialized content management system for AI assets, TextAgent.dev acts as a version-controlled, collaborative "single source of truth" for your prompts and datasets, integrating seamlessly into your CI/CD pipeline. It allows your engineers to treat prompts with the rigor of code, while enabling domain experts to contribute to their refinement in a structured, accessible environment.

A modern CI/CD pipeline that incorporates these principles would look fundamentally different from its predecessors.

The "Prompts as Code" movement, supported by modern tooling, is the critical bridge connecting the experimental, ad-hoc world of early AI development with the rigorous, scalable world of professional software engineering. It is the tactical implementation that makes the strategic argument of this manifesto a reality.

Your Action Plan: Don't Build a Silo, Build a Bridge

The principles outlined in this manifesto are not merely theoretical. They translate into a clear, actionable plan for engineering leaders. The goal is not to halt innovation but to place it on a foundation of engineering excellence that allows it to scale reliably.

Upskill, Don't Isolate

Instead of opening requisitions for "AI Engineers," the first and most effective action is to invest in upskilling your current team and developing real authority. A strategic training program can build the necessary competencies within the engineering talent you already have. Key focus areas for this training should include:

1. Data Literacy: Engineers building with LLMs must understand the fundamentals of data pipelines, data quality, and the potential for bias in datasets. This knowledge is crucial for debugging and for understanding the root causes of model drift.
2. Applied ML Concepts: The goal is not to turn every software engineer into an ML research scientist. Rather, the focus should be on the practical application of existing models. This includes understanding the trade-offs of fine-tuning, the architecture of Retrieval-Augmented Generation (RAG) systems, and the techniques for evaluating model outputs.
3. Prompt Engineering as a Technical Discipline: Treat prompt engineering not as a soft skill but as a technical craft to be learned and refined. This involves training on techniques for creating clear, effective, and secure prompts.

This upskilling is best achieved through a combination of formal training, internal mentorship from early adopters, and, most importantly, hands-on experience with small, well-defined pilot projects.

Elevate the Senior Engineer's Role

In this new paradigm, the role of the senior, staff, or principal engineer becomes more critical than ever. AI tools are not just "augmenting" them to code faster; they are fundamentally shifting their responsibilities. The primary function of a senior engineer is to be the skeptical human in the loop, providing the critical judgment, architectural oversight, and deep system knowledge that AI models lack.

Their focus must elevate from writing code to:

• Architectural Guardianship: Designing systems that are inherently resilient to the probabilistic failure modes of their AI components.
• Critical Review: Meticulously scrutinizing AI-generated code, not just for correctness, but for the subtle bugs, security flaws, performance issues, and maintainability problems that models cannot yet reason about.
• Mentorship and Governance: Establishing the best practices, guardrails, and review processes that allow the rest of the team to use AI tools safely and effectively.

Adapt Your Processes

Finally, these cultural and skill-based shifts must be reinforced by process changes:

• Mandate Version Control: Establish a clear policy that all production-facing AI assets, including prompts and evaluation datasets, must live in a version-controlled system, whether that is Git or a specialized platform like TextAgent.dev.
• Update the Definition of "Done": For any feature that incorporates an LLM, the definition of "done" must be expanded. It must include not only functional code and deterministic tests but also a robust probabilistic evaluation suite, a comprehensive observability plan (including drift monitoring), and a security review against the OWASP LLM Top 10.
• Start Small and Measure: Begin with contained pilot projects to build institutional knowledge and measure the true ROI of AI initiatives before attempting to scale them across the entire organization.

Conclusion: The Engineer is Dead, Long Live the Engineer

The industry's current fascination with the "AI Engineer" title is a dangerous distraction. It encourages leaders to pursue a flawed strategy of building isolated, specialized teams, leading them away from the very practices that ensure software quality and reliability. The real work of building the next generation of intelligent applications will not be done by a new priesthood of AI specialists. It will be done by applying the disciplined, rigorous craft of software engineering to a new, powerful, and admittedly chaotic class of tool.

The future does not belong to siloed teams. It belongs to integrated, cross-functional teams of software engineers who have mastered this new tool while remaining grounded in the foundational principles of their profession. Resisting the pressure to create organizational silos and instead investing in the engineering excellence of your existing teams is the most robust, scalable, and defensible strategy for success. The title of Software Engineer is not becoming obsolete; in the age of AI, it is becoming more vital than ever.

Supporting Articles for Further Reading

1. Martin Fowler - Exploring Generative AI : An essential and evolving collection of articles from one of software engineering's most respected thinkers on the practical realities, challenges, and opportunities of working with LLMs. ( https://martinfowler.com/articles/exploring-gen-ai.html )
2. OWASP Top 10 for Large Language Model Applications : The definitive, authoritative guide to the new security threat landscape introduced by LLMs. This is required reading for any engineering leader building AI-powered applications. ( https://www.cloudflare.com/learning/ai/owasp-top-10-risks-for-llms/ )
3. Gartner - The 2025 Hype Cycle for Artificial Intelligence : This report provides a valuable macro view of the industry, helping leaders understand how concepts like "AI Engineering" and "ModelOps" are maturing from initial hype toward productive, mainstream application. ( https://www.gartner.com/en/articles/hype-cycle-for-artificial-intelligence )
4. Unlocking SEO Success in 2025: The Truth About AI Content and Google Ranks : Dive deep into the latest analysis of AI-generated content and its impact on search visibility. ( https://www.textagent.dev/blog/unlocking-seo-success-in-2025-the-truth-about-ai-content-and-google-ranks )
5. Content Duplication Solutions: Improve SEO and Crawl Efficiency 2025 : Learn how to identify, manage, and prevent duplicate content to keep your site healthy and authoritative. ( https://www.textagent.dev/blog/content-duplication-solutions-improve-seo-and-crawl-efficiency-2025 )
6. Mastering GEO: The New Strategic Imperative in AI Search : Prepare your digital strategy for the future with practical GEO tactics for AI-powered search. ( https://www.textagent.dev/blog/mastering-geo-the-new-strategic-imperative-in-ai-search )

 

About Text Agent

At Text Agent, we empower content and site managers to streamline every aspect of blog creation and optimization. From AI-powered writing and image generation to automated publishing and SEO tracking, Text Agent unifies your entire content workflow across multiple websites. Whether you manage a single brand or dozens of client sites, Text Agent helps you create, process, and publish smarter, faster, and with complete visibility.

About the Author

Bryan Reynolds is the founder of Text Agent, a platform designed to revolutionize how teams create, process, and manage content across multiple websites. With over 25 years of experience in software development and technology leadership, Bryan has built tools that help organizations automate workflows, modernize operations, and leverage AI to drive smarter digital strategies.

His expertise spans custom software development, cloud infrastructure, and artificial intelligence—all reflected in the innovation behind Text Agent. Through this platform, Bryan continues his mission to help marketing teams, agencies, and business owners simplify complex content workflows through automation and intelligent design.