Software Engineering-Based Agentic Coding
- June Park
- Jun 2
- 12 min read
Updated: Jun 9
SW Engineering: A Historical Overview
Software Engineering began to develop in earnest in the late 1960s, primarily in the United States and Europe. IBM’s OS/360 development project for the System/360 in the 1960s suffered severe schedule delays and cost overruns, while U.S. defense and large-scale public sector projects of the era similarly encountered repeated delivery failures and quality problems. At the 1968 NATO Software Engineering Conference in Garmisch, Germany, the international community formally declared a Software Crisis and launched research and development into software engineering as its solution.
What distinguished software engineering from pre-1960s development practices was its emphasis on systematic analysis and design prior to system implementation, as well as the use of standardized processes, methods, and tools throughout the entire development lifecycle.
Requirements analysis reduces rework caused by requirements errors by clarifying development specifications up front. Clear acceptance criteria provide the foundation for test automation, and automated regression tests in turn provide a safety net for continuous code refactoring.
System design encompasses both architecture-level design and detailed code-level design. Architectural design improves the integration efficiency among the components of a system. Detailed design and code structure design enhance code readability and modifiability, thereby ensuring the long-term maintainability of the software.
To eliminate the ambiguity that arises when requirements specifications and software designs are expressed in natural language, the industry has established visual modeling notations — such as UML (Unified Modeling Language), BPMN (Business Process Model and Notation), ERD (Entity-Relationship Diagram), ArchiMate, and C4 — as international and industry standards.
Software engineering remains as relevant as ever in today’s era of AI coding agents. Even when AI generates the code, the quality and maintainability of large-scale production systems ultimately depend on disciplined software engineering practice. What we need is software engineering-based agentic coding.
A History of Software Coding Automation
Coding automation technology began its full-scale development in the 1980s. In the late 1980s, Texas Instruments developed IEF (Information Engineering Facility), a CASE (Computer-Assisted Software Engineering) tool that automatically generated 100% of mainframe COBOL code and was used to auto-generate code for large-scale enterprise systems in the financial and public sectors. The 1990s saw the emergence of a variety of model-based CASE tools — including Composer, Obsydian, and ObjectTeam — capable of automatically generating Unix C, Windows C++, and Java code. However, from the late 1990s onward, CASE tools fell out of favor due to their limited flexibility in accommodating changing requirements and the burden of complex modeling.
The 2000s brought a new software development paradigm: iterative and incremental development of web applications using object-oriented programming languages. MDA (Model-Driven Architecture) tools, which pursued 100% automatic code generation from UML models, were developed but failed to gain traction as a mainstream development approach. Instead, open-source web application frameworks such as Spring, Ruby on Rails, and Django came to dominate the development market. Meanwhile, visual modeling tools such as Rational Rose and Sparx EA (Enterprise Architect) were decoupled from code-generation tools, yet remained widely used for their support of code-skeleton generation and Round-Trip Engineering.
From the late 2010s onward, Low-Code development platforms — including OutSystems, Mendix, Appian, and Microsoft Power Apps — that automatically generate applications from visual models began to spread rapidly. (See: June Sung Park, Fundamentals of Low-Code Development, kosta-online.com) Around the same time, No-Code development platforms — such as Wix, Bubble, AppSheet, and Webflow — that assemble applications automatically through template-based visual drag-and-drop in a WYSIWYG (What You See Is What You Get) fashion also proliferated rapidly. In its 2022 report, Gartner forecast that the share of new enterprise applications built using Low-Code/No-Code (LCNC) platforms would rise from 25% in 2020 to approximately 75% by 2026. (Gartner, Forecast Analysis: Low-Code Development Technologies — Worldwide, 2022) By 2024, a significant number of enterprises had already adopted Low-Code development platforms, indicating that this trajectory was becoming a reality.
While AI coding agents are generating considerable excitement around coding automation today, as the history above makes clear, coding automation is not a new phenomenon. LCNC platforms have already been widely used to automatically build applications. Because they operated on top of standardized architectures, metadata models, and visual constraints that deliberately limited developer freedom, LCNC platforms were able to achieve both high productivity and stability simultaneously. Natural language-based AI coding agents, by contrast, offer far greater flexibility, but introduce new risks: hallucination and the breakdown of structural consistency.
For AI coding agents to move beyond LCNC and become the mainstream approach to enterprise production system development, software engineering constraints must be deeply embedded within the agent coding process itself. What we need is software engineering-based agentic coding.
The Emergence of GenAI-Based Coding Assistance and Automation
In the 2020s, Generative AI (GenAI)-based Vibe Coding, AI Coding Assistants, and AI Coding Agents have been spreading rapidly. Vibe Coding is an experimental development approach in which applications are quickly generated and refined through natural language prompts. When errors are found during testing, developers provide feedback in natural language and iterate toward improvement. It uses general-purpose AI chatbots such as Claude and ChatGPT, or dedicated Vibe Coding tools such as Lovable, Bolt.new, and Replit.
Most AI coding tools today combine Vibe Coding, AI Coding Assistant, and AI Coding Agent capabilities in a single product, and some are embedded directly within integrated development environments (IDEs). AI Coding Assistants — such as GitHub Copilot, Cursor, and Amazon Q Developer — are used to support developer productivity, offering features including code completion, code generation, refactoring, debugging, documentation, and code translation. AI Coding Agents — such as Cursor, Claude Code, and GitHub Copilot — interact with developers and semi-autonomously carry out tasks such as implementing system objectives, developing requirements, generating tests, fixing errors, improving designs, and producing documentation, all through a plan-execute-verify loop.
Vibe Coding has its limitations when it comes to building large-scale production systems. Table 1 compares the characteristics of AI Coding Assistants and Agents suitable for production system development against those of LCNC platforms.
The advantages AI Coding Agents hold over No-Code development platforms include the ability to design UIs more freely via prompts rather than by customizing templates, and to modify and assemble applications at the component level. Compared to Low-Code development platforms, AI Coding Agents free developers from the difficulties of visual modeling — enabling application and database generation through prompts or images — and avoid vendor lock-in to proprietary frameworks, generating code in standard open-source frameworks such as Next.js, Tailwind, and PostgreSQL that can be exported to an IDE-based development environment.
However, leading LCNC platforms are overcoming their own limitations by integrating AI Coding Assistant and Agent capabilities — built on GenAI foundation models — directly into their tools. AI Coding Assistant technology supports developers’ visual drag-and-drop and modeling work, while AI Coding Agent technology autonomously generates applications without any visual modeling.
When comparing market size based on Gartner and IDC data, the LCNC market still accounts for a significantly larger share than the AI coding tools market.
For AI coding agents to gain a competitive edge over LCNC development platforms, they must ultimately overcome the problem of non-deterministic output. Non-determinism and hallucination — whereby the same prompt can produce different results — undermine test reproducibility and the predictability of code changes, potentially degrading the stability of CI/CD pipelines. These phenomena also give rise to security risks, accumulation of technical debt, violations of copyright and regulatory requirements, and audit failures.
LCNC platforms achieved deterministic automation by restricting developer freedom through metadata, visual models, and platform constraints. AI coding agents, by contrast, use open-ended natural language generation, which offers far greater flexibility but simultaneously introduces the new risks of non-determinism and hallucination.
LCNC succeeded in automation through constraint. For AI coding agents to become the mainstream approach to enterprise production system development, they too must internalize software engineering constraints and governance. What we need is software engineering-based agentic coding.
Software Engineering-Based Agentic Coding
Eliminating hallucination and non-determinism in agentic coding requires the systematic application of software engineering constraints and automation mechanisms. (See: June Sung Park, AI Agent Coding Patterns, kosta-online.com)
Test-Driven Development
(TDD; see Kent Beck, Test-Driven Development, 2002)
The context file specifies that the agent must write test code before writing source code. A hook is installed to trigger automated tests immediately after any software change. Another hook is installed to block commits when test coverage falls below a defined threshold. The Red-Green-Refactoring TDD cycle is registered as a Skill and incorporated into the agent’s task planning. The Red, Green, and Refactoring phases are separated and assigned to distinct subagents.
Continuous Integration/Continuous Delivery
(CI/CD; see Kent Beck, Extreme Programming Explained, 2004; Martin Fowler, Continuous Integration, martinfowler.com, 2006; Jez Humble and David Farley, Continuous Delivery, 2010)
The CI/CD pipeline serves as a quality gate, providing bounded assurance in agentic coding, much like TDD. The pipeline validates probabilistic and potentially hallucination-prone GenAI-generated artifacts against requirements, acceptance criteria, architectural constraints, design rules, security policies, deployment policies, and operational requirements.
An agentic CI/CD pipeline is a semi-autonomous, self-correcting, closed-loop system that incorporates human-in-the-loop (HITL) controls. It acts as an evaluator, orchestrator, and governor of autonomous software delivery. To sandbox autonomous software behavior, it may isolate development, staging, and production agents.
Agentic CI automatically performs commits, builds, PR creation, unit and integration testing, static analysis, and security checks when merging a software change into the repository’s main branch. On failure, the agent blocks the merge, receives the stack trace as feedback, and self-corrects the error.
Agentic CI executes the CI pipeline using platforms such as GitHub Actions, Buildkite, and CircleCI and employs the AI coding agent to perform multiple steps within the pipeline — including code review, correction, and quality improvement. Operating Agentic CI under a Trunk-Based Development strategy ensures the main branch remains releasable at all times.
As with TDD, context files, hooks, skills, and subagents can be used in combination to detect and prevent CI failures early. Effective CI operation requires a high level of test automation, and TDD is the primary means of achieving this. The body of test code accumulated through TDD forms the foundation for automated unit and integration testing within the CI pipeline.
Typical CD verification gates include acceptance tests, security checks, architectural fitness functions, performance thresholds, policy compliance, human approval workflows, deployment-window controls, rollback readiness, and runtime quality indicators such as anomalous tool usage or unexpected token consumption.
Agentic CD typically supports progressive deployment strategies such as canary, blue-green, rolling, feature-flag, and shadow deployments. To avoid non-repeatable generation, it freezes, versions, signs, and maintains reproducible deployment artifacts, including containers, workflow graphs, prompts, model versions, agent configurations, and tool schemas.
Agentic CD depends heavily on observability. Its monitoring may include prompt traces, tool-call traces, agent decision logs, memory-access telemetry, workflow-execution graphs, and semantic error tracking. Automated rollback mechanisms may be triggered when the system detects problems such as degraded evaluation scores, workflow failures, anomalous token consumption, tool misuse, and business KPI degradation. In such cases, previously validated containers, prompts, workflows, and agent configurations can be restored automatically.
Requirements Engineering
(see June Sung Park, The Complete Guide to Business Analysis, kosta-online.com)
To achieve business outcomes when building AI-native applications that incorporate AI agents, the end-to-end process — including the agents themselves — must be reinvented. The domain concepts and semantic structures used in the application’s business domain must be clearly defined, and processes must be designed using standardized terminology. The more precisely the innovative features to be implemented are defined as use cases and elaborated into scenarios, the fewer implementation errors will arise from the requirements. (See: June Sung Park, Key Conditions for AI Agent Success, kosta-online.com)
This requirements analysis is performed upfront, before development begins with the AI coding agent. Process models can be designed using BPMN (Business Process Model and Notation), the international standard. While semantic models have traditionally been expressed as UML class diagrams, it can be effective to complement them with ontologies when working with AI coding agents. Because ontologies explicitly represent the relationships and constraints between concepts, they increase the likelihood that an AI coding agent will interpret domain semantics more accurately and generate consistent code.
Figure 1 illustrates the requirements analysis artifacts and their dependency relationships. Producing a consistent and complete requirements specification requires strict adherence to the interdependencies among the process model, the semantic model (Business Object Model), the use case model, the UX model, and the service model.
As noted earlier, after the emergence of software engineering in the 1970s, the industry developed modeling languages to precisely document requirements specifications and software designs, because natural language alone was too ambiguous even for human communication. The same principle applies to AI coding agents: they can process structured inputs more reliably than natural language prompts, including markup languages (Markdown, HTML, etc.), serialized languages (JSON, YAML, etc.), modeling and domain-specific languages (UML, BPMN, BDD, User Stories, Ontologies, etc.), and programming languages (Python, TypeScript, etc.).
When incorporating process models, semantic models, and use cases into the requirements specification for an AI coding agent, they can be provided as images or in text, or converted into User Stories and BDD (Behavior-Driven Development) Gherkin statements. BDD statements provide the acceptance test criteria for the generated code. (Dan North, Introducing BDD, dannorth.net, 2006)
These conversions can themselves be delegated to the AI coding agent. For example, a process model can be converted into a diagram DSL such as Mermaid.js before being provided to the agent. Ontologies can be serialized into JSON-LD or Turtle (.ttl) format for input. Once User Stories and BDD statements have been generated, a Business Analyst must review them for errors. Upon passing the analyst’s review, the agent writes code based on the User Stories and BDD statements.
As described in the TDD section above, test code must be written before source code; accordingly, the agent derives TDD test code from the User Stories and BDD statements. When a BDD framework, such as Cucumber, and an E2E testing framework, such as Playwright, are used to author BDD statements, the agent generates test code based on the Step Definition files. When no BDD tooling is used, the agent converts the BDD statements directly into TDD test code.
In this way, effective CI operation depends on TDD-based test automation; TDD, in turn, depends on BDD; and BDD is accurately derived through upfront requirements analysis — including process modeling, semantic modeling, and use case analysis. (Requirements Analysis → BDD → TDD → CI)
Object Design
(see Erich Gamma et al., Design Patterns, 1994; Robert Martin, Design Principles and Design Patterns, 2000)
AI coding agents generate code in object-oriented programming languages such as Python and TypeScript. Key quality attributes that production systems must possess include readability, maintainability, extensibility, and testability. Achieving these attributes requires the code to adhere to object design principles and apply object design patterns. To ensure that an AI coding agent applies object design principles and patterns consistently, quality gates are needed — including explicitly specifying the principles and patterns in the context file, performing static analysis using architectural fitness functions in the CI/CD pipeline, and operating a dedicated subagent responsible for design-quality review.
Service-Oriented Architecture
(SOA; see OASIS, Reference Model for Service Oriented Architecture, 2006; June Sung Park, The Complete Guide to SOA, MSA and Modulith, kosta-online.com)
A critical constraint when working with AI coding agents is the size of the context window. Providing only the optimal information needed — at the right time — is the key to maximizing the agent’s effectiveness and efficiency. SOA decomposes an application into loosely coupled service units and connects them through publicly exposed standard APIs. This allows the agent to generate code independently at the service level. Because the agent’s context is focused on a smaller, well-scoped service, the risk of hallucination can be reduced.
To strengthen independence between services, one approach is to identify Bounded Contexts from the application’s object design model — each representing a cohesive Business Capability and sharing a consistent Ubiquitous Language — and map each Bounded Context to a single service. (See: Eric Evans, Domain-Driven Design, 2003)
When implementing an SOA application with a sub-hourly release cycle, a Microservice Architecture (MSA) can be adopted to enable independent deployment of each service. This allows for independent per-service deployment and optimized feedback loops, enabling rapid error correction. MSA is the SOA implementation pattern best suited for fast release cycles, but some teams prefer a Modulith (Modular Monolith) or SBA (Service-Based Architecture) implementation pattern due to the operational and maintenance complexity that MSA entails. (Mark Richards and Neal Ford, Fundamentals of Software Architecture, 2020) Within a single application, some services can be deployed independently while others are deployed collectively.
Figure 2 illustrates an e-commerce agent system built through agent coding, in which black-bordered boxes represent logical services and red-bordered boxes represent physical services (deployment units). (See: Park Jun-sung, Physical Architecture of AI Agents — Hybrid Architecture of Modulith, SBA, and MSA, kosta-online.com)
To implement SOA in AI agent coding, the architect first designs the SOA architecture and defines each service’s API using OpenAPI or Protocol Buffers. In the agent’s project structure file, each service can be defined as an independent repository or as part of a Monorepo. When a Monorepo is used, static analysis is applied to verify that the SOA service encapsulation principle — that no service may be accessed directly by another except through its API — has not been violated. The agent generates code that conforms to the API contract. In SOA, it is important to allow API extensions while restricting changes that break backward compatibility. The CI pipeline verifies whether this principle has been violated and cancels the build if it has.
Conclusion
An AI coding agent is like a junior developer who must be guided and validated by senior analysts, architects, and engineers — the equivalent of the agent and a senior expert engaged in pair programming. The role of the senior is to take responsibility and remain actively involved in ensuring that software engineering principles, patterns, and best practices are properly applied, so that the resulting application is one that end users can trust and that can continue to grow and evolve over the long term. We need to do software engineering-based agentic coding.
Comments