Everyone is talking about context engineering.

Most of the conversation focuses on giving AI more: better prompts, more files, more documentation, bigger context windows.

I think we’re solving the wrong problem.

This is Part 2 of a series on engineering in the age of AI. In Part 1, I argued that as AI takes over implementation, the specification becomes the asset — and engineers are measured by how clearly they define correctness. This post is about the next step: making that correctness executable.

If AI generates the implementation and engineers define correctness, the obvious question is how.

How do you define “correct” in a way that survives AI producing five different implementations, each of which looks right?

You don’t do it in a prompt. You do it in your engineering system.

Before context engineering comes engineering discipline. And discipline, at scale, is really just standardization: the same rules applied the same way every time, enforced by machines rather than memory.

Think about what happens when your project has no automated tests, no static analysis, no accessibility checks, no performance budgets, no API contracts, no shared component library.

A large part of your “context” exists only in people’s heads.

AI can’t reliably infer unwritten rules. Worse, neither can the new hire, the contractor, or the version of you three months from now.

The more your engineering practices are standardized and automated, the less you need to explain implementation details to anyone — human or AI.

What this looks like in practice

Each of these takes a rule that usually lives in someone’s head and turns it into something a machine checks automatically.

Coding standards and static analysis

Instead of describing your conventions in a prompt, encode them.

Linters like ESLint and formatters like Prettier make style non-negotiable and invisible — the standard is the config file, not a paragraph of instructions. Type checkers like TypeScript catch whole categories of errors before anyone reviews a line.

Automated tests

A test suite is a specification you can execute — the executable spec from Part 1, made real.

Unit tests (Jest, Vitest), integration tests, and end-to-end tests (Playwright, Cypress) describe what “correct” means in a form that doesn’t drift. When AI generates an implementation, the tests tell you immediately whether it works — no need to trust that it followed your description.

Accessibility checks

Rules like “every image needs alt text” or “contrast must meet WCAG AA” shouldn’t live in tribal knowledge.

Tools like axe-core or Lighthouse’s accessibility audits enforce them in CI, so accessible output is the default rather than something you have to remember to ask for.

Performance budgets

“Keep it fast” is not a spec. A performance budget is.

Lighthouse CI, or the assertions in WebPageTest let you set hard limits — bundle size, Largest Contentful Paint, time to interactive — and fail the build when they’re exceeded. The standard enforces itself.

API contracts

Define the interface once, formally, with OpenAPI/Swagger, GraphQL schemas, or Protocol Buffers.

Contract tests (Pact) then guarantee that producers and consumers stay in sync. The contract becomes the shared source of truth instead of a shared assumption.

A standard UI component library

When “a button” means your Button component—variants, states, and accessibility already baked in—there's nothing to describe.

Design systems built with Storybook turn visual and interaction standards into reusable, verifiable building blocks.

Architecture diagrams and docs

Even structure can be standardized and checked.

Diagrams-as-code (Mermaid, PlantUML etc) keep the picture in version control.

Why this matters more with AI, not less

Instead of writing a prompt like:

“Generate code that follows our conventions, is performant, accessible, secure, and maintainable…”

you provide the specification and let your automation verify the result.

The implementation becomes almost interchangeable, because the guardrails don’t care who — or what — wrote the code.

AI is probabilistic. Your engineering system shouldn’t be.

Every standard you leave unwritten is something you’ll re-explain in every prompt, and hope the model gets right every time.

Every standard you automate is one you never have to explain again.

That’s why the biggest investment to make before adopting AI isn’t better prompts — it’s better automation.

Automation is executable context. Every test you write, every check you enforce in CI, every standard you encode is context that no longer needs to live in a prompt or someone’s memory. It’s standardized, executable, and impossible to forget.

Part 1 ended with a principle: AI generates the implementation, engineers define correctness. This is how you enforce it.

Standardize what “good” means. Automate the checks that hold the line. Only then, prompt.

Get those first two right, and context engineering becomes surprisingly simple.

When AI can generate hundreds of lines of code in seconds, what is a software engineer actually paid to do?

Over the past few weeks, I’ve been brainstorming about this and discussing it with several colleagues. We kept coming back to one question:

What skills become more valuable in a world where generating code is becoming a commodity?

History suggests that automation doesn’t reduce human value — it redefines it. Every generation has resisted a new tool because it feared losing a core skill. Instead, the skills that mattered simply moved up the value chain.

• Calculators automated arithmetic. We stopped valuing manual calculations and started valuing mathematical reasoning and problem-solving.
• Excel automated repetitive calculations, reconciliation, and reporting. The value shifted from manual bookkeeping to financial modeling, data analysis, and decision-making.
• Cloud computing automated infrastructure provisioning and operations. Instead of managing servers, engineers focused on architecture, scalability, security, reliability, and cost optimization.

AI feels like the next step in this evolution. As it becomes increasingly capable of generating code, documentation, and even tests, the value of manually writing every line of code naturally decreases. Our contribution shifts toward defining problems, providing context, designing systems, reviewing solutions, and making engineering decisions.

AI’s Fundamental Difference

Unlike the technologies before it, AI is non-deterministic.

A calculator always returns the same answer for the same equation. An Excel formula always produces the same result for the same inputs. A cloud API follows a defined contract.

AI doesn’t.

The same prompt can generate multiple implementations. Each may look correct, follow best practices, and even pass a quick review — yet one might fail under an edge case that another handles perfectly.

That leads me to a simple conclusion:

AI doesn’t make testing more important because it writes bad code. It makes testing more important because it can produce many different implementations, all of which must satisfy the same behavior.

The Specification Becomes the Asset

As AI gets better at implementation, the implementation itself becomes less valuable. The enduring asset is the specification.

Requirements, acceptance criteria, business rules, edge cases, invariants, and automated tests don’t just verify software anymore — they define what “correct” means. They become executable specifications that constrain AI-generated code and make the overall development process predictable, even when the code generation itself isn’t.

Perhaps that’s where software engineering is heading.

As AI continues to lower the cost of implementation, engineers won’t be measured by how many lines of code they write. They’ll be measured by how clearly they define the problem, how thoroughly they capture expected behavior, and how effectively they validate the solution.

AI may generate the implementation.

Engineers define correctness.