World Model Readiness
Engraved team-functions instrument

For your team

Teams by Function

Module · How AI-written code enters your repo

The Engineering Team AI Check

Your team ships more code than it used to, and a growing share of it was drafted by a model. That is fine, until the day something breaks and nobody can say who wrote the line or whether anyone read it. This module checks the five habits that keep AI-assisted engineering honest: review discipline, test coverage on generated code, security scanning, clear ownership, and the prompts and configs that shape it all living in the repo.

Question 1 of 5 · AI code gets reviewed

Does AI-generated code get the same review as anything a human wrote?

A model produces plausible code fast, which makes it easy to wave through. The failure mode is a reviewer skimming a large diff because it looks finished. Same bar, same scrutiny, regardless of who or what typed it.

Question 2 of 5 · Generated code is tested

Does the code your team generates ship with tests that actually exercise it?

Models are happy to write both the code and the tests, and tests that were written to pass can hide the bug they should catch. The question is whether generated logic carries real coverage a human trusts, not green checkmarks the model produced to satisfy itself.

Question 3 of 5 · Security scanning runs

Does generated code pass through security scanning before it merges?

Models reproduce the vulnerable patterns they learned: hardcoded secrets, injectable queries, outdated dependencies pulled in without a thought. Automated scanning in the pipeline catches the common cases that a tired reviewer at speed will miss.

Question 4 of 5 · Someone owns the module

When AI writes a module, does a named human own it afterwards?

Code that no person understands is code no person can fix at 3am. Ownership means a named engineer who can explain the module, extend it, and answer for it, not a git blame that points at a prompt. Generation does not transfer understanding by itself.

Question 5 of 5 · Prompts live in the repo

Are the prompts and AI configs your team relies on versioned in the repo?

If the prompt that generates your code or the config that governs an AI feature lives in someone's chat history, you cannot review it, roll it back, or reproduce a result. Prompts and model configs are source: they belong in version control with everything else that shapes behaviour.

For the statistics · one click each

Three questions for the public picture

These do not affect your score. They feed the anonymised, aggregated statistics; groups under 8 respondents are never shown.

How many engineers are on your team?

1 to 3
4 to 8
9 to 20
Over 20

What share of your team uses an AI coding assistant on most days?

Under a quarter
A quarter to half
Half to most
Nearly everyone
We do not track it

Roughly what share of code merged last month was AI-drafted?

Under 10 percent
10 to 30 percent
30 to 60 percent
Over 60 percent
We cannot tell

Your context

Used to calibrate the report. Company size and sector remain in the anonymized dataset; your email does not.

What the five levels look like

Every dimension in this assessment is scored 1 to 5. This is what the levels mean, dimension by dimension. The graded report diagnoses where your own answers land and what to do about it.

AI code gets reviewed

  1. 1No review
  2. 2Skimmed quickly
  3. 3Reviewed like normal
  4. 4Reviewed more closely
  5. 5Extra scrutiny, enforced

At the low end: Unreviewed AI code is a stranger committing directly to your main branch. Route every generated change through the same pull request and approval your team already uses for human work. What good looks like: Holding AI code to a higher bar than hand-written code is the right instinct while trust is still forming. Keep the practice as volume grows; the temptation to rubber-stamp rises with the diff count.

Generated code is tested

  1. 1No tests
  2. 2Model wrote tests
  3. 3Some human tests
  4. 4Coverage required
  5. 5Coverage plus review

At the low end: Generated code with no tests is a guess you have promoted to production. Require the same coverage you would demand of any change touching the same path. What good looks like: Real coverage that a person reviewed is what lets your team accept AI speed without inheriting AI blind spots. Keep watching for tests that pass by describing the bug rather than catching it.

Security scanning runs

  1. 1No scanning
  2. 2Manual, occasional
  3. 3Scanned sometimes
  4. 4Scanned in pipeline
  5. 5Blocking, enforced gate

At the low end: Generated code merges faster than a human can audit it, so the audit has to be automated. Put a scanner in the pipeline this month, starting with secrets and dependency checks. What good looks like: A blocking scan that every change must clear is exactly the backstop AI velocity needs. Keep the rules current; the vulnerable patterns a model favours shift as its training does.

Someone owns the module

  1. 1Nobody owns it
  2. 2Whoever prompted it
  3. 3Loose ownership
  4. 4Named owner
  5. 5Owner who understands it

At the low end: A module nobody owns is technical debt with the lights off. Assign a named engineer to every generated component who can maintain it as if they had written it themselves. What good looks like: An owner who genuinely understands the module closes the gap between generating code and comprehending it. Protect that understanding through handovers; ownership that lapses is how orphaned code accumulates.

Prompts live in the repo

  1. 1In chat histories
  2. 2On someone's laptop
  3. 3Shared informally
  4. 4In the repo
  5. 5Versioned and reviewed

At the low end: A prompt in a chat window is a build input you cannot audit or reproduce. Move the prompts and configs that shape your output into the repo where the rest of your source lives. What good looks like: Versioned, reviewed prompts and configs mean your AI-shaped behaviour is as reproducible as your code. Treat prompt changes like code changes; a quiet edit can shift output as much as a logic change.