Cloud-Native Agentic Coding: Implementing Software Engineering as Executable Governance
- June Park
- Jul 10
- 10 min read
The Emergence of Cloud-Native Development
Around 2007, leading enterprises began migrating their applications to Infrastructure-as-a-Service (IaaS)-based public cloud platforms. Around 2010, pioneering companies such as Netflix and Amazon began developing the Microservice Architecture (MSA) paradigm. The emergence of Docker containers in 2013, followed by container orchestration platforms such as Google’s Kubernetes and Amazon’s Elastic Container Service (ECS) in 2015, accelerated the adoption of microservices as the dominant implementation pattern for Service-Oriented Architecture (SOA). In the same year, the Linux Foundation established the Cloud Native Computing Foundation (CNCF) to promote the standardization of the cloud-native ecosystem and foster open-source projects.
By 2015, Amazon already had thousands of DevOps teams independently deploying microservices through standardized internal CI/CD pipelines approximately 50 million times per year — an average of one deployment every 0.6 seconds. (Chris Munns, I Love APIs 2015: Microservices at Amazon, 2015.) As a result, the core pillars of cloud-native application development became Microservice Architecture (MSA), automated CI/CD pipelines, containers and container orchestration, and DevOps practices built on Infrastructure as Code (IaC).
The emergence of Generative AI in 2022 rapidly accelerated AI-assisted coding, vibe coding, and AI agentic coding, ushering in a new phase in software development. However, these innovations have not replaced the cloud-native development paradigm. Rather, they represent its next stage of evolution, building upon the cloud-native foundation established over the previous decade.
The Promise and Reality of Cloud-Native Development
As the limitations of Microservice Architecture (MSA) became increasingly apparent in the 2020s, Modulith (Modular Monolith) and Service-Based Architecture (SBA) (M. Richards and N. Ford, Fundamentals of Software Architecture, 2020) began to attract attention as more pragmatic alternatives. SBA is an SOA implementation pattern similar to Miniservices Architecture, proposed by Gartner (A. Thomas and A. Gupta, Miniservices: A Pragmatic Alternative to Microservices, Gartner, 2017). Unlike MSA, SBA packages and deploys services at a coarser granularity than individual microservices while avoiding disruptive practices that are often difficult for typical enterprises to operate effectively, such as Database-per-Service, Event Sourcing, and fully decentralized DevOps. Modulith differs from SBA in that the entire application is deployed as a single unit while maintaining a modular internal architecture. In the Gartner report cited above, Gartner predicted that by 2019, more than 90% of organizations evaluating MSA would choose miniservices rather than microservices.
The DORA (DevOps Research and Assessment) metrics shown in Table 1 are among the most widely recognized measures of software delivery performance pursued by cloud-native development. (DORA, DORA Metrics, https://dora.dev/guides/dora-metrics/)
The defining characteristic of cloud-native development is its emphasis on extremely short deployment and release cycles. While few organizations aim to match Amazon's deployment frequency of once every 0.6 seconds, many target at least one deployment per day. Leading SaaS companies routinely deploy and release software updates dozens of times each day. Key practices of Microservice Architecture (MSA) - such as independent service deployment, database-per-service, and event sourcing - enable this high level of release agility. However, these practices come at the cost of significant distributed-system complexity and operational overhead that are often beyond the capabilities of typical enterprises.
In Korea, relatively few organizations release software on a regular cadence of less than one month. Therefore, consistent with Gartner's findings, Modulith or Service-Based Architecture (SBA) is likely to be a more appropriate architectural choice than MSA for most Korean enterprises. In such environments, three DORA metrics - deployment frequency, lead time for changes, and time to restore service - are generally of lower priority.
In contrast, change failure rate and deployment rework rate remain critically important because they directly reflect software quality. MSA, containers, Kubernetes, CI/CD, and Infrastructure as Code (IaC) do not, by themselves, guarantee software quality. They are enabling technologies that support rapid software delivery. Quality is achieved through the software engineering practices executed on top of this cloud-native infrastructure.
In cloud-native development, software quality is established through the software engineering activities shown in the black boxes of Figure 1. These include process modeling, semantic modeling, use-case analysis and test case derivation during requirements analysis; domain modeling based on object-oriented design principles; service identification and SOA architecture design; and Test-Driven Development (TDD), test automation, and CI/CD automation for implementing production systems. The activities highlighted in the red boxes of Figure 1 represent the additional engineering tasks required when implementing an SOA design using Microservice Architecture (MSA).
Since the invention of software in the early 1950s, every major advancement in information technology has been achieved through the incremental and cumulative integration of established technologies with emerging innovations. As illustrated in Figure 1, Microservice Architecture (MSA), which began gaining widespread adoption in the early 2010s, was built upon Service-Oriented Architecture (SOA), which had itself become widely adopted roughly two decades earlier, beginning in the early 1990s. Consequently, organizations with mature SOA analysis and design capabilities were significantly more likely to succeed in adopting MSA.
Likewise, SOA design is founded on use case–driven requirements analysis and object-oriented design methodologies that became widely established in the mid-1990s. Organizations that had not developed capabilities in business process modeling, semantic modeling, use case analysis, object-oriented design principles, design patterns, and refactoring often struggled to adopt SOA successfully. Moreover, many organizations that attempted to implement MSA without first establishing these software engineering practices — or without first adopting SOA — experienced significant difficulties or outright failure.
Similarly, the automation of Continuous Integration and Continuous Delivery (CI/CD), which became widespread in the early 2010s, was built upon Test-Driven Development (TDD) and automated testing practices that had emerged approximately a decade earlier. Organizations lacking mature TDD and test automation capabilities cannot reliably maintain software quality within an automated CI/CD pipeline. As a result, they typically experience higher change failure rates and deployment rework rates.
Furthermore, TDD can be effective only when requirements specifications are sufficiently complete and detailed to derive comprehensive test cases with high use case coverage. Ultimately, the success of cloud-native development depends not on MSA or Kubernetes themselves, but on how rigorously organizations apply established software engineering principles, including requirements analysis, object-oriented design, SOA architecture design, TDD, and test automation. Only when these engineering disciplines are firmly established can CI/CD simultaneously achieve both high software quality and rapid release cycles.
In essence, CI/CD is not a technology that guarantees software quality by itself. Rather, it is a platform that continuously validates and executes software engineering principles — from requirements analysis through testing — in an automated manner. In the era of AI agentic coding, these validation rules are evolving into executable governance that directs and constrains the behavior of AI coding agents.
The Evolution of Cloud-Native Development in the Era of AI Agentic Coding
As shown in Table 2, AI agentic coding requires software delivery metrics that extend the five DORA metrics presented in Table 1.
Improving the performance metrics in Table 2 requires minimizing the nondeterministic behavior of AI agents and the resulting hallucinations and implementation errors. Achieving this objective requires clear and verifiable specifications, executable constraints, and deterministic validation within a closed-loop feedback process.
More specifically, production systems that are both reliable and maintainable can be developed through a combination of Upfront Requirements Engineering (URE), Spec-Driven Development (SDD), Constraint-Driven Development (CDD), and Evaluation-Driven Development (EDD).
Upfront Requirements Engineering (URE) defines what the system should accomplish. Spec-Driven Development (SDD) formally specifies those requirements. Constraint-Driven Development (CDD) defines the architectural, engineering, and implementation constraints that AI agents must satisfy during code generation. Evaluation-Driven Development (EDD) deterministically verifies that the generated implementation conforms to the specifications and constraints.
Together, these engineering practices transform AI agentic coding from a probabilistic code-generation process into a disciplined software engineering process capable of producing production-quality systems with high reliability and long-term maintainability.
As illustrated in Figure 2, Upfront Requirements Engineering (URE), Spec-Driven Development (SDD), Constraint-Driven Development (CDD), and Evaluation-Driven Development (EDD) are realized through well-established software engineering practices. In AI coding agent environments, these practices are embodied as context files, hooks, skills, tools, and subagents, which function as executable governance to direct and constrain agent behavior. (J. Park, AI Coding Agents Are Junior Developers… Software Engineering Is Essential, ZDNET Korea, June 6, 2026.)
Before agentic coding begins, it is essential to design the business process models that the application will support or transform, develop semantic models of the business domain, and perform use case analysis based on those models. These activities establish the foundation for delivering business value. (J. Park, Key Success Factors for AI Agents, ZDNET Korea, May 1, 2026; McKinsey, One Year of Agentic AI: Six Lessons from the People Doing the Work, 2025.)
Agentic coding should begin with a comprehensive specification of the application. In particular, defining acceptance criteria for Behavior-Driven Development (BDD) (Dan North, Introducing BDD, 2006) together with an ontology that formally represents the application's domain knowledge is an especially effective approach. A fundamental principle of agentic coding is to verify nondeterministically generated code through deterministic tests. Accordingly, Test-Driven Development (TDD) should be applied by deriving executable tests from the BDD acceptance criteria before implementation, allowing AI agents to generate code that satisfies those tests. The domain ontology, meanwhile, provides the foundation for context engineering, enabling AI agents to interpret domain knowledge consistently throughout the development process.
Core architectural principles - including Domain-Driven Design (DDD) (Eric Evans, Domain-Driven Design, 2003), Service-Oriented Architecture (SOA) (J. Park, The Complete Guide to SOA, MSA and Modulith, 2005, https://www.kosta-online.com/post/the-complete-guide-to-soa-msa-and-modulith), and Architectural Decision Records (ADR) - should be implemented as Architectural Fitness Functions (AFFs) (Neal Ford et al., Building Evolutionary Architectures, 2017) and automatically validated within the CI/CD pipeline. Likewise, security, regulatory compliance, cost governance, and observability can all be continuously verified through automated pipeline checks. Deterministic test suites produced through TDD validate functional requirements, AFFs validate architectural constraints, and security, compliance, and observability rules validate non-functional requirements.
In this way, software engineering principles and constraints are transformed into executable governance that directs and constrains AI coding agents. The CI/CD pipeline continuously executes these validation rules, providing deterministic verification of the inherently nondeterministic artifacts generated by AI agents. The central principle of agentic coding is therefore to evaluate nondeterministically generated outputs using deterministic verification rules, thereby achieving production-quality software through disciplined software engineering rather than relying solely on the capabilities of the AI agent itself.
Cloud-Native Agentic Coding Process
Figure 3 illustrates the Cloud-Native Agentic Coding Process, a reinterpretation of the traditional agile development process for the era of AI agentic coding. While preserving the fundamental structure of established methodologies - including Design Thinking, Lean Startup, Scrum, and Extreme Programming (XP) - the roles of developers evolve significantly. Activities that were previously implemented directly by developers are delegated to AI agents, while developers focus on specifying requirements, reviewing outputs, validating quality, and guiding the development process. (See Tim Brown, Change by Design, 2019; Eric Ries, The Lean Startup, 2011; Ken Schwaber, Agile Project Management with Scrum, 2004; Kent Beck, Extreme Programming Explained, 2004.)
The process begins with a Design Thinking loop that performs Upfront Requirements Engineering (URE) to derive an application specification that is desirable for users, feasible from a technical perspective, and viable as a sustainable business. Based on this specification, a Minimum Viable Product (MVP) is developed, followed by iterative Build–Measure–Learn cycles.
During the Build phase, an agile development loop - such as Scrum, Kanban, DevOps, or SAFe - is applied. A Sprint Backlog is created by selecting the use cases to be implemented during the sprint (typically a release cycle of one month or less) from the Product Backlog, which contains the application's use cases and other development tasks. Developers assign these use cases to AI agents, which implement them while adhering to Test-Driven Development (TDD) practices and executable governance. Developers review and approve the artifacts generated by the agents, and only changes that satisfy both the executable governance rules and Evaluation-Driven Development (EDD) validations are continuously integrated and deployed through the CI/CD pipeline.
The innermost cycle of the Build phase is the autonomous Red–Green–Refactor TDD loop executed by the AI agent during code generation. Every pull request generated by an AI agent should be reviewed by a human developer. The next outer cycle is the Continuous Integration (CI) cycle, in which the agent performs frequent builds and automated validations. Surrounding that is the Continuous Delivery (CD) cycle, through which the agent deploys software multiple times per day. Every CI and CD execution should include deterministic validation based on EDD. In AI agentic coding, XP's core engineering practices - including TDD, refactoring, and Continuous Integration - are largely automated by AI agents and augmented with modern Continuous Delivery and executable governance.
The outermost cycle, encompassing XP, is the Scrum sprint cycle (that is, the release cycle). At the end of each sprint, the Product Owner (PO), stakeholders, and the development team conduct a Sprint Review to evaluate the product increment, after which the PO decides whether it is ready for release. If approved, user feedback on the released increment is measured using the Innovation Accounting approach from Lean Startup, providing data-driven evaluation of business outcomes. When the measured results satisfy the target Key Performance Indicators (KPIs), the current strategy is maintained (persevere) and development proceeds to the next sprint. Otherwise, the team pivots by returning to the Design Thinking phase to redefine the problem and explore alternative solutions. If the product increment is rejected during the Sprint Review, the team revises the project plan and organization or returns to the Design Thinking phase.
In cloud-native development, software engineering principles were continuously verified through CI/CD pipelines. In AI agentic coding, those same software engineering principles are embodied as executable governance that directs and constrains AI agents, while CI/CD continuously validates their enforcement. Consequently, AI agentic coding does not represent a replacement for software engineering. Rather, it is a new development paradigm that realizes established software engineering principles as executable governance and applies them to AI agents. As a result, the importance of software engineering does not diminish in the age of AI agents. On the contrary, its role becomes even more critical as software engineering evolves into the executable governance that ensures AI-generated software remains reliable, maintainable, and production-ready.
Conclusion
The success of cloud-native development has been driven not primarily by Microservice Architecture (MSA), but by the software engineering principles that underpin it. The same is true for AI agentic coding: its success ultimately depends on sound software engineering rather than on AI alone.
The key difference is that software engineering is no longer merely a set of guidelines for human developers. In the era of AI agentic coding, it is evolving into executable governance that directs and constrains the behavior of AI agents. CI/CD serves as the execution platform that continuously validates and enforces this governance.
AI does not diminish the importance of software engineering. Instead, it elevates software engineering from human guidance to machine-enforceable governance, making it the foundation for building reliable, production-quality AI-generated software.
Comments