From Assembly to C, from Code to Spec — AI-DLC and Robo Architect
1. "Can we trust the compiler?"
In the 1970s, when C began to be used for operating systems (Unix) and systems programming, veteran assembly programmers pushed back hard.
- "A compiler can never match human optimization." In assembly, people controlled every register and every clock cycle. Machine code produced by a compiler was criticized as bloated, full of needless branches.
- "To debug, you still have to know assembly." When a program crashed, you had to dig through memory dumps and assembly. So, the argument went, a developer who only knew C was only half a developer.
- "We will lose control of the hardware." Fine-grained timing at specific addresses and hardware interrupts, they said, could not be handled in C.
We know what happened next. As compiler optimization improved, more and more compiled code beat hand-written assembly. As hardware got faster, development speed and portability came to matter far more than a few percent of performance. Assembly did not disappear, but it retreated to specialized niches such as bootloaders, kernel initialization and real-time embedded chips. The rest of the industry moved to C and higher-level languages.
2. Fifty years later, the same debate
The debate over AI coding (vibe coding) today is strikingly similar. The only difference is that what people work with directly has moved one more level of abstraction up.
| Category | 1970s–80s (assembly → C) | Today (hand coding → AI) |
|---|---|---|
| What people write | Registers and instructions → syntax and functions | Syntax, functions and logic → natural-language specs and prompts |
| The critics | "If you don't know assembly, you can't catch memory leaks and slowdowns." | "If you don't check AI-written code line by line, something will break." |
| The optimists | "Just write the structure and design in C, and the compiler takes care of the rest." | "As long as the input/output spec and the tests are precise, the internals don't matter." |
The story is likely to play out the same way. As AI-generated code gets better and automated testing and static analysis get sharper, reading code line by line becomes too expensive to sustain. System cores, security reviews and high-performance tuning will still need code-level verification. But for most business-system development, the center of gravity will shift.
The old question "Do you have to work in assembly to be a real engineer?" has come back in new clothes: "Do you have to type and read every line of code to be a real developer?"
3. The spec is now the source code
In the C era, people wrote C and trusted the compiler. That trust was earned through verification and testing. Spec-driven development (SDD) works on the same principle. People decide what to build in a spec. AI turns it into code, and the result is checked through automated tests and stage-by-stage verification.
| The C era | Spec-driven development | |
|---|---|---|
| What people write | C code | Requirements, acceptance criteria, design decisions |
| What translates it | Compiler | AI Agents |
| Why we trust it | Compiler verification and testing | Automated tests, verification gates, records of human approval |
| Where lower-level work remains | Bootloaders, kernel initialization | Security reviews, high-performance tuning, system cores |
Here is how it connects, using a single sentence. In the parking-pass booking app we built with AI-DLC, one sentence from the original request became an acceptance criterion and then, directly, test code.
.isEqualTo(new ParsedQuery("강남역", 2));
No one read this code line by line. People set the spec and checked the result with 886 tests and a per-target verdict table.
Once the spec is the source code, the questions change. "Who wrote the code?" matters less than "How do we define the spec, where do we keep it, and how do we keep it in sync with the code?" There is more than one answer. Let's compare two of them.
4. Two ways to work with specs: AI-DLC and Robo Architect
AI-DLC (AI-Driven Development Life Cycle) is an open-source methodology and toolset published by AWS Labs. Installed into a coding agent such as Claude Code, it walks the agent through intent → requirements → design → units → build → test, stage by stage. At each stage it asks people questions and gets the documents it wrote approved. Every decision goes into an audit log, and the spec accumulates in the repository as Markdown documents.
Robo Architect is uEngine's design tool. It breaks requirements into Epic → Feature → User Story and uses DDD to set business boundaries (bounded contexts). Commands, events and screens are managed as one design model. Code and tests are generated from that model, and when developers change the code, the change flows back into the model.
Use the links in the table to jump straight to the matching chapter of each tutorial and compare how the two handle the same job.
| AI-DLC | Robo Architect | |
|---|---|---|
| Where the spec lives | Stage-by-stage Markdown documents (requirements, stories, design, units, bolt plan), stored in Git alongside the code. ↗ Tutorial: Browse the artifacts (Korean) | A design model (bounded contexts, aggregates, commands, events, screens) that you view and edit as a graph. ↗ See it on the product page · ↗ Tutorial ch. 8 |
| How work proceeds | Out of 33 stages, only those that fit the nature of the work (the scope) run, in order. Each stage goes question → document → AI review → human approval. ↗ Tutorial ch. 9 (Korean) | Per proposal: intent → plan → build → verify → accept. You choose a decomposition mode (Simplified, Detailed DDD, ODA Standard). ↗ See it on the product page · ↗ Tutorial ch. 3 |
| The human role | Approve or request changes at every stage. Questions, answers and approvals are kept in the audit log with timestamps. ↗ Tutorial ch. 12 (change requests, Korean) · ch. 8 (audit log, Korean) | Preview model changes and confirm them. Edit boundaries and relationships directly on screen. ↗ Tutorial ch. 5 (confirming the Plan) |
| Spec and code | One direction, documents → code. A traceability file links each acceptance criterion to implementation and test files. ↗ Tutorial ch. 15 (Korean) | Both directions. Spec changes flow into the implementation (Spec Align), and code changes flow back into the spec (Spec Backfill). ↗ See it on the product page · ↗ Tutorial ch. 9 · ch. 7 |
| Screen design | Screen states and interactions are written up as documents. ↗ Tutorial ch. 11 (Korean) | Screens are designed together with the event model they connect to. ↗ See it on the product page · ↗ Tutorial ch. 8 (design canvas) |
| Existing systems | A reverse-engineering stage reads the existing code before starting. | Robo Analyzer extracts business rules from code, databases and documents and links them to the model. ↗ Tutorial ch. 13 |
| Best fit | Teams that want to follow a defined process and keep an approval record | Complex business boundaries, where you need to see the design and keep it aligned with the code |
The two tools complement each other more than they compete. AI-DLC is strong on process: in what order to ask, and who approves. Robo Architect is strong on the model: what the spec is made of, and how it connects to the code.
5. Where the human role is moving
Programmers did not disappear when compilers arrived. Instead of counting registers, they started thinking about algorithms and structure. The same is happening with AI. The hands-on work goes to AI, and people spend their time on judgment. In our hands-on run, too, AI finished each stage in a few minutes. Where people spent their time was reviewing and deciding.
| Role | Where time went until now | Where to focus from now on |
|---|---|---|
| Planner / PO | Writing requirements documents | Writing acceptance criteria that tests can check, and removing ambiguity by answering the AI's questions |
| Architect | Writing design documents, code review | Setting business boundaries and the agreements (contracts) between services, and deciding which AI review findings to accept |
| Developer | Writing code | Supervising the AI as it turns specs into code, designing verification, and writing code in areas that need deep expertise such as security and performance |
| QA | Running tests | Designing automated tests and pass criteria, and judging when not to lower the bar |
| Team lead / PM | Scheduling and assigning work | Deciding who approves what, and cutting the time spent waiting for human approval |
Different roles, but the focus comes down to three things.
- Spec: The ability to decide clearly what to build. Requirements, acceptance criteria and business boundaries belong here.
- Verification: The ability to design the grounds for trusting what AI produces. Automated tests, pass criteria and stage-by-stage verification gates belong here.
- Approval and accountability: A system that records who approved what, and when. Named approvers, review standards and decision records belong here.
How teams are built and how they work will change too. Teams that handed work down the line — planning → design → development → testing — become small teams where people from different roles verify the same spec at the same time. AI-DLC calls this Mob Elaboration.
If skill in the assembly era meant knowing the registers, skill in the AI era means writing precise specs and knowing how to verify them.
6. Closing: making the shift as a team
Installing a tool does not complete this shift. Teams need to build the habit of writing specs, learn how to design verification, and agree on approval rules together. uEngine's AX School starts with open courses anyone can follow. Once you have learned the method from them, it continues into workshops and consulting training built around your company's real work. Where to start depends on your role.
- Planner / PO: AI Planning & Design Tools Lab → AI-DLC Level 1 (requirements chapter) → Agent Storming Workshop
- Dev lead / architect: AI-DLC Level 1 → Level 2 (team rules, design · units · bolts, TDD build) → Defining your team rules
- Executives / transformation leads: AX Transformation Consulting Training → AI Work Class for Your Company
The full paths are in AX School: Who starts where (Korean). Programs and schedules are set through consultation. If you want to think through how your team's roles should change, reach out via Contact Us.
If you want to try it on your own first, start with the Claude Code × AI-DLC Hands-On (Korean; the C story from this post is in chapter 2), the GitHub repository of hands-on artifacts, or the Robo Architect tutorial.
References
- awslabs/aidlc-workflows — the official AI-DLC repository
- Claude Code × AI-DLC Hands-On, chapter 2 · Spec-driven development and verification gates (Korean)
- uengine-oss/tutorial-aidlc-handson — hands-on artifact repository
- What Is Spec-Driven Development? Tools and Specs — re:cinq
- Robo Architect tutorial