10 AI Coding and Automation Workflows Worth Trying in 2026

Test-first loop

1. 1Describe the behaviourWrite down the inputs and expected outputs in plain language, including edge cases and errors.
2. 2Get tests, not codeAsk the assistant for tests only. Read them and fix any that assert the wrong thing before moving on.
3. 3Confirm they failRun the tests against the current code. A test that passes before the change proves nothing.
4. 4Ask for the minimum implementationHave it write only enough code to pass, then run the tests yourself.

Review pass

1. 1Give it the diff and the intentProvide the change, the issue it addresses and any style rules.
2. 2Ask for findings onlyRequest a list of possible bugs, security concerns and unclear logic, each tagged certain or possible. Forbid rewrites.
3. 3Triage the listDiscard noise, confirm the real findings in the code, and fix them.
4. 4Hand off to a humanA teammate still reviews the final diff.

Guarded refactor

1. 1Lock current behaviourMake sure tests cover what the code does now. Add characterisation tests where they are missing.
2. 2State the boundaryTell the assistant which files may change and which public interfaces must not.
3. 3Work in small stepsAsk for one refactor at a time, and run the full suite after each.
4. 4Compare behaviourCheck that tests, types and any benchmarks you rely on match the before state.

Docs from code

1. 1Point it at real sourceGive the assistant the actual functions or modules, not a description of them.
2. 2Request a fixed structureAsk for purpose, parameters, return values, errors and one runnable example.
3. 3Run the examplesExecute every code sample. Broken examples are the easiest errors to catch.
4. 4Have the owner read itSomeone who knows the code confirms the explanation matches intent.

CI triage

1. 1Collect the evidencePaste the failing job's log, the commit diff and the last passing run's differences.
2. 2Ask for hypothesesRequest a ranked list of likely causes and the single command that would confirm or rule out each.
3. 3Test the top hypothesisRun that command yourself and report back what happened.
4. 4Fix and re-runApply a small fix and let the pipeline prove it.

Debug loop

1. 1Reproduce firstWrite the smallest steps or test that trigger the bug.
2. 2Share the factsGive the error, the relevant code and what you already ruled out.
3. 3Ask for a diagnosis, then a fixHave it explain the cause before it proposes changes.
4. 4Confirm with the reproductionThe reproduction must now pass, and nothing else should break.

Staged migration

1. 1Read the official guideGive the assistant the vendor's own migration notes. Do not rely on its memory of an older release.
2. 2Inventory the changeAsk it to list every place in the code that the change touches, and check that list with a search.
3. 3Migrate in slicesOne module or directory at a time, each in its own reviewable change.
4. 4Run the suite on every sliceStop at the first failure and understand it.

Script workflow

1. 1Specify inputs, outputs and limitsSay what the script reads, what it writes and what it must never touch.
2. 2Ask for a dry-run modeRequire a flag that prints what it would do without doing it.
3. 3Read it line by lineLook hardest at anything that deletes, overwrites, sends or spends.
4. 4Run on a copyTry it on disposable data before the real thing.

Code reading

1. 1Start with the entry pointShare the main file and ask for a map: modules, responsibilities and how they connect.
2. 2Ask what it is unsure aboutHave it list parts it could not determine from the code given.
3. 3Trace one real pathFollow a single request or function call end to end, and verify it in a debugger or with logging.
4. 4Write down what you learnedYour own notes become the check on the next explanation.

Supervised agent run

1. 1Scope the task and the sandboxUse a branch or a throwaway environment, with no production credentials. See What is an AI coding agent? for what agents can access.
2. 2Define doneWrite the acceptance checks before the run: which tests pass, which files change.
3. 3Watch the first minutesLook at what it reads and runs early, when mistakes are cheapest to stop.
4. 4Review the whole diffRead every change, then run the checks yourself before opening a pull request.