Treating AI as a Team Member: Bootstrapping Codex for CI/CD-Aware Development

Over the last few weeks I’ve been playing with something new:
not a new framework, not a new Agile process – but a new team member.

A very fast, very literal, slightly overconfident team member called Codex.

I’m using it on a small side project called PipelineSage – a Spring Boot and Gradle service that analyses CI pipeline failures and returns:

• a short human-readable summary,

• a failure category, and

• some suggested next steps for the engineer.

Underneath that, the real experiment is this:

How do we build golden paths for AI-assisted development that feel as reliable as good CI/CD, rather than like a random chatbot bolted onto the side?

It turns out the answer looks a lot like Agile transformation used to:
make the rules explicit, make them visible, and put them in the same place as the work.

---

The problem: clever models, forgetful tools

I’ve been jumping between Cursor, IntelliJ AI and various GPT models.

They’re all impressive. But I kept running into the same issues:

• Different tools “remember” different versions of my domain model.

• One happily invents new enum values.

• Another rewrites the CI pipeline and breaks the failure analysis stage.

• Free tiers silently throttle me halfway through a refactor.

It reminded me of badly aligned Agile teams:
everyone using the same words, but with completely different mental models.

At some point I realised the real problem:

All of the important context lived in chat history, not in the codebase.

You wouldn’t describe a critical API only in a meeting and never write it down.
But that’s effectively what I was doing with the AI.

So I stopped.

---

Step 1 – Put the AI’s “mental model” in the repo

The first change was simple: create a single project context file and treat it like any other artefact.

I added:

prompts/system-project-context.md

# PipelineSage – System Project Context

Project:
- Spring Boot 3, Java 21, Gradle (Groovy), GitLab CI
- POST /api/analysis:
  - LogAnalysisRequest: logs, stage, jobName, commitId
  - LogAnalysisResult: summary, category, suggestedFix, confidence?, links?

FailureCategory enum (canonical):
- TEST_FAILURE
- BUILD_CONFIGURATION
- INFRASTRUCTURE
- DEPENDENCY
- SECRET_OR_AUTH
- OTHER

CI shape:
- Stages: build → test → package → analyze_failure
- analyze_failure:
  - when: on_failure, allow_failure: true
  - send JSON LogAnalysisRequest to /api/analysis
  - never block the main pipeline

This file is now the source of truth for:

• The main endpoint and its contract.

• The official list of failure categories.

• The shape and rules of the CI pipeline.

If I change the design, this file changes too – just like any other spec.

---

Step 2 – Teach Codex to join the team

Codex in the shell is fast, clean and brutally honest.
It also starts every session with no context at all.

So I wrapped it in a tiny script that “onboards” it whenever I start:

scripts/codex.sh:

#!/usr/bin/env bash
set -euo pipefail

REPO_ROOT="$(git rev-parse --show-toplevel 2>/dev/null || pwd)"
CONTEXT_FILE="$REPO_ROOT/prompts/system-project-context.md"

if [ ! -f "$CONTEXT_FILE" ]; then
  echo "❌ Context file not found: $CONTEXT_FILE" >&2
  exit 1
fi

echo "🚀 Starting Codex in PipelineSage mode"
echo "   Repo:    $REPO_ROOT"
echo "   Context: $CONTEXT_FILE"
echo

PROMPT="$(cat "$CONTEXT_FILE")"

PROMPT="$PROMPT

---

You are now in the PipelineSage project session.

General rules:
- Be brief and opinionated.
- Assume: Java 21, Spring Boot 3.x, Gradle, GitLab CI.
- Respect the FailureCategory enum and JSON contracts above.
- Keep changes PR-sized and coherent; update/suggest tests when behaviour changes.
- Never hard-code secrets or URLs; use env/config.
- For CI, keep .gitlab-ci.yml valid and make AI analysis non-blocking.
"

codex \"$PROMPT\"

Now my flow looks like this:

./scripts/codex.sh                 # start Codex “in project”
cat .gitlab-ci.yml | codex edit    # adjust analyze_failure job
cat LlmAnalysisService.java | codex edit   # add retries + fallback

Because the context lives in the repo, Codex:

• Stops inventing new failure categories.

• Respects the POST /api/analysis contract.

• Understands that the analyze_failure stage is allowed to fail, but must never block CI.

It behaves much more like a new team member who has read the docs, rather than a very clever stranger.

---

Step 3 – Make the pattern reusable

The nice side-effect of this approach is that it doesn’t just help Codex.

Any tool can plug into the same model:

• Cursor can be pointed at prompts/system-project-context.md and the docs.

• IntelliJ AI can use the same file as its “project context”.

• ChatGPT (the one I’m using to write this) reads from the same contracts.

When the design evolves, I don’t need to “retrain” each tool by hand.
I update the docs and the prompt file, and they all follow.

In Agile terms, I’ve gone from:

“We all kind of remember the process”

to:

“We have a lightweight working agreement written down, and we actually use it.”

---

Why this matters for real teams

PipelineSage is a small project, but the pattern feels very familiar from Agile coaching days:

• Start by making expectations explicit.

• Put them somewhere visible and versioned.

• Use them to align behaviour across the whole system.

For AI-assisted development, that translates into:

• Context as code.

• Prompts as artefacts, not disposable chat.

• AI tools as replaceable clients of a shared model.

If you’re experimenting with AI in your engineering teams, you don’t have to solve everything at once. A few simple steps go a long way:

1. Write down the key contracts and constraints in your repo.

2. Create a small project-context file that any assistant can read.

3. Add tiny bootstrap scripts (like codex.sh) so new tools start in the right mode.

Just like Agile, it’s a series of small steps that add up.

In my case, the biggest win was psychological: Codex stopped feeling like a random magic trick and started to feel like what it really is:

A very fast junior team member, working inside a system of clear agreements.

And that’s a team I know how to work with.