AI-Native Development: A Practical Reference for Your Cloud Stack

This article is written with AI-assistance

A customer service team wants a CSV export from its administration portal. The change needs an interface, an API, access checks, tests and a release plan.

An AI coding assistant can help write the implementation. An AI-native development process connects that assistance to the whole delivery workflow: the requirement, repository context, permitted actions, executable checks, review and production feedback.

I use “AI-native development” here to describe a process designed around agents carrying out defined engineering tasks, with people setting direction and deciding which changes can proceed. A team can build that process around a local small language model, or use model services in Azure, Google Cloud or AWS.

The starting point should be the repositories, identity system, testing tools and delivery pipeline the team already uses. The cloud stack supplies parts of the implementation. The workflow determines how those parts work together.

What changes in the SDLC

Anthropic’s AI-native SDLC playbook provides one concrete approach across planning, design, building, testing, deployment and maintenance. It also retains human accountability for decisions requiring judgment.

The comparison below starts with an established Agile/DevOps team. That team already has automated tests, delivery pipelines and production feedback.

Both processes contain feedback loops. The change is that an agent can perform work inside those loops, receive tool results and attempt the next step within its permitted scope.

The components every implementation needs

The model is one component in the system. A workable implementation also needs a way to provide context, execute actions and establish whether a change is acceptable.

An approved requirement and current project context. Record the outcome, constraints, acceptance criteria and open questions. Give the agent relevant code, API contracts, architecture rules and build commands. Anthropic uses versioned files such as intent.md for this purpose. The filename is a convention; reviewed content and traceability are what matter.

A model endpoint and development agent. The endpoint generates responses. The development agent manages the conversation and connects those responses to repository operations and tools. An endpoint alone cannot inspect your repository or run its tests.

A controller with enforceable limits. A controller can be part of the agent application or a separate service. It tracks task state, permitted paths, allowed commands, time limits and repair attempts. Instructions explain expected behaviour; permissions and tool policies enforce the action boundaries.

An isolated tool runner. Give each task a working copy and a suitable execution environment. Tools read files, apply patches, run checks and collect results. Separate development credentials from release permissions, and keep production access specific to approved operations.

Verification maintained outside the repair loop. Existing regression tests, acceptance checks, static analysis and human review provide evidence about the change. During a repair task, protect the acceptance checks from unauthorised modification. Anthropic’s feedback-loop guidance makes this distinction explicit.

A release path and operational feedback. Keep changes connected to their requirement, diff, check results and approval record. Production findings can enter the next task as evidence. Initially, an agent can investigate with read access and submit a proposal for review.

One feature, from request to release

For the CSV export example, suppose the product owner agrees three requirements: the export follows the screen’s filters, contains only approved columns, and includes only records the signed-in user may access.

The team then carries the feature through this workflow:

The controller should count repair attempts itself. If a task reaches its limit, it should return the current diff, failed checks and execution log to the engineer.

The export endpoint can remain ordinary application code, with standard authentication and database access. Here, the model participates in developing and maintaining the feature.

Map the workflow to your stack

These are example combinations for a web application. An organisation can retain its existing Git provider, issue tracker or CI system when those tools already meet its needs.

The agent host and the application host have different jobs. In the AWS example, AgentCore runs the development agent while ECS Fargate runs the example application. The agent uses explicitly configured tools to interact with the repository, build system and delivery pipeline.

Local SLM: evaluate the model against your engineering tasks

A local implementation can combine Ollama, a compatible development client, Git and a restricted test runner. Aider documents its Ollama integration; a team can also build a task controller around a local model endpoint.

For a small model, I would begin with narrow changes and selected repository context. Check whether it can follow the chosen edit format, use the required tools, understand test failures and stop when it lacks information. Code generation quality and reliable repository editing are separate things to evaluate.

Run planning, implementation and review as separate passes when useful. Several passes through the same model can share the same mistaken assumptions, so retain independently maintained checks and human review.

Local inference also needs a boundary around the surrounding workflow. Check where context retrieval, optional embeddings, tool calls and diagnostic logs are processed or stored. Hardware capacity, context length and quantisation should be recorded alongside the model version during evaluation.

Azure: connect Foundry models to the existing delivery process

Microsoft Foundry supplies model and agent capabilities. This reference design uses a custom development agent on Container Apps, with controlled integrations to Azure Boards, Azure Repos and Azure Pipelines.

The agent can turn an approved work item into a proposed plan, use a sandboxed tool runner to prepare a patch, and collect pipeline results. A reviewer checks the change before it progresses. Azure Pipelines supports environment approvals and checks, which resource owners manage separately from pipeline YAML.

Entra ID and Key Vault support identity and secret handling. The implementation team still defines the agent’s permissions, connects the tools and decides which actions need approval.

Google Cloud: Gemini, ADK and Cloud Run

Google now documents the former Vertex AI platform as Gemini Enterprise Agent Platform. In this reference design, the platform supplies the model endpoint, while a custom Agent Development Kit agent runs on Cloud Run. Google provides an ADK deployment guide for that hosting pattern.

The development agent uses configured repository and task tools. Cloud Build executes the project’s checks; Cloud Deploy manages the example application’s release to Cloud Run. Production targets can require rollout approval.

Cloud Logging and Cloud Monitoring provide operational evidence for investigation. The team decides what evidence the agent may read and which changes it may propose.

AWS: Bedrock, AgentCore and the delivery pipeline

Amazon Bedrock provides model access, while AgentCore Runtime can host a custom development agent. That agent needs defined tools and task permissions for repository work and execution.

CodeBuild runs the build and test commands. CodePipeline coordinates the release, with a manual approval action before the chosen production deployment step.

In the example, the application runs on ECS Fargate and sends operational telemetry to CloudWatch. An agent can use permitted log access to investigate an incident and prepare a proposed fix. IAM roles and Secrets Manager support the access boundary around those operations.

Choose the stack around the existing team

Start by identifying where the code lives, how developers authenticate, where checks execute and who owns releases. A company whose application runs in AWS can continue using GitLab for source and CI. A local model can assist a team that deploys its application to Azure.

Choose the model and agent combination against representative repository tasks. Evaluate tool-call correctness, edit reliability, completion rate, latency and the amount of human repair required. Keep application tests distinct from evaluations of the development agent. Anthropic’s continuous-evaluation guidance includes regression checks for changes to agent instructions and configuration.

For a Hong Kong organisation, record the permitted locations for source code, prompts, retrieved context, build logs and traces. Then check each selected service and model deployment against that requirement.

Azure distinguishes global, data-zone and geography-based processing. Google documents processing commitments by endpoint and model, while Bedrock’s cross-region inference profiles define possible routing destinations. The location of the application server alone is insufficient to establish where model processing occurs.

Start with one repository and a measured pilot

Choose a bounded change with acceptance criteria and a named reviewer. Keep the approved behaviour stable while comparing the existing process with the proposed agent workflow.

Record the model version, agent configuration, relevant context, tool permissions and repair limits for each run. Include unsuccessful attempts in the results, together with time spent reviewing and correcting the output.

A single successful feature demonstrates that the workflow can execute. Use a representative set of changes before expanding its scope or permissions, including cases involving unfamiliar code and failing checks.

Measure elapsed delivery time, engineer effort, review time, rework and total operating cost. Across a suitable set of releases, also track production defects, failed changes and recovery time. Include model calls, agent hosting, build execution and engineering time; add hardware, power and maintenance for a local deployment.