The tools have changed, even the new ones. Chat-style AI assistants became mainstream in 2023. But in 2026, we are not prompting a chatbot to explain a regex pattern or draft a commit message. We are working with agentic AI – tools like Claude Code that can navigate a file system, execute terminal commands, and modify a codebase directly. Tools that don’t just answer you, but do the work for you.
Our tech firm builds bespoke software, automation and integration solutions including an e-commerce product automation platform. Over the past year, we have embedded Claude Code into our daily engineering workflows. Technical capability was not the issue we faced; the challenge was getting the wider team to stop treating it like Stack Overflow and start treating it like a junior engineer sitting at the next desk.
Here is what we learned, including a concrete CI/CD example with numbers.
The prompt problem
When engineers first get access to an agent that can run shell commands and edit files autonomously, there is a natural adjustment period. Most people default to asking isolated questions. “How do I configure environment secrets in a GitHub Actions workflow?” A valid question, but it only scratches the surface.
The real value is when you let the agent handle a full workflow end to end: reading your existing configurations, understanding your conventions, generating new files, and writing the documentation to go with them. Getting comfortable with that level of delegation is a skill, and like any skill, it needs deliberate practice.
Case study: standardising CI/CD workflows across microservices
We run a microservices architecture for our e-commerce SaaS platform. The system has separate services for supplier data ingestion, product transformation, Shopify synchronisation, and API orchestration – each with its own GitHub Actions CI/CD pipeline. We wrote about the full architectural breakdown separately, but the relevant point here is that every service needs its own build, test, and deployment workflow and those workflows need to stay consistent.
Every time we added a new service, the same issue appeared. A senior engineer would copy an existing workflow YAML, update the service name and build path, reconfigure environment secrets for staging and production, adjust the test and deployment steps, then spend another stretch writing up the pipeline documentation. Across our projects, this reliably cost about three hours of focused work per service.
We pointed Claude Code at the repository and gave it a structured objective:
”’Read the GitHub Actions workflows in .github/workflows/ and the service structure in src/. Identify our naming conventions, build steps, test configuration, environment variable patterns, and deployment targets. Generate a complete CI/CD workflow for a new service called supplier-adapter-v2, following the same patterns. Include staging and production deployment jobs with the correct environment references and approval gates.”’
Claude Code scanned the existing workflows, traced the patterns across our `api-gateway`, `supplier-ingest`, and `shopify-sync` pipelines, and produced a complete workflow file. Here is a trimmed excerpt of what it generated:
name: Deploy supplier-adapter-v2
on:
push:
branches: [main]
paths: ['src/SupplierAdapterV2/**']
pull_request:
branches: [main]
paths: ['src/SupplierAdapterV2/**']
env:
DOTNET_VERSION: '8.0.x'
PROJECT_PATH: 'src/SupplierAdapterV2'
jobs:
build-and-test:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-dotnet@v4
with:
dotnet-version: ${{ env.DOTNET_VERSION }}
- run: dotnet restore ${{ env.PROJECT_PATH }}
- run: dotnet build ${{ env.PROJECT_PATH }} -c Release --no-restore
- run: dotnet test ${{ env.PROJECT_PATH }}.Tests -c Release --no-build
deploy-staging:
needs: build-and-test
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main'
environment: staging
steps:
- uses: actions/checkout@v4
- uses: actions/setup-dotnet@v4
with:
dotnet-version: ${{ env.DOTNET_VERSION }}
- run: dotnet publish ${{ env.PROJECT_PATH }} -c Release -o ./publish
- uses: azure/webapps-deploy@v3
with:
app-name: ret-supplier-adapter-v2-staging
package: ./publish
It matched our naming conventions, picked up the .NET 8 build chain, replicated the path-filtered triggers we use to avoid unnecessary builds, and structured the environment-gated deployments correctly. After a quick review, we sent back one refinement prompt to correct a deployment slot name. Total time from first prompt to merged pull request: about 25 minutes.
Our team adds or substantially refactors roughly three to four service pipelines per month across projects. At about two and a half hours saved per pipeline, that works out to around 30 hours recovered per quarter – time that goes back into feature work rather than YAML wrangling.
A three-step framework for team adoption
If you are rolling out agentic tools to your engineering team, the following framework has worked well for us.
1. Context first, prompt second
An AI agent is only as useful as the context it can access. Before asking it to generate anything, point it at the right directories and documentation. Think of it like onboarding a new contractor – you would not hand someone a Jira ticket on day one without showing them the repo structure first.
In practice, this means starting sessions with something like “read the files in `.github/workflows/` and `docs/pipeline-guide.md` before doing anything.” This step alone dramatically improves first-draft quality and cuts the back and forth.
2. Iterate with the agent, not around it
When you spot an error in the output, the instinct is to jump into the file and fix it yourself. That works, but it breaks the feedback loop. Describe what is wrong and let the agent make the correction. This keeps momentum with the machine and sharpens your prompting instincts over time. Each cycle makes the next one faster.
We found that engineers who committed to this loop for a fortnight stopped reverting to manual edits almost entirely. Their prompts got sharper, the context got richer, and the drafts started landing closer to production-ready on the first pass.
3. Human review stays in the loop
Speed means nothing if it introduces regressions. Every piece of output from an agent – whether it is a CI/CD workflow, an infrastructure template, or a documentation page – goes through the same review process as human-written code. Same pull request template, same approval requirements.
This serves two purposes. First, it catches the occasional hallucinated config value or subtly wrong default. Second, and this matters more for adoption, it builds trust. When the rest of the team sees that agent output goes through the same gate as everything else, they become more comfortable delegating larger tasks to it.
What makes this practical today
The latest AI coding tools can hold context across dozens of files in a single session. Claude Code can trace a build configuration through multiple workflow files, understand how a change in one pipeline affects shared environment variables in another, and flag inconsistencies before they surface in staging.
For teams running microservice architectures, this means accumulated friction (inconsistent workflow patterns, outdated build configurations, missing pipeline documentation) can be addressed systematically rather than in ad hoc bursts during quiet sprints.
Getting started
Pick a repetitive task that currently takes a senior engineer two or more hours. Workflow generation, configuration standardisation, and documentation updates are all good candidates. Run it through Claude Code with a clear, structured prompt. Review the output carefully. Refine. Repeat.
The tooling is ready. The adoption curve responds well to a structured approach, and the payoff compounds quickly once your team builds the habit.
