Table of Contents
1. The Origin Story: GE, UNIVAC, and Andersen Consulting
In the early 1950s, General Electric's Appliance Park plant in Louisville, Kentucky was drowning in paperwork. Payroll and inventory for a plant of that size were being run by rooms full of clerks, ledgers, and punch-card tabulating machines — a process that was slow, error-prone, and getting more expensive every year as the plant grew. GE wanted to know whether one of the new electronic computers being built at the time — a UNIVAC I, the first commercially produced computer in the United States — could actually replace that paperwork process and run the plant's payroll and inventory instead.
GE didn't have people who knew how to answer that question, because almost nobody did yet — commercial computing barely existed. So they brought in outside help: the team that would eventually become Andersen Consulting (the consulting arm of the accounting firm Arthur Andersen & Co., renamed Accenture decades later) to figure out, from scratch, whether this was even feasible, and if so, how to actually build it.
What that engagement produced is widely regarded as the first large-scale commercial software/business-systems project ever delivered — a computer doing real payroll and inventory work for a real factory, not a research demo. And notably, the team building it didn't just start writing code. They worked through a sequence of steps that, seventy-plus years and several complete generations of technology later, is still exactly how large software projects get built today.
2. The Ten Phases of a Software Project
Strip away the specific technology of any era — punch cards, mainframes, client-server, the web, the cloud, or Agentic AI — and every large software project still passes through the same ten phases, in roughly the same order. This is the sequence the GE/Andersen team followed in the 1950s, and it's the sequence a well-run project follows today.
1. Understand the business problem
2. Gather requirements for the software to be built
3. Create the high-level design
4. Create the technical specifications
5. Build the software from the technical specs
6. Code review
7. Unit testing → fix unit defects
8. Integration testing → fix integration defects
9. User Acceptance Testing (UAT) → fix UAT defects
10. Deploy to production and monitor for issues3. Walking Through Each Phase
| # | Phase | What it actually means |
|---|---|---|
| 1 | Understand the business problem | Before anyone talks about software, someone has to be able to state, in plain language, what is actually broken or missing. For GE, the problem wasn't "we need a computer" — it was "payroll and inventory processing is too slow and too error-prone to keep up with the plant." Get this wrong, and every later phase inherits the mistake. |
| 2 | Gather requirements | Translate the business problem into a concrete list of what the software must do: what data it consumes, what calculations it performs, what output it produces, and under what rules. This is where "process payroll faster" becomes specific, checkable statements a builder can work from. |
| 3 | High-level design | Decide the overall shape of the solution before writing anything — what major components exist, how data flows between them, what the system's boundaries are. For GE/UNIVAC this meant deciding how payroll data, inventory data, and the computer's processing steps would fit together end to end. |
| 4 | Technical specifications | Turn the high-level design into a level of detail precise enough to actually build from — exact data layouts, exact processing logic, exact edge cases. This is the bridge between "here's the shape of the solution" and "here's what to actually type." |
| 5 | Build the software | Write the actual program from the technical specs. In 1953 this meant machine-level and early assembly-style programming for the UNIVAC I; today it means whatever language and framework fit the job — but the activity is the same: turning a spec into working code. |
| 6 | Code review | Someone other than the builder checks the work against the spec and against sound engineering practice before it moves forward — catching mistakes while they're still cheap to fix. |
| 7 | Unit testing / fix defects | Test each piece of the software in isolation against what it's supposed to do, and fix whatever it gets wrong. This phase is never "run once" — build, test, fix, retest is the loop until the unit is solid. |
| 8 | Integration testing / fix defects | Individually correct pieces still have to work correctly together. Integration testing checks the seams — where payroll logic meets inventory logic meets the data store — and the same fix-and-retest loop applies. |
| 9 | User Acceptance Testing / fix defects | The people who will actually rely on the system — GE's payroll and plant staff, in the original story — test it against real-world use, not just the spec. UAT catches the gap between "technically correct" and "actually usable," and defects found here get fixed before go-live. |
| 10 | Deploy and monitor | Put the system into production and watch it closely for issues that only show up under real load and real data — because no amount of prior testing perfectly predicts production. |
4. Seventy Years Later: Same Ten Phases, Every Time
Since that GE/UNIVAC project, software engineering has been through mainframes, minicomputers, PCs, client-server architecture, the internet and the web, mobile, cloud computing, microservices, DevOps, and now Agentic AI. Methodologies have been renamed and rearranged more times than anyone can count — waterfall, iterative, spiral, RUP, Agile, Scrum, Kanban, DevOps, and now "AI SDLC." Each one changes the packaging: how the ten phases are scheduled, how much overlap there is between them, how quickly you loop back to an earlier phase.
None of them removed a phase, and none of them added a genuinely new one. Every methodology still has to answer: what's the business problem, what are the requirements, what's the design, what's the spec, who builds it, who reviews it, how is it tested at three different levels, and how is it deployed and watched afterward. That is the actual, durable shape of software engineering — and it is exactly as true for a UNIVAC I payroll system in 1953 as it is for a cloud-native application built with an AI coding agent in 2026.
5. Enter Agentic AI: A New Layer, Not a New Shape
Agentic AI's real contribution is that every one of the ten phases can now be performed — partly or fully — by an AI agent instead of, or alongside, a human doing it by hand. That's genuinely new. What is not new is the list of phases itself. The table below maps each phase to what changes with Agentic AI in the loop, and — since this is a series about evals — what has to be true for you to actually trust that an agent did that phase well.
| # | Phase | With Agentic AI | What an eval has to check |
|---|---|---|---|
| 1 | Business problem | An agent can summarize stakeholder input, prior tickets, and documentation into a candidate problem statement. | Does the statement match what stakeholders actually meant, not just a plausible-sounding paraphrase? |
| 2 | Requirements | An agent can draft structured requirements from meeting notes, tickets, or a business description. | Are the requirements complete, unambiguous, and traceable back to the real business problem? |
| 3 | High-level design | An agent can propose an architecture and component breakdown from the requirements. | Does the design actually satisfy every requirement, and is it consistent with real system constraints? |
| 4 | Technical specs | An agent can expand a design into detailed specs — data shapes, interfaces, edge cases. | Are the specs precise enough to build from without silently dropped edge cases? |
| 5 | Build the software | A coding agent writes the implementation directly from the technical spec. | Does the generated code actually implement the spec — the core question the rest of this series is built around. |
| 6 | Code review | An agent can review a diff for bugs, style, and spec conformance before a human ever looks at it. | Does the review catch the same class of issues a senior engineer would — and catch them consistently, not just sometimes? |
| 7 | Unit testing | An agent can generate and run unit tests, and propose fixes for failures. | Do the generated tests actually exercise the requirement, or just exercise the code as written (and thus rubber-stamp bugs)? |
| 8 | Integration testing | An agent can generate cross-component test scenarios and diagnose failures at the seams. | Are the real integration risks covered, or only the easy, obvious paths? |
| 9 | UAT | An agent can simulate user workflows and flag likely usability or business-logic gaps before real users do. | Does it catch what real users would actually hit, including the business intent a spec might have missed? |
| 10 | Deploy & monitor | An agent can watch logs and metrics post-deploy and flag anomalies or propose rollbacks. | Does it flag real incidents promptly, without drowning the team in false positives? |
Notice the pattern in that last column: every single phase gets a new failure mode the moment an agent — not a human — performs it, because (as Chapter 1 covers) an LLM's output is a sample from a probability distribution, not a guaranteed-correct fact. That's precisely why "just add Agentic AI" to any of these ten phases without a proper eval framework is how a team quietly trades a slow, human-verified process for a fast, unverified one — and doesn't find out until production.
6. What the Business Actually Cares About
Step back from all ten phases and all seventy years, and the business sponsor paying for the project — in 1953 or today — has never actually cared about the phases themselves. Phases are how engineers manage the work. The business has only ever judged the result on three things:
High Quality
Software that correctly does what the business needed, with few defects reaching production.
Shortest Time to Production
Delivered as fast as possible, so the business benefit starts landing sooner rather than later.
Least Cost
Built for the lowest total cost that still meets the quality and time bar.
This is the classic "iron triangle" of delivery — quality, speed, cost — and it was just as true for GE deciding whether a UNIVAC I was worth the money in 1953 as it is for any executive signing off on an AI-assisted engineering budget today.
7. Conclusion: The Only Reason to Use Agentic AI
Put the whole chapter together and the conclusion is straightforward:
- The core steps of software engineering — the same ten phases followed on the first large commercial software project ever built, for GE, by the team that became Andersen Consulting, in the early 1950s — have not changed in over seventy years.
- Agentic AI does not replace those phases or add new ones. It adds a layer on top of the existing SDLC — call it the AI SDLC — where an agent can perform some or all of the work in any given phase.
- The business, at the end of the day, is still only judging the outcome on three things: quality, speed, and cost. That has not changed either.
- Therefore, the only legitimate reason to introduce Agentic AI into any of these ten phases is that it measurably improves one or more of those three things — better quality, faster delivery, lower cost — without silently sacrificing the others. An agent that writes code faster but ships more defects hasn't helped. An agent that improves quality but requires more human cleanup than it saves hasn't helped either.
- Which is exactly why a rigorous eval framework isn't optional decoration on top of Agentic AI — it's the only mechanism that tells you whether the AI layer is actually moving those three needles, or just moving the work around. That is the problem the rest of this series is built to solve.
Everything from here — agent basics, golden datasets, scorecards, Goodhart's Law, failure modes, and a full LangSmith pipeline — is in service of one question: is the Agentic AI layer we've added actually making our software better, faster, and cheaper to deliver? If it isn't, it isn't worth having, no matter how impressive the demo looks.
With the shape of the problem established, the series turns next to the foundation everything else builds on: why an AI agent's output — unlike a traditional program's — can't be assumed to be the same twice. — continue to Chapter 1: How LLMs Work, and Why They're Not Consistent →
8. Glossary
| Term | Meaning |
|---|---|
| UNIVAC I | The first computer commercially produced in the United States; GE's Appliance Park plant was among the first non-government sites to use one for real business processing (payroll and inventory), starting in the early-to-mid 1950s. |
| Andersen Consulting | The consulting arm of accounting firm Arthur Andersen & Co., whose engagement with GE on the UNIVAC I payroll/inventory project is widely cited as the origin of large-scale commercial software consulting; renamed Accenture in 2001. |
| SDLC | Software Development Life Cycle — the standard sequence of phases (problem, requirements, design, spec, build, review, test levels, deploy) a software project moves through. |
| AI SDLC | The same SDLC phases, with one or more phases performed partly or fully by an Agentic AI system rather than only by humans. |
| High-level design | The phase that defines a system's major components and how data flows between them, before technical specifications are written. |
| Technical specification | A build-ready level of detail — exact data structures, logic, and edge cases — derived from the high-level design. |
| UAT (User Acceptance Testing) | Testing performed by the actual intended users of a system, checking real-world usability and business fit rather than just spec conformance. |
| Iron triangle | The classic project-delivery trade-off between quality, speed (time to delivery), and cost — the three things a business sponsor ultimately judges a software project on. |
| Eval framework | A structured, repeatable way of measuring whether an AI agent's output at a given SDLC phase is actually correct and reliable — the subject of the rest of this series. |