Skip to content
AI Agents Execute Full Engineering Chain: Will Software Engineers Be Replaced?

AI Agents Execute Full Engineering Chain: Will Software Engineers Be Replaced?

An experiment using AI Agents to perform requirements, design, coding, and testing on a 3D printer firmware project shows Agents can handle multi-stage engineering tasks, but human judgment, review, and verification remain essential, shifting engineers toward system thinking, specification, and quality assurance rather than replacement.

Software Engineering 3.0 Era
Software Engineering 3.0 Era
Software Engineering 3.0 Era

Experiment: AI Agent Executes Full Engineering Chain on 3D Printer Firmware

The author conducted an experiment using OpenCode and a large language model to drive an AI Agent through a relatively complete engineering workflow on the open-source Marlin 3D printer firmware. Starting from a 21-page user requirements PDF, the Agent progressed through seven stages: requirements engineering, specification decomposition, multi-round requirements review and revision, system design, design review and revision, component implementation with Unit Test Driven Development (UTDD), and code review.

Engineering chain overview
Engineering chain overview

Requirements Engineering and Specification Decomposition

The Agent extracted 186 source requirements from the raw document, analyzed, categorized, and merged them into 188 system leaf requirements with 12 top-level aggregated views. It further decomposed these into 130 software requirements, 49 hardware requirements, and 53 hardware-software interface contracts (HSI), plus 9 key behavioral contracts and 62 verification scenarios. This was not mere splitting; the Agent had to understand system functions, operational scenarios, identify hardware-software boundaries, clarify interface relationships, and transform descriptive user needs into clear, traceable, verifiable engineering specifications.

Partial requirements work summary
Partial requirements work summary

Multi-Round Requirements Review and Revision

An independent review process was introduced. The first review uncovered 16 major issues, 13 minor issues, and 4 improvement suggestions. After revision, a second review found 5 new issues. After subsequent revisions and re-checks, the requirements specification reached v1.0. Traceability achieved 100% coverage: all 128 M-level requirements mapped to verification scenarios, and all 9 specialized requirements for environment, EMC, and safety had corresponding scenarios.

Full traceability matrix (partial)
Full traceability matrix (partial)

System Design and Design Review

Based on the frozen requirements, the Agent produced 230 structured design elements: 21 architectural designs, 53 component definitions, 23 data structure designs, 13 data flow designs, 8 state machine designs, 11 timing designs, 19 algorithm designs, 72 interface designs, and 10 configuration designs. Independent design review revealed 10 issues (1 critical, 4 major, 5 minor). After revision and a second review, all 10 issues were closed with no new issues. One critical issue involved a reversed condition in temperature protection logic — an error that could have propagated into code as a real defect without professional review.

Partial design work summary
Partial design work summary

Component Implementation, UTDD, and Code Review

Seven components of the motion subsystem (Motion, Planner, Bezier, Stepper, Endstops, Kinematics, FtMotion) were implemented using UTDD: test cases were designed from design contracts first, then the Agent implemented code to satisfy them. The Motion component alone generated ~3,700 lines across 33 files (8 source, 12 header, 10 test). Tests covered five kinematic configurations (Cartesian, CoreXY, SCARA, Polar, Delta), each executing 79 or 80 test cases — all passed. Overall line coverage reached 96.86%, branch coverage 71.36%; core components (Motion, Planner, Stepper) achieved line coverage 95.68%–99.01% and branch coverage 70.00%–83.33%. Code review against design contracts resulted in a conditional pass with 2 major issues, 3 minor issues, and 4 suggestions, no critical or blocking issues. The author notes this was a self-contained implementation with native unit tests, not including ISR real-time or real-hardware concurrency verification.

Motion component implementation directory structure
Motion component implementation directory structure

Three Key Observations from the Practice

Scale of engineering artifacts and need for structure/verification: The experiment produced 188 system requirements, 130 software requirements, 53 interface contracts, 62 verification scenarios, and 230 design elements. While Agents can automate extraction, decomposition, numbering, linking, and updating, quantity does not guarantee quality. Complete traceability does not ensure semantic correctness. Without explicit structure, relationships, and verification mechanisms, Agents merely generate inconsistent documents and code faster.

Multi-round review and revision outweigh single-pass generation: Both requirements and design phases underwent independent review, issue logging, item-by-item revision, and re-review. The temperature protection logic error demonstrates that Agent output can be structurally complete and professionally phrased yet contain substantive engineering flaws. This aligns with traditional software quality principles: quality is built through incremental review, verification, and correction, not by a final inspection. Agent speed must not lower engineering review standards.

UTDD provides concrete constraints for Agent implementation: Getting an Agent to write code is easy; getting it to produce behaviorally correct, verifiable code per design is hard. UTDD makes test cases participate from the start: design contracts supply implementation basis, test cases supply behavioral constraints, test results and coverage supply verification evidence. This forces the Agent to work within explicit engineering constraints and continuously correct via test feedback rather than guessing from natural language. As Agent execution speed increases, the importance of testing, review, and quality gates only grows; otherwise, faster code generation translates into larger defect investigation and rework costs.

Will Software Engineers Be Replaced?

The author distinguishes task replacement from role replacement . Many daily tasks — routine coding, simple feature changes, interface documentation, initial test generation, repetitive bug fixes, basic code checks — have clear boundaries and verifiable outputs. These will increasingly be automated, reducing human effort and altering team composition. However, software engineering is more than executing defined coding tasks. Real projects involve incomplete requirements, conflicting business goals, evolving constraints, architectural trade-offs across performance, cost, reliability, security, maintainability, complex fault analysis requiring business context and historical experience, and high-reliability domains demanding safety responsibility, compliance, and delivery decisions. These require understanding problems, identifying risks, weighing alternatives, and owning decisions. Agents can provide analysis and execute substantial portions, but final engineering judgment and accountability cannot be substituted by code generation or test passes alone. In automotive, aerospace, energy, industrial control, software quality directly impacts safety. Engineers must judge specification adequacy, design soundness, verification sufficiency, and release readiness — responsibilities that do not vanish because an Agent is used. Therefore, replacement pressure falls on roles centered on highly repetitive, low-judgment, standardized manual tasks. Engineers who understand complex business, master system architecture, manage engineering risk, orchestrate Agent collaboration, and own quality outcomes will see their value increase.

Five Essential Skills for Future Engineers

Systems thinking: Beyond understanding a function or module, grasp business objectives, system boundaries, architectural relationships, functional dependencies, runtime environments, and the impact of local changes on the whole system.

Requirements and specification capability: Transform vague business goals into clear, complete, verifiable engineering requirements — defining what the system must do, its constraints, prohibited behaviors, and acceptance criteria. This becomes the foundation for directing Agent work.

Engineering organization and Agent collaboration: Decompose engineering tasks appropriately, provide Agents with context, knowledge, tools, and permissions, orchestrate multiple Agents, and establish execution constraints and feedback loops.

Quality assurance and verification: Do not blindly trust Agent outputs; design review mechanisms, test strategies, and quality gates to assess correctness, completeness, consistency, and sufficiency of verification evidence.

Professional judgment and responsibility: Make technical decisions in complex, uncertain scenarios, identify key risks, and own system safety, quality, and delivery outcomes.

Junior Engineer Challenge

Traditionally, engineers grew from simple coding, bug fixing, and test writing — tasks now most susceptible to automation. If companies pursue short-term efficiency by drastically cutting junior positions, the pipeline for future senior engineers may erode. Organizations must redesign career paths: let newcomers participate in real engineering activities assisted by Agents, learning requirements analysis, design, review, testing, and quality judgment, rather than merely presenting Agent-generated code as their own work.

Conclusion: Paradigm Shift to Software Engineering 3.0

The author frames the evolution: Software Engineering 1.0 (traditional, process discipline), 2.0 (Agile, CI/CD, DevOps, rapid iteration), and now 3.0 — AI/Agent-driven intelligent software engineering. The core logic of this new paradigm: Specification as core, Agent as execution main body, human as decision and judgment, verification evidence as quality basis. The Marlin firmware practice is an exploratory case; scalable, autonomous, trustworthy end-to-end engineering delivery still faces unsolved problems. Yet it shows Agents are moving from coding assistants into core software engineering activities. The future differentiator for engineers will not be lines of code per day, but the ability to understand complex systems, define the right problems, organize Agents to execute engineering tasks, and provide reliable evidence that results are trustworthy. What gets replaced is not the software engineer profession, but the automatable work patterns and the role value built solely on those patterns.

Software Engineering 3.0 paradigm
Software Engineering 3.0 paradigm
Original Source

Signed-in readers can open the original source through BestHub's protected redirect.

Sign in to view source
Republication Notice

This article has been distilled and summarized from source material, then republished for learning and reference. If you believe it infringes your rights, please contactadmin@besthub.devand we will review it promptly.

AI Agentssoftware engineeringSystem DesignCode ReviewRequirements EngineeringEngineering AutomationSoftware Engineer RolesUnit Test Driven Development
Reader feedback

How this landed with the community

Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.