TDD in the Age of AI: Who Tests the Tests?

Step 1: I write the spec (tests)#

type Result<T, E> = { ok: true; value: T } | { ok: false; error: E };

function ok<T>(value: T): Result<T, never> {
	return { ok: true, value };
}

function err<E>(error: E): Result<never, E> {
	return { ok: false, error };
}

class PasswordError {
	constructor(
		public readonly code: string,
		public readonly message: string
	) {}
}

describe("PasswordValidator", () => {
	it("should accept strong passwords", () => {
		const result = PasswordValidator.validate("Str0ng!Pass#2026");
		expect(result.ok).toBe(true);
	});

	it("should reject passwords under 12 characters", () => {
		const result = PasswordValidator.validate("Sh0rt!");
		expect(result.ok).toBe(false);
		if (!result.ok) {
			expect(result.error.code).toBe("TOO_SHORT");
		}
	});

	it("should require uppercase, lowercase, digit, and special character", () => {
		const noUpper = PasswordValidator.validate("alllowercase1!");
		expect(noUpper.ok).toBe(false);
		if (!noUpper.ok) {
			expect(noUpper.error.code).toBe("MISSING_UPPERCASE");
		}

		const noDigit = PasswordValidator.validate("NoDigitHere!");
		expect(noDigit.ok).toBe(false);
		if (!noDigit.ok) {
			expect(noDigit.error.code).toBe("MISSING_DIGIT");
		}

		const noSpecial = PasswordValidator.validate("NoSpecialChars9");
		expect(noSpecial.ok).toBe(false);
		if (!noSpecial.ok) {
			expect(noSpecial.error.code).toBe("MISSING_SPECIAL");
		}
	});

	it("should reject common passwords", () => {
		const result = PasswordValidator.validate("Password123!");
		expect(result.ok).toBe(false);
		if (!result.ok) {
			expect(result.error.code).toBe("TOO_COMMON");
		}
	});

	it("should reject passwords with repeated sequences", () => {
		const result = PasswordValidator.validate("abcabcABCd1!");
		expect(result.ok).toBe(false);
		if (!result.ok) {
			expect(result.error.code).toBe("REPEATED_SEQUENCE");
		}
	});
});

The tests define behavior, expected error codes, and the edge cases I care about. That is the specification AI needs.

Step 2: AI generates the implementation#

I paste the tests into my AI assistant and say: “Make these tests pass.”

It produces:

class PasswordValidator {
	private static readonly COMMON_PASSWORDS = [
		"password",
		"password123",
		"123456789",
		"qwerty123",
		"admin123",
		"letmein1",
		"welcome1",
		"password1!",
		"iloveyou",
		"monkey123",
	];

	private static readonly MIN_LENGTH = 12;

	static validate(password: string): Result<string, PasswordError> {
		if (password.length < PasswordValidator.MIN_LENGTH) {
			return err(
				new PasswordError(
					"TOO_SHORT",
					`Password must be at least ${PasswordValidator.MIN_LENGTH} characters`
				)
			);
		}

		if (!/[A-Z]/.test(password)) {
			return err(
				new PasswordError(
					"MISSING_UPPERCASE",
					"Password must contain at least one uppercase letter"
				)
			);
		}

		if (!/[a-z]/.test(password)) {
			return err(
				new PasswordError(
					"MISSING_LOWERCASE",
					"Password must contain at least one lowercase letter"
				)
			);
		}

		if (!/[0-9]/.test(password)) {
			return err(
				new PasswordError(
					"MISSING_DIGIT",
					"Password must contain at least one digit"
				)
			);
		}

		if (!/[!@#$%^&*()_+\-=\[\]{};':"\\|,.<>\/?]/.test(password)) {
			return err(
				new PasswordError(
					"MISSING_SPECIAL",
					"Password must contain at least one special character"
				)
			);
		}

		const lowerPassword = password.toLowerCase();
		const isCommon = PasswordValidator.COMMON_PASSWORDS.some(
			(common) =>
				lowerPassword.includes(common.toLowerCase()) ||
				common.toLowerCase().includes(lowerPassword)
		);
		if (isCommon) {
			return err(
				new PasswordError("TOO_COMMON", "Password is too common or predictable")
			);
		}

		if (/(.{3,})\1{1,}/i.test(password)) {
			return err(
				new PasswordError(
					"REPEATED_SEQUENCE",
					"Password contains repeated sequences"
				)
			);
		}

		return ok(password);
	}
}

These tests would now pass against this implementation.

Step 3: I review and refine#

The structure and validation logic are reasonable, but the review finds three problems:

• COMMON_PASSWORDS is hardcoded and small. Production needs a larger dataset. A bloom filter can reduce memory use, but its false positives can reject valid passwords.
• The special-character regex has unnecessary escapes.
• The repeated-sequence regex /(.{3,})\1{1,}/i needs edge-case checks.

The tests let me review the implementation against a contract I wrote. Without them, I would be judging code quality without an objective measure of correctness.

Pattern 1: Test-First Prompting#

Start with tests, then prompt AI: “Make these tests pass.” The tests act as the specification and acceptance criteria.

describe("Email", () => {
	it("should normalize to lowercase", () => {
		const result = Email.create("[email protected]");
		expect(result.ok).toBe(true);
		if (result.ok) {
			expect(result.value.getValue()).toBe("[email protected]");
		}
	});
});
// Prompt: "Implement Email to make these tests pass"

Pattern 2: Specification Testing#

Write tests that describe domain rules. Let AI figure out the architecture.

describe("Order", () => {
	it("should reject orders exceeding credit limit", () => {
		const order = Order.create(customerId, CreditLimit.usd(100)).value!;
		order.addLine("Widget", 1, Money.usd(75));

		const result = order.addLine("Gadget", 1, Money.usd(50));
		expect(result.ok).toBe(false);
	});
});
// AI decides: class-based? function-based? How to structure it.
// You decide: what the rules are.

Pattern 3: Mutation Testing for AI Code#

Change the implementation slightly. Do the tests catch it? If not, your tests aren’t specific enough. Your AI-generated code could silently regress.

Pattern 4: The Trust Boundary#

I write tests for domain logic and critical paths. I let AI write tests for utility functions and boilerplate. The rule: the more important the behavior, the more human involvement the tests need.

Can AI write tests for you?#

AI can draft tests, but critical behavior needs human-written tests. AI-generated tests often verify implementation details, break during refactoring, and miss real bugs. Write the specification; let AI implement it.

How does TDD work with AI coding assistants?#

The cycle shifts from “human writes test, human writes code” to “human writes test, AI writes code, human reviews.” Red-Green-Refactor remains intact; AI handles Green while you specify intent and review the output.

Do you still need TDD with AI?#

Yes. Tests provide an objective check on AI-generated code. TDD turns tests written before implementation into acceptance criteria and prevents false confidence from weak tests.