DEV Community: Francisco Silvério

Agentic Development as a Process, Not Throwaway Prompts

Francisco Silvério — Sat, 17 Oct 2026 19:19:24 +0000

Put five engineers on the same team, give them the same coding agent, and within a month you will have five different agentic workflows: a private prompt library, a rules file that never leaves a laptop, a clever skill nobody else knows exists. Each engineer is faster than before. The team is not, because the problem was never the tool. It was the process, or rather the absence of one.

A team's agent setup (its rules, skills, connectors and quality gates) is shared engineering infrastructure, and it deserves to be designed, versioned and reviewed like any other part of the delivery system. Its purpose is not to remove the engineer, but to move the engineer's judgment to where it matters most. The examples use Claude Code, but every layer maps to open standards that Cursor, Codex and Windsurf support too.

1. From Prompts to a Process

A prompt is a one-time artifact. It lives in a single session, carries the assumptions of whoever wrote it, and disappears when the context window closes. Even an excellent prompt does not scale: nobody else can review it, test it, or improve it.

A process is the opposite. It is:

Shared: every engineer runs the same workflow against the same definitions.
Versioned: it lives in a repository, so every change has history and an author.
Reviewed: changes go through pull requests, like any other code.
Compounding: a fix made once benefits every future session, for every engineer.

We already accept this logic for CI/CD. Nobody expects each engineer to deploy with a personal script; the pipeline is a team asset with owners and a review process. Agentic workflows deserve the same treatment, and the data suggests they need it.

Google's DORA research on AI-assisted software development describes AI as an amplifier: it magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones. The 2025 report also found that AI adoption now improves delivery throughput while still correlating negatively with delivery stability. Speed without a shared quality system turns into instability downstream.

DORA's follow-up work, the AI Capabilities Model, identifies seven practices that determine whether AI helps or hurts an organization. Three of them read almost like a specification for the process in this article:

A clear and communicated AI stance: engineers know which tools and practices are expected. Ambiguity is a risk, not a freedom.
AI-accessible internal data: agents are connected to internal documentation and systems instead of working from prompts alone.
Working in small batches: a deliberate counterweight to agents' tendency to produce large changes that are hard to review and test.

2. The Reference Pipeline

Setting up an agentic process starts with mapping everything an engineer usually does by hand. Fetching context for the agent or babysitting it through every step is not the engineer's job. Building the skills, tools and connectors that let it work on its own between the human checkpoints is. Here is what that workflow could look like for a typical development team:

flowchart TD
    T["Ticket in the tracker"] --> I["Ingest"]
    I --> RD[("Requirements doc")]
    RD --> G1{{"Engineer validates requirements"}}
    G1 --> P["Plan"]
    P --> BL[("Versioned backlog of slices")]
    BL --> G2{{"Engineer approves the plan"}}
    G2 --> S["Spec for one slice"]
    S --> G3{{"Engineer approves the spec"}}
    G3 --> X["Implement"]
    X --> V["Verify: typecheck, tests, checks"]
    V -- fail --> X
    V -- pass --> AR["Adversarial review agents"]
    AR -- findings --> X
    AR -- clear --> PR["Pull request"]
    PR --> G4{{"Engineer reviews and merges"}}

Each stage produces an artifact that the next stage consumes, and each artifact is a file in the repository, not a message lost in a chat history. The hexagons are the human gates; we will come back to them in section 4.

Ingest. A connector reads the ticket and turns it into requirements: the problem, the acceptance criteria, the stakeholders, and where each requirement came from. A requirement with no source is one the agent invented.
Plan. Requirements become small slices in a versioned backlog, each with its dependencies and its own definition of done. If the agent only ever implements one slice, it cannot produce a 3,000-line pull request.
Implement. For each slice, the agent writes a short spec (approach, files, edge cases, tests) and waits for the engineer's approval. Correcting a spec costs a minute; correcting finished code costs a review cycle.
Verify. Typecheck, tests and checks run until they pass, and only then is a pull request opened. "Done" is defined by the pipeline, not claimed by the agent.
Review. Separate reviewer agents, each focused on one dimension (requirements, code quality, delivery plan), try to break the work before a human sees it. This is Anthropic's evaluator-optimizer pattern: the reviewers produce findings, and a human still decides what to act on.

Traceability ties the stages together. Each slice records which acceptance criteria it covers, so every criterion can be traced to a test:

id: S-03
title: Paginated order history endpoint
depends_on: [S-01, S-02]
covers: [AC-2, AC-4]
definition_of_done:
  - Returns orders for the authenticated customer only
  - Cursor-based pagination with a maximum page size of 50
  - Integration tests cover AC-2 and AC-4, including the empty state
  - Typecheck, lint and the full test suite pass
status: ready

That trace matters most for tests. A suite written by the same agent that wrote the code tends to confirm what the code does, not what the requirement says.

3. The Toolkit, Layered by How Strongly It Holds

The pipeline is executed by a toolkit with distinct layers. The most useful way to organize them is not by feature, but by how strongly each one constrains the agent.

flowchart BT
    R["Rules: advisory<br/>conventions, boundaries, vocabulary"] --> SK["Skills: procedural<br/>ingest, plan, implement, review"]
    SK --> C["Connectors: grounded<br/>trackers, docs, CI, internal systems"]
    C --> E["Enforcement: deterministic<br/>hooks and CI gates that must pass"]

Rules (advisory). Conventions, architectural boundaries and domain vocabulary, in CLAUDE.md or AGENTS.md. Anthropic's own docs describe them as advisory, so keep them short: every extra line dilutes the others.
Skills (procedural). Each pipeline stage is a skill the agent loads only when the task calls for it. This is where the team's process actually lives.
Connectors (grounded). MCP servers for trackers (Jira, Linear), knowledge bases (Confluence, Notion), source control and CI (GitLab, GitHub), business systems (Salesforce) and other internal teams' services. Requirements then come from the source, not from someone's paraphrase.
Enforcement (deterministic). Hooks and CI gates for anything that must happen: formatting, blocking destructive commands, refusing "done" while tests fail. Guarantees go in hooks; preferences go in rules.

The toolkit lives in a repository and changes through pull requests, either as a committed configuration directory or, at scale, as plugins published through an internal marketplace:

.
├── AGENTS.md                 # shared rules, read by most agents
├── CLAUDE.md                 # symlink or one-line import of AGENTS.md
├── .mcp.json                 # team connectors
├── .claude/
│   ├── settings.json         # hooks and permissions, committed
│   ├── skills/
│   │   ├── ingest/
│   │   ├── plan/
│   │   ├── implement-slice/
│   │   └── review/
│   └── agents/               # reviewer subagents
└── docs/
    ├── requirements/         # output of ingest
    └── backlog/              # versioned slices

None of this locks a team into one vendor. Rules map to AGENTS.md, skills to the Agent Skills standard, and connectors to MCP: open formats that most coding agents now read. The exception is enforcement. Agent-level hooks are tool-specific, so the gates that must hold regardless of who, or what, wrote the code belong in CI.

4. The Engineer at Each Gate

Look at the pipeline again and count where a human appears. Not at every step: at four gates. That is the point. The process removes the engineer from the work that does not need judgment, so that judgment can be applied fully where it does.

The reviewer role is increasingly automated; the review itself, the judgment of whether the software is right for its purpose, is not. And accountability does not delegate: the name on the approval belongs to a person.

The research points the same way. A 2026 literature review on software engineering for agentic systems frames the engineer's enduring value around four competencies: intent articulation, systematic verification, multi-agent orchestration and accountable human judgment. None of them is typing code. All of them are engineering.

5. You Won't Be Replaced. Unless You Stop Learning.

Every shift in tooling triggers the same prediction. When deployments moved from manual runbooks to CI/CD pipelines, the engineers who stayed relevant were not the fastest at running scripts by hand; they were the ones who learned to build pipelines.

When infrastructure moved from on-premise racks to cloud APIs and infrastructure as code, the people who struggled were not the ones whose tasks disappeared. They were the ones who refused to learn the new abstraction.

Agentic development follows the same pattern, at a larger scale. The tasks are changing, and much of the typing goes away. What remains is understanding the problem, decomposing it, defining what correct means, and taking responsibility for the result. That was always the hard part of the job.

Engineers are not being replaced by agents. Engineers who stop learning are being replaced by engineers who did not. That was true long before AI, and it will remain true after whatever comes next.

Conclusion: Build the Process Once, Improve It Every Time

A prompt helps one engineer, once. A process helps the whole team, every time, and it gets better with each mistake it absorbs. By treating rules, skills, connectors and quality gates as shared, versioned infrastructure, a team turns agent speed into delivery that meets requirements and holds the QA bar, instead of a faster way to produce pull requests nobody trusts.

The agent writes the code. The team owns the process. The engineer owns the judgment.

References

Microservices with Bounded Contexts, Event-Driven Operations and Sagas: The Art of Orchestrating a Distributed System

Francisco Silvério — Wed, 18 Feb 2026 13:17:11 +0000

In a monolithic architecture, a transaction is a single, atomic database operation. It either happens in full, or it doesn't happen at all. It’s safe, but it can become a bottleneck when millions of users are trying to process transactions simultaneously. As we scale into distributed systems, we trade that localized safety for a "relay race" across multiple services.

To prevent this relay race from ending in a catastrophe, we must move beyond the basic "microservices" buzzword and master the orchestration between services.

1. The System: International Wire Transfer

This architecture draft draws a microscope to a banking engine, specifically, the part responsible for wire transfers. Its mission is to move funds across borders while satisfying three distinct business requirements:

Integrity: Ensuring the math adds up and funds are accounted for.
Security: Screening every transaction against global watchlists.
Market Accuracy: Locking in volatile currency exchange rates in real-time.

Instead of a single "Banking Service," we have three autonomous "islands" of logic: Ledger (Core), Fraud (Compliance), and FX (Currency).

2. Establishing the concepts

I. Bounded Context: The "Territory" of Data

The term "Bounded Context" was originated by Eric Evans, who defines it as:

A description of a boundary (typically a subsystem, or the work of a particular team) within which a particular model is defined and applicable.

Looking at the diagram, you’ll notice that the Entity: Account exists in all three services, but the Account Model is different in each one. This is the Bounded Context in action.

In the Ledger Context: An account is a Balance Container. It only cares about Available Balance and Currency.
In the Fraud Context: An account is a Legal Risk Profile. It cares about the Owner Legal Name and Watchlist Flags.
In the FX Context: An account is a Regional Wallet. It cares about the Home ISO and the Local Market Rate.

By isolating these models, we ensure that a change in the Compliance department's risk-rating logic never accidentally breaks the code responsible for calculating account balances. Each service owns its own "version of the truth."

II. Event-Driven Operations: The "Nervous System"

In the provided architecture, notice that the services never call each other's APIs directly. They communicate via a Message Bus.

When a request arrives, the Ledger doesn't "tell" Fraud to start a check; it simply announces a fact: TransferRequested.

Decoupling: The Ledger doesn't know (or care) if the Fraud service is currently online. It drops the message on the Bus and continues its work.
Autonomy: The Fraud and FX services are "Subscribers." They react to the message when they have the resources to do so. This prevents a slow-down in one service from cascading into a total system failure.

3. The Saga: Orchestrating the Distributed "Undo"

Now that we have established what the system does and why it is organized this way, one question might pop up: If these services are independent islands, who ensures the process actually finishes?

This is where the Saga Pattern enters.

In a distributed system, there is no "Global Rollback." If the money is locked in the Ledger (Step 2) and the Fraud service emits a SecurityCleared message, but the FX system finds a problem, there is no way to automatically revert all the other database records. We must perform a Compensating Transaction.

How the Saga Orchestrates the System:

The Happy Path:
- Ledger locks the funds emits TransferRequested.
- Fraud clears the user emits SecurityCleared.
- FX locks the conversion rate emits RateLocked.
- Result: The transfer is finalized.
The Failure Path (The "Undo" Button):
- Ledger locks $10,000 and emits TransferRequested.
- Fraud Service checks pass and it emits a SecurityCleared message.
- FX Service fails to process the transaction and emits TransactionNotAllowed.
- The Compensation: The Ledger and Fraud services are "listening" for failure events. Upon hearing TransactionNotAllowed, they trigger their own internal "Undo" logic to unlock the $10,000 and notify the user.

Choreography vs. Orchestration

Our system uses Choreography. There is no central "Boss" or "Orchestrator" service. The Ledger works as an entry point for the operation, but it is not responsible for managing the state of the entire flow.

If we required more granular control over the operation, we could implement Orchestration, where a dedicated service directs the transaction and has the final word to approve or deny it. For many decentralized systems, however, the Choreography shown here offers the best balance of scale and simplicity.

Conclusion: Resilience by Design

By combining Bounded Contexts (to isolate logic), Event-Driven Operations (to decouple communication), and Sagas (to handle failures), we build a system that is far more resilient and performant than any monolith. We accept "Eventual Consistency" in exchange for a system that can scale globally and fail gracefully.

Automating React App deployments to AWS with GitHub Actions and OIDC

Francisco Silvério — Sun, 01 Feb 2026 21:26:37 +0000

After deploying my personal website to AWS, I realized the need to automate the deployment process to streamline the delivery of new features. For that, you can’t go wrong with a CI/CD pipeline powered by your Git provider — in this case, GitHub and GitHub Actions.

In this article, I’ll walk through the architecture and CI/CD pipeline I use to deploy a React application to S3 + CloudFront, authenticated via GitHub Actions OIDC (no long-lived AWS credentials).

This setup is suitable for real-world projects and follows AWS and GitHub best practices.

Architecture Overview

Before diving into CI/CD, let’s clarify the infrastructure that was already in place.

Initial AWS Setup (Pre-requisites)

The following resources were already created before the pipeline was written.

1 - S3 bucket

Static website hosting enabled
Public access configured appropriately
Hosts the built React assets (index.html, /assets/*, etc.)

2 - CloudFront distribution

Origin pointing to the S3 website endpoint
Default root object: index.html
Caching enabled
Custom domain configured

3 - Name.com

Custom domain pointing to the CloudFront distribution

Once this setup is complete, the website can already be accessed via the custom domain.
The CI/CD pipeline’s job is to automate updates safely and consistently.

AWS: Configuring OIDC Authentication

1 - Create an OIDC Identity Provider

In AWS IAM:

Provider URL:

https://token.actions.githubusercontent.com

Audience:

sts.amazonaws.com

This allows AWS to trust GitHub as an identity provider.

2 - Create an IAM Role for GitHub Action

This role will be assumed by the GitHub Actions runner.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "Federated": "arn:aws:iam::<ACCOUNT_ID>:oidc-provider/token.actions.githubusercontent.com"
      },
      "Action": "sts:AssumeRoleWithWebIdentity",
      "Condition": {
        "StringEquals": {
          "token.actions.githubusercontent.com:aud": "sts.amazonaws.com"
        },
        "StringLike": {
          "token.actions.githubusercontent.com:sub": "repo:<ORG>/<REPO>:*"
        }
      }
    }
  ]
}

3 - Attach Required IAM Permissions

The role needs permissions to:

Sync files to S3
Create CloudFront invalidations

Example policy (simplified):

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Action": [
        "s3:PutObject",
        "s3:DeleteObject",
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::<BUCKET_NAME>",
        "arn:aws:s3:::<BUCKET_NAME>/*"
      ]
    },
    {
      "Effect": "Allow",
      "Action": "cloudfront:CreateInvalidation",
      "Resource": "*"
    }
  ]
}

GitHub Actions Pipeline Overview

The pipeline is split into three jobs:

install – install dependencies
build – build the React app and upload artifacts
deploy – authenticate to AWS, deploy to S3, invalidate CloudFront

This separation improves clarity, caching, and debuggability.

Job 1: Installing Dependencies

install:
  runs-on: ubuntu-latest
  steps:
    - uses: actions/checkout@v4
    - name: Install dependencies
      uses: actions/setup-node@v4
      with:
        node-version: "22.x"
        cache: 'npm'
    - run: npm ci

What this job does

Checks out the repository
Sets up Node.js 22
Uses npm ci for deterministic installs
Enables dependency caching for faster builds

This job ensures the dependency tree is valid before moving forward.

Job 2: Building the React Application

build:
  runs-on: ubuntu-latest
  needs: install
  steps:
    - uses: actions/checkout@v4
    - name: Use Node.js 22
      uses: actions/setup-node@v4
      with:
        node-version: "22.x"
        cache: 'npm'
    - run: npm ci
    - run: npm run build
    - name: Upload dist
      uses: actions/upload-artifact@v4
      with:
        name: dist
        path: ./dist

What this job does

Rebuilds the application in a clean environment
Produces a static dist/ folder
Uploads the build output as a pipeline artifact

Artifacts allow the deploy job to be fully decoupled from the build process.

Job 3: Deploying to AWS (S3 + CloudFront)

  deploy:
    needs: build
    runs-on: ubuntu-latest
    environment: aws
    permissions:
      id-token: write
      contents: read

    steps:
      - name: Download dist artifact
        uses: actions/download-artifact@v4
        with:
          name: dist
          path: dist

      - name: Configure AWS credentials
        uses: aws-actions/configure-aws-credentials@v4
        with:
          role-to-assume: ${{ secrets.AWS_ARN }}
          aws-region: ${{ vars.AWS_REGION }}
          role-session-name: ${{ vars.ROLE_SESSION_NAME}}

      - name: Deploy to S3
        run: |
          aws s3 sync dist s3://${{ vars.S3_BUCKET_NAME }} \
            --delete \
            --exact-timestamps

      - name: Invalidate CloudFront
        run: |
          aws cloudfront create-invalidation \
            --distribution-id ${{ vars.CLOUDFRONT_DISTRIBUTION_ID }} \
            --paths "/*"

What this job does

Downloads the build artifact
Authenticates to AWS
Uploads the static files to the bucket
Invalidate CloudFront's cache

Invalidating /* ensures CloudFront fetches the new version immediately.

Final Result

After every push to main:

The app is built
Assets are uploaded to S3
CloudFront cache is invalidated
The custom domain serves the latest version reliably

All without storing a single AWS secret in GitHub.

References

- GitHub Actions OIDC

- AWS IAM OIDC

- CloudFront invalidations

- aws-actions/configure-aws-credentials