AI Builder in Practice: What It Is, What Changes, and How I Apply It

At AWS Summit São Paulo on September 3, 2026, at São Paulo Expo, the thread running through the keynote was a practitioner who writes less code by hand and spends more time defining intent, orchestrating specialist agents, and validating what they produce. The market already calls that profile the AI Builder. I recognize the design because this site runs that way: bilingual articles, weekly studies, and cloned-voice narration come out of an agent pipeline that I orchestrate rather than write line by line. The question I care about is not whether agents can execute. It is who decides what they should do, and who notices when they execute wrong. This piece explains the profile, the method AWS published behind it, and how I apply it every day.

What was said on stage

The event drew thousands of people and well over a hundred sessions, according to a community recap. Cleber Morais, AWS general manager for Brazil, opened by marking 15 years of AWS in the country. Laura Grit, VP and Distinguished Engineer, talked about agentic systems in development and framed the cycle as three moves around the word build: write it right, ship it fast, and keep it modern.

Kiro showed up on stage with the sentence that sums up the pitch: "the team decides at each phase; the AI executes." It comes from AI-DLC (AI-Driven Development Life Cycle), the methodology Raja SP published on the AWS DevOps blog on July 31, 2025. The announcements cited in the keynote were the AWS DevOps Agent, continuous modernization in AWS Transform, AWS Continuum, and Web Search in Amazon Bedrock AgentCore. The sessions also surfaced the new AWS Certified AI Business Strategist certification (AIB-C01).

An honest caveat: I found the AI Builder label in DP6's recap ("AWS is calling it the AI Builder"), not on an official AWS page. The event agenda does not use the term. I treat the label as a useful frame, not as a job title or product with a published definition. What does have a published definition is AI-DLC, and that is what I lean on from here.

So what is an AI Builder, really

It is not a job title or a certification. It is a way of working where the person writes less code by hand and spends the day on three skills.

Defining intent. Writing down what success looks like before asking for anything. Not a pretty prompt: a criterion that fits in a versioned file, stating what must be true at the end and what must not happen along the way. If the criterion only lives in the operator's head, approval becomes the mood of the day, and mood cannot be audited.

Orchestrating agents. Deciding which agent does what, in which order, with which context, and where the work stops for someone to approve. One agent per specialty works better than one agent that does everything, and order matters: research before writing, writing before review, review before publishing.

Validating with evidence. The result looking right is not validation. Validation is the check that would have caught the error before it existed: an output schema, a test, a gate that compares what came out with what was asked. In financial systems, where I work, this is not ceremony: the approval gate is where someone signs, and a signature without a criterion becomes a rubber stamp.

Notice that none of the three is about typing code. It is the architect's job without the typing part.

AI-DLC: the cycle, phase by phase

AI-DLC organizes development into three phases. Inception is where you decide what will be built and why: business intent, requirements, design. Construction is where the code is born, in short cycles. Operations is where the system runs, is observed, and is maintained. The sprint gives way to the Bolt, a cycle of hours or days, and in every activity the same pattern repeats: the AI drafts the plan, asks for clarification on what is missing, and implements; the human makes the critical decisions and approves the move to the next phase.

AWS built Kiro on that idea. A Kiro spec produces three files, requirements.md (what must be true), design.md (how it will be done), and tasks.md (the steps), with a human approval point between each phase before moving on. The open AI-DLC repository, awslabs/aidlc-workflows, under the MIT-0 license, goes further: it describes domain specialist agents, reviewers, stages per phase, and an event audit trail. The workflow picks the path from the request, asks what still needs deciding, and stops at approval gates before advancing.

The detail that caught my attention most is the list of supported tools: Claude Code, Kiro CLI, Kiro IDE, Codex CLI, Cursor, opencode, and GitHub Copilot. Two of them are exactly the ones that run my pipeline. That says something important about the AI Builder model: the method is the design of the gates, not the tool. You can swap the executor without swapping the process, as long as the process is written somewhere other than the operator's head.

The sentence that matters is the second half

"The AI executes" is the half that sells. "The team decides at each phase" is the half that takes work, because deciding requires a criterion written beforehand, and validating requires evidence afterwards.

This is where the productivity conversation usually stays shallow. Speed gains with agents are real and easy to measure on the way in. The cost shows up on the way out: in the gate that did not exist, in the error that slipped through because nobody had written down what wrong looks like. That cost is not building the pipeline; it is keeping the gates working for years.

It is also no coincidence that the stage cases came from banking and financial services. That is where errors cost the most and where the approval gate has existed for decades under other names: segregation of duties, dual control, audit trail. The AI Builder does not invent that. It brings the agent into a process that already knew how to decide and validate, and finds out which gates lived only in people's heads.

Primary source, not the summary of a summary: A teaching example of the validating skill, taken from the event itself. Livelo's result with Kiro was presented on stage, then summarized by the event coverage, and I went to check it in the official AWS case study. What reached me had gone through two summaries and switched currency along the way; the official study also credits the gain to Amazon Q Developer and Kiro together, in a program with Compass UOL. I did not see the slide, so I cannot tell at which layer the unit got lost. I deliberately do not repeat the figures here: the point is not the number, it is the path it took. That is exactly what an agent does when nobody opens the primary source. Validating is opening the source.

How I apply it: this site's pipeline

Twice a week, early in the morning, a cron job on my homelab calls the article generator. It reads the feeds and scores each signal against the blog's four pillars: financial systems, AI agents in production, resilience and security, FinOps and data platforms. Out-of-profile services, regional expansions, and weekly digests lose points; a signal below the minimum score does not become an article, and a weak week ends without publishing, on purpose. That is defining intent: pillars, weights, and the minimum score exist in code before the agent picks any topic.

Every generator goes through a single function, callModel. The default provider is the Claude Code CLI, chosen by measurement rather than reputation: same prompt and same signal across the candidates, comparing length, structure, parse failures, and references that actually respond. Codex and Bedrock remain available through LLM_PROVIDER, with no code changes. Before each prompt comes the voz skill, which describes how I write based on what I have already published, as a versioned copy in the repository, because the overnight cron cannot depend on network or a token to write. The model searches the web to confirm dates, limits, and prices. That is orchestrating.

Between the model and production sit the gates: normalizeArticle drops invalid blocks and throws on missing prose or title; the output schema stops malformed JSON; dedupe is by source link, in an index outside the prefix the site lists as articles; a style rule runs on entry, not in the prompt. Only then does the article go to S3, where the site reads it from. Narration runs overnight with my cloned voice on a GPU at home, with the Mac as fallback. That is validating.

My role in all this: I define the pillars, the voice, and the quality criteria, I review what comes out, and I decide what stays. The agents execute.

Where I decide, where the agent executes, where code blocks it

Decisions live in files; deterministic gates sit between the model and production. No step depends on someone remembering to check.

👤 Fernando: decide

• Pillars + minimum score what is worth writing (user)
• Skill voz versioned copy (user)
• Review & decision keep, fix or drop (user)

🤖 Agents: execute

• scoreSignal() weights per pillar (ai)
• callModel Claude Code default (ai)
• WebSearch + WebFetch dates, prices, limits (ai)

🔧 Deterministic gates

• normalizeArticle drops invalid blocks (security)
• index/signals.json dedupe by source link (security)
• no-em-dash.mjs cleans on entry (security)

🟧 AWS: serverless

• S3 articles bucket S3 wins by slug (storage)
• Site + newsletter real readers (frontend)

🏠 Homelab: narration

• RTX 5050 under WSL cloned voice, 02:00 (compute)

Flows

• pillars -> score: written criterion
• score -> callmodel: signal above the minimum score
• voice -> callmodel: injected in every prompt
• callmodel -> research: checks facts
• callmodel -> normalize: bilingual JSON
• normalize -> nodash: valid blocks
• nodash -> dedupe: new link?
• dedupe -> s3: publish and index
• s3 -> site: read
• s3 -> gpu: audio queue
• site -> review: I read what shipped
• review -> pillars: adjusts the criterion

Who does what, stage by stage

Criterion	What I decide	What the agent executes	How I validate
Topic	Pillars, weights, minimum score	Scores feed signals	--plan shows score, reason and what was cut
Facts	Rule: open the URL before citing	Searches, opens pages, cites	curl on every reference before publishing
Voice	The voz skill and what it forbids	Writes pt and en as originals	Reading what shipped; site-wide no em dash rule
Provider	Switch criterion: measurement	Generates the article JSON	Same prompt and signal on all three providers
Publishing	Block format and dedupe index	Uploads to S3 through a script	normalizeArticle throws on missing prose or title
Narration	When to render and with which voice	Renders MP3 on the home GPU	Idempotent: skips objects that already exist

Three lessons the pipeline taught me

None of them came from a mistake the agent made while executing. All of them came from a gate that did not exist or that checked the wrong thing. I keep the pattern, not the numbers.

The dedupe that never deduplicated. The old version of the generator probed an S3 key derived from the source title and wrote another one derived from the generated title. The keys never matched, so the "is it new?" check always said yes. At one run per day, nobody saw it. The day I ran several invocations in a row, repeated articles on the same topic came out. The agent did its job perfectly every time. The error was in the gate, not in the execution. The fix was to dedupe by source link and document the bug in the fallback.

The wrong category that looked right. The classification function tested the bare substring ai, with no word boundary, and it was the first rule to match. "available", "domain", and "maintain" all matched. An article about a database came out tagged as AI agents. Reading one article at a time, nobody noticed. I noticed by looking at the distribution of the whole archive. The fix replaced first-match with occurrence counting, with the title weighing more than the summary, and an idempotent script reclassified the archive.

The style rule that only lived in the prompt. The voice skill was extracted from my published text and treated a punctuation tic as my rhythm. But much of that text had been written together with models, and the tic was a signature of generated text. Asking in the prompt not to use it was not enough; the model returned it anyway. The rule became code that cleans on entry, applied to the whole archive and swept through the sitemap until it hit zero.

The hard lesson: none of these failures raised an error. They all passed the validation that existed. Validating is not reading the result carefully. It is designing the check that would have caught the error before it existed.

How I validate, in practice

1. Write the criterion before asking for execution: Pillars, weights, and the minimum score exist in code before the agent picks any topic. If the criterion only lives in my head, approval becomes the mood of the day, and mood cannot be audited.

2. Put a deterministic gate between the model and production: normalizeArticle drops unknown blocks and throws on missing prose or title; the output schema stops malformed JSON. The model can be as wrong as it likes before that point; after it, no.

3. Check the primary source, not the summary: The Livelo case shows why: the result switched currency across two summaries. Every reference is opened before it enters the text, and a number that does not match the official source is dropped or caveated.

4. Measure before switching executors: I switched providers using the same prompt and the same signal across the candidates, comparing length, structure, parse failures, and references that respond. Model reputation does not go in the spreadsheet.

5. Audit the archive, not just today's item: The wrong category only showed up in a count of the whole archive. Systematic error is invisible in the unit and obvious in the histogram.

6. Know what the fallback lacks: The backup generator does not get the voz skill and still carries the old dedupe. It is documented and switched off. If you turn it back on, check the voice before publishing.

The announcements, through an operator's lens

Every keynote announcement fits the "the team decides, the AI executes" design. My reading is about where the gate sits in each one.

AWS DevOps Agent: on-demand investigations, assessments, and SRE tasks, billed by agent time. Time-based billing means long investigations cost money; but the gate I care about in a financial environment is a different one: what the agent is allowed to change. Broad read access, writes only through the change flow that already exists.

AWS Transform, continuous modernization: scans repositories against configurable baselines and opens pull requests with fixes. Who approves the PR is the whole question. One PR per outdated dependency across hundreds of repositories is a volume no human reviewer reads carefully; the auto-merge criterion needs to exist before the first PR.

Web Search in Bedrock: grounding with web search, with query processing inside US regions and no data egress by default. I used the AgentCore version in an old generator, through an MCP gateway created outside Terraform. I retired it when generation moved to a CLI with native search: it was an unversioned infrastructure dependency. For a regulated Brazilian institution, the absence of sa-east-1 from the in-region processing list is a conversation with the risk team before it is a technical one.

AWS Certified AI Business Strategist (AIB-C01): a no-code certification across four domains, for people who work alongside technical teams but do not build AI solutions. In the certification, AWS separated those who decide from those who build. In my pipeline that separation would not work: whoever decides needs to be able to read the diff, or the gate becomes a rubber stamp.

The trail is the product: The event audit trail in AI-DLC is the right instinct, and not for cosmetic compliance. Every decision in this pipeline came from a commit message that explains why, not what: the measurement that picked the provider, the classification fix, the style rule that became code. If I had let the agents commit "fix category" and "update generator", I could not reconstruct any of those decisions three weeks later. In a regulated environment, the evidence of who approved what, under which criterion, is what you hand to the auditors. The code is what they look at afterwards.

Anti-patterns I have already paid for

• Human gate without a written criterion: approval becomes a rubber stamp, and a rubber stamp does not catch the dedupe that never deduplicated.
• Trusting the summary of a summary: Livelo's result switched currency across two layers; the agent reproduces whatever layer you hand it.
• Validating the item and never the archive: systematic error, like the wrong category across much of the archive, does not show up reading one article at a time.
• Style rule only in the prompt: the model returns the tic even when told not to; a rule that matters becomes code on entry.
• Switching executors on reputation: without the same prompt and the same signal across candidates, you swap models and find the regression in production.
• Fallback nobody exercises: the backup generator still writes in the old voice; switched back on unchecked, it would publish off-standard.

When to adopt the AI Builder model

Agent pipeline with gates (AI Builder)

Pros

• Repetitive volume with a stable criterion
• Swap the executor without swapping the process
• Auditable trail by default

Cons

• Permanent cost of maintaining the gates
• Silent failure wherever a gate is missing
• Requires someone who reads the diff, not just the summary

Verdict: Adopt when the criterion fits in a file and errors revert in minutes.

IDE assistant, human in charge

Pros

• Cheap adoption, no infrastructure
• Good in a domain you can't specify yet

Cons

• Doesn't scale volume
• Decisions live in the chat, with no trail

Verdict: Use it while you're still discovering what right looks like.

Human execution, AI for lookup only

Pros

• Full control where errors are irreversible

Cons

• Slow and expensive at volume

Verdict: Keep it for money movement, production IAM and contracts.

Curator's note: After 16 years building financial platforms, what I recognized on the Summit stage was not a new role. It was the architect's job without the typing part. What I would do again, from day one: write the criterion for every gate before letting any agent publish, and keep the why of every decision in the commit. What I would do differently: I would have looked at the distribution of the whole archive in the first week, not months later. The systematic error was there from the start; someone just had to look at the histogram.

Verdict

The AI Builder profile describes well what already happens to anyone operating agents in production, and AI-DLC gives it a name and a structure: define the intent, orchestrate the agents, validate with evidence. The risk is reading only the half of the sentence that sells. Use the model when three conditions are present: the quality criterion fits in a versioned file, there is a deterministic gate between the model and production, and the error can be reverted in minutes. That was the case for this site: a wrong article gets republished, a wrong category gets reclassified. Do not use it, or use it only as a consultant, when the error is irreversible or regulated and you cannot write the approval criterion before executing: money movement, IAM permissions in production, contracts. In those cases the stage sentence is still right, but the "decides" has to come with a signature and evidence, and that is still human work.

A question for anyone already working with agents: of the three skills, which is the hardest on your team today, defining, orchestrating, or validating?

Rating: Adote com portões

References

• Como foi o AWS Summit São Paulo 2026 (Você Certificado)
• AI-Driven Development Life Cycle: Reimagining Software Engineering (AWS DevOps Blog)
• awslabs/aidlc-workflows (GitHub)
• Kiro: Specs
• Livelo boosts productivity 30%-50% using Amazon Q Developer and Kiro (AWS case study)
• Introducing Web Search on Amazon Bedrock for foundation model grounding
• AWS Certified AI Business Strategist (AIB-C01) exam guide

---

Originally published at fernando.moretes.com. By Fernando F. Azevedo: Senior Solutions Architect.