Implementation Guide

A practical, step-by-step plan for introducing and embedding the manifesto and framework in a team or organisation.

This is not a process. It is a way of working. The goal is to make the principles visible, repeated, and lived — not laminated to a wall.

🚦 Start here: minimum viable adoption

The full rollout below is a menu, not a mandate. If your team is under pressure and wants to start this week, do just these:

• Non-negotiables (the parts that are not optional): a named human owner for every change; human-led reasoning for security, compliance, and irreversible work; and protecting early-career learning.
• This week: add an AGENTS.md where your tool supports it (otherwise use its native instruction file) and one CONTEXT.md to your busiest repo, then adopt one review habit — ask the author why, not just what.
• Later, when it earns its place: the intro session, shared prompt libraries, quarterly reviews, and the rituals below.

Everything else in this guide is there to help; adopt it as it proves useful, not because it is listed.

1️⃣ Start with the why

Open with the core truth:

• The real risk is not replacement — it is deskilling. This framework exists because of it.
• Early-career engineers are the most exposed. The pipeline from junior to senior to principal is what is at stake.
• AI is changing how software is built.
• Engineering has always evolved with its tools.
• This manifesto protects the craft and the people who practise it.

Frame the conversation around growth, not fear.

2️⃣ Tell the story of continuity

Connect AI explicitly to the long lineage of assistive tools — autocomplete, IntelliSense, refactoring tools, static analysis, code generation. This grounds the change in familiarity and reduces anxiety. AI is a bigger step on the same ladder, not a different one.

3️⃣ Introduce the manifesto first

Present the manifesto as:

• A statement of what we believe.
• A commitment to engineer growth.
• A cultural anchor and shared philosophy.

This is the emotional, identity-driven part. Resist the urge to jump straight to behaviours.

4️⃣ Introduce the framework second

The framework is the how: five pillars, simple enough to remember, actionable enough to guide decisions. Emphasise that it is not a process to comply with — it is a way of working to internalise.

5️⃣ Run a team intro session

A suggested 30–45 minute format:

• 5 min — The why. Deskilling risk, continuity of tooling, the opportunity ahead.
• 5 min — The manifesto. Walk through each line. Ask: "What does this mean for us?"
• 15 min — The framework. Walk through the five pillars with examples from your own codebase.
• 10–15 min — Discussion. As a team, talk through:
  • Where are we strong?
  • Where are we weak?
  • What is one thing that changes tomorrow?

Capture the answers. They become your team's first commitments.

Pitches you can reuse

The 30-second version:

AI is changing how software is built faster than any tool we have seen before. The biggest risk is not that it replaces engineers — it is that it quietly stops them from becoming senior ones. Human-First Engineering is a lightweight manifesto and framework that lets us go faster and keep growing engineers.

The two-minute version:

For decades, every new tool — autocomplete, IntelliSense, refactoring, static analysis — has made engineers faster. AI is the next step on that same ladder, but it is a much bigger step.

For the first time, the bottleneck is not writing code. It is understanding it. We can ship faster than ever, and it has never been easier to ship things we do not fully understand.

That is a problem for code quality, but it is a bigger problem for people. If we are not deliberate, junior engineers will skip the very experiences that build judgement. Senior engineers will drift into reviewing output rather than shaping solutions. The pipeline from junior to senior to principal will quietly erode.

Human-First Engineering is our response. A short manifesto on what we believe, a five-pillar framework on how we work, and a practical toolkit for embedding both. The point is simple: we use AI to grow engineers, accelerate delivery, and protect quality — not to trade one off against the other.

The one-line version:

Think first. Own the output. Grow through AI, not around it. Use AI intelligently. Trust AI, but verify everything.

Framings to avoid

• "AI changes everything." It changes a lot, but the framing produces fear and false novelty. Engineering principles are intact.
• "Just use AI for everything." Encourages exactly the deskilling pattern we are trying to prevent.
• "AI will replace engineers." It will not. But careless use will erode the engineers we have.
• "This is mandatory." The framework works because it is internalised, not because it is enforced. Frame it as a way of working, not a process to comply with.

6️⃣ Empower seniors and principals to lead

Senior engineers are where culture becomes durable. Charge them explicitly with:

• Modelling the behaviours.
• Mentoring juniors in AI-assisted workflows.
• Curating shared instruction files, prompts, and skills.
• Protecting foundational learning opportunities.
• Calling out — kindly — when AI output is shipped without understanding.

Make this part of the role expectation, not an extracurricular favour.

7️⃣ Embed into existing rituals

Do not add new ceremonies. Weave the framework into ones you already run.

Ritual	Prompt to add
Design reviews	Did we think before we generated?
Code reviews	Can the author explain every significant decision?
Onboarding	Where is our instruction file? Where is our CONTEXT.md and prompt library?
Retrospectives	Are we growing through AI, or just faster because of it?
Architecture discussions	Did we use AI to explore options, or to decide for us?
Performance conversations	What evidence shows this engineer's judgement is growing, not just their output?
Incident reviews	Did anyone ship something they did not fully understand?

8️⃣ Invest in the tooling layer

The framework only works if the tooling around it is in good shape. As a baseline, every team should have a small, named set of artefacts — and it helps to keep the vocabulary straight:

• CONTEXT.md per project — the small, always-on project memory (goals, state, constraints) that links out to the rest.
• An instruction file per project — the standing AI behaviour and conventions, kept short and current.
• ARCHITECTURE.md and a decision log (DECISIONS.md / ADRs) — loaded on demand, holding the why so it outlives the session.
• A prompt library — reusable task prompts that have proven to work.
• Model and data guidance — which models are approved and when, and what must never go into a prompt (secrets, credentials, regulated data).
• A named owner for each of the above.

These are small artefacts. They have an outsized effect on quality.

9️⃣ Review quarterly

AI evolves fast. Schedule a short, recurring review to ask:

• What is working?
• What is not?
• Where are we seeing deskilling?
• Where are we seeing genuine acceleration?
• What needs to change in our manifesto, framework, or tooling?

Keep the framework alive. A static manifesto in a fast-moving discipline becomes a museum piece.

🔟 Celebrate the right things

Reinforce culture by highlighting:

• Juniors who show strong reasoning, not just shipping speed.
• Seniors who mentor effectively and visibly.
• Teams who use AI intentionally.
• Concrete examples of think first, own the output.
• Cases where verification caught an AI error before it shipped.

Repetition builds belief. Repeat the one-line summary often:

Think first. Own the output. Grow through AI, not around it. Use AI intelligently. Trust AI, but verify everything.

📝 A final note

This is not finished work. It is a starting position for an industry that is changing under our feet. Take what is useful, adapt the rest, and share back what you learn. The engineers we grow today are the senior engineers of the next decade — and it is on all of us to protect that.