/skill

AI-First Engineering

This skill comes from ECC. Credit goes clearly and fully to the original author.

Use this skill when a team uses AI to plan, write, review, test, or ship code.

Main Rules

1. A clear plan matters more than typing speed.
2. Good tests matter more than personal trust.
3. Review how the whole system acts, not just how the code looks.
4. A person must own each change, even when AI wrote it.
5. Small changes are safer and easier to check.

Before Writing Code

Write down:

• The goal
• What is in scope
• What is out of scope
• Clear rules for success
• Files or parts that may change
• Known risks
• A safe way to undo the change

If the task is not clear, stop and ask for more facts. Do not let the AI guess about key product rules, user data, money, access, or safety.

Code Design

Choose designs that are easy for people and AI agents to follow:

• Clear parts with clear jobs
• Stable rules between parts
• Typed inputs and outputs
• Tests that give the same result each time
• Few hidden side effects
• Names that say what things do
• Short and direct control flow

Do not depend on secret rules, file order, global state, or facts that exist only in a person's head.

Keep key rules near the code they control. Write down any rule that is not clear from the code.

Code Review

Check for:

• Old behavior that may break
• Wrong safety or access rules
• Lost, mixed, or damaged data
• Bad input and empty input
• Missing values
• Very large values
• Repeat calls
• Two tasks changing the same data
• Slow or failed services
• Timeouts and retries
• Half-finished work
• Error messages that hide the cause
• Unsafe logs with private data
• Safe release and rollback steps
• Changes that break old users or old data

Spend little review time on style rules that tools already check. Spend more time on real behavior and risk.

Never approve code only because it builds, looks clean, or has tests. Read the test cases. Make sure they prove the right behavior.

Team Skills

A strong engineer on an AI-first team can:

• Split a vague task into clear steps
• Set success rules that can be checked
• Give the AI short and exact instructions
• Write tests that catch real bugs
• Check AI output instead of trusting it
• Keep safety rules during time pressure
• Explain risks in plain words
• Stop a release when proof is weak

Judge results by safe, useful work. Do not judge people by how much code they make.

Test Rules

AI-written code needs a high test bar.

Require:

• Tests for the part that changed
• Tests for old behavior that must stay
• Clear tests for edge cases
• Checks where two parts meet
• Tests for expected failures
• Tests for retries when retries exist
• Tests for access rules when data is private
• Tests for old data when formats change

Tests must not depend on live web calls, random timing, or shared state. Use fixed test data. If time or random values matter, control them in the test.

A bug fix must include a test that fails before the fix and passes after it.

Release Rules

For a risky change:

1. Ship it to a small group first.
2. Keep the old path ready when possible.
3. Check clear signs of success or failure.
4. Stop or undo the change if a safety limit is hit.
5. Record what changed and who owns the next step.

Do not mix a large cleanup with a new feature. Split them so each change is easy to review and undo.

When AI Output Is Incomplete

Stop and fix the plan if the AI:

• Changes files outside the task
• Removes checks without a clear reason
• Makes up a tool, field, or rule
• Hides errors
• Skips tests
• Copies the same rule into many places
• Adds a new package without need
• Changes public behavior without warning

Keep good parts only after they are checked. Do not patch many weak guesses into one large change.

Usage Example

Task: Add a retry when a payment service times out.

Plan:

• Retry only on a timeout.
• Try no more than two extra times.
• Do not retry a card decline.
• Use the same request key for every try.
• Keep the current error after all tries fail.
• Add tests for success, timeout, decline, and repeat calls.
• Release behind a switch so it can be turned off.

Review:

• Can a retry charge the user twice?
• Is the request key saved and reused?
• Are private payment details kept out of logs?
• Does the code stop after the retry limit?
• Does old payment behavior still work?
• Can the change be turned off without a new release?

Accept the change only when the code and tests prove each rule.