ai-coding

Writing a requirement in Rules does not mean an Agent will follow it. Rules can be forgotten or skipped, and even if the Agent claims to have followed them, the result remains unconfirmed without verification. Turning checkable rules into mandatory checks that block further progress on failure reduces reliance on the executor's voluntary compliance.

For example, a project may prohibit Controllers from accessing Repositories directly. A reminder in Rules may still be ignored, and functional tests may pass despite the violation. Encoding this dependency rule in an architecture check and requiring it to pass before merging blocks that violation:

Controller → Repository           Check fails; merge blocked
Controller → Service → Repository  Passes this dependency check

A read-only database account is more direct. A rule prohibiting data changes can still be violated. If the account's effective privileges on the target tables allow only reading, the database rejects direct attempts to modify those tables through that account. The permission restriction remains effective even if the Agent forgets the instruction.

This reliability has a defined scope: the architecture check blocks only the dependency violations it covers, and read-only privileges restrict the corresponding operations through that account. Checks must actually run, and failure must block further progress. Printing a warning while still allowing a merge does not enforce the rule.

When the main effort shifts from production to verification, making automatically checkable requirements mandatory can reduce the burden of manual verification.

I used to spend most of my development time writing code. Once a Coding Agent could produce code quickly, review and testing took up more of my time. With AI doing most of the production work, my focus shifted to verifying the result.

Verification also includes checking for missing requirements. Even if AI writes both the code and the tests and every test passes, a requirement may be absent from both. As long as I am responsible for accepting the result, I still need to check it against the requirements. Faster code generation and test execution cannot replace that check.

Translation workflows that use a machine for the first draft and a human for revision follow a similar division of work: the machine produces the translation, and the person checks whether it conveys the original meaning accurately and fully.

Requirements that can be checked automatically can become mandatory checks in the workflow. This applies the idea that enforcement constrains an executor more reliably than voluntary compliance and reduces some of the manual verification work.

Code can show an Agent what is currently implemented, but it may not explain why a particular approach was chosen or why a feature was deferred. Recording those reasons in idea, PRD, spec, design, decision, and plan documents from the start, and linking the documents together, gives the Agent access to the original reasoning during later reviews, debugging, or feature work. This reduces the need to infer intent from the code’s structure.

For example, an Agent taking over the login module three weeks later can identify the authentication library from the code, but may not learn why enterprise SSO was initially deferred. Preserving that reason in the documents makes it less likely to mistake a temporary constraint for a lasting product principle. Using one name for the same concept across documents and code also reduces missed information caused by different names when searching the chain.

Maintaining consistency requires distinguishing current requirements from historical decisions. If the project later decides to support enterprise SSO, a new decision document can record why the choice changed and identify the earlier decision it replaces. The old document keeps its original reasoning, is marked as archived or superseded, and links to the new decision. This preserves the history of the change while making the current decision identifiable.

This approach adds ongoing work to check code against documentation. When requirements and implementation change, the relevant descriptions, decision statuses, and replacement links need maintenance. Without that work, old documents can mislead the next Agent. As the main effort shifts to verifying whether outputs meet requirements, documents can provide acceptance criteria, but those criteria also need to be checked for continued validity.

When implementing an unfamiliar feature by hand, getting stuck or encountering errors often forces people to consult documentation and understand the mechanism before proceeding. Learning happens as part of completing the task. Once AI can perform those steps, people may obtain a usable result without going through the process that would have prompted learning.

People without a software development background may also build software through Vibe Coding and check whether it meets their requirements by using it. Where this is a sufficient way to evaluate the result, they can confirm that the software does what they need without learning its underlying principles. As the main work shifts to verifying whether output meets requirements, learning to evaluate a result and learning to implement it become activities that can happen separately.

Under pressure to finish, people can move on once the result passes acceptance checks, without spending more time asking why it works. Continued learning then requires deliberate effort: asking about the implementation, explaining the mechanism in their own words, or making understanding part of the completion criteria. Delegating implementation and debugging to AI over time may reduce opportunities to learn new skills and practise existing ones. Gaps in those abilities may become apparent when AI cannot solve a problem.

What becomes optional here is learning the implementation principles. Understanding the requirements remains essential to acceptance. When judging correctness requires knowledge of internal mechanisms, software that appears to work is insufficient evidence, and that knowledge remains necessary for effective verification.

Writing a requirement in Rules does not mean an Agent will follow it. Rules can be forgotten or skipped, and even if the Agent claims to have followed them, the result remains unconfirmed without verification. Turning checkable rules into mandatory checks that block further progress on failure reduces reliance on the executor's voluntary compliance.

For example, a project may prohibit Controllers from accessing Repositories directly. A reminder in Rules may still be ignored, and functional tests may pass despite the violation. Encoding this dependency rule in an architecture check and requiring it to pass before merging blocks that violation:

Controller → Repository           Check fails; merge blocked
Controller → Service → Repository  Passes this dependency check

A read-only database account is more direct. A rule prohibiting data changes can still be violated. If the account's effective privileges on the target tables allow only reading, the database rejects direct attempts to modify those tables through that account. The permission restriction remains effective even if the Agent forgets the instruction.

This reliability has a defined scope: the architecture check blocks only the dependency violations it covers, and read-only privileges restrict the corresponding operations through that account. Checks must actually run, and failure must block further progress. Printing a warning while still allowing a merge does not enforce the rule.

When the main effort shifts from production to verification, making automatically checkable requirements mandatory can reduce the burden of manual verification.

I used to spend most of my development time writing code. Once a Coding Agent could produce code quickly, review and testing took up more of my time. With AI doing most of the production work, my focus shifted to verifying the result.

Verification also includes checking for missing requirements. Even if AI writes both the code and the tests and every test passes, a requirement may be absent from both. As long as I am responsible for accepting the result, I still need to check it against the requirements. Faster code generation and test execution cannot replace that check.

Translation workflows that use a machine for the first draft and a human for revision follow a similar division of work: the machine produces the translation, and the person checks whether it conveys the original meaning accurately and fully.

Requirements that can be checked automatically can become mandatory checks in the workflow. This applies the idea that enforcement constrains an executor more reliably than voluntary compliance and reduces some of the manual verification work.

Code can show an Agent what is currently implemented, but it may not explain why a particular approach was chosen or why a feature was deferred. Recording those reasons in idea, PRD, spec, design, decision, and plan documents from the start, and linking the documents together, gives the Agent access to the original reasoning during later reviews, debugging, or feature work. This reduces the need to infer intent from the code’s structure.

For example, an Agent taking over the login module three weeks later can identify the authentication library from the code, but may not learn why enterprise SSO was initially deferred. Preserving that reason in the documents makes it less likely to mistake a temporary constraint for a lasting product principle. Using one name for the same concept across documents and code also reduces missed information caused by different names when searching the chain.

Maintaining consistency requires distinguishing current requirements from historical decisions. If the project later decides to support enterprise SSO, a new decision document can record why the choice changed and identify the earlier decision it replaces. The old document keeps its original reasoning, is marked as archived or superseded, and links to the new decision. This preserves the history of the change while making the current decision identifiable.

This approach adds ongoing work to check code against documentation. When requirements and implementation change, the relevant descriptions, decision statuses, and replacement links need maintenance. Without that work, old documents can mislead the next Agent. As the main effort shifts to verifying whether outputs meet requirements, documents can provide acceptance criteria, but those criteria also need to be checked for continued validity.

When implementing an unfamiliar feature by hand, getting stuck or encountering errors often forces people to consult documentation and understand the mechanism before proceeding. Learning happens as part of completing the task. Once AI can perform those steps, people may obtain a usable result without going through the process that would have prompted learning.

People without a software development background may also build software through Vibe Coding and check whether it meets their requirements by using it. Where this is a sufficient way to evaluate the result, they can confirm that the software does what they need without learning its underlying principles. As the main work shifts to verifying whether output meets requirements, learning to evaluate a result and learning to implement it become activities that can happen separately.

Under pressure to finish, people can move on once the result passes acceptance checks, without spending more time asking why it works. Continued learning then requires deliberate effort: asking about the implementation, explaining the mechanism in their own words, or making understanding part of the completion criteria. Delegating implementation and debugging to AI over time may reduce opportunities to learn new skills and practise existing ones. Gaps in those abilities may become apparent when AI cannot solve a problem.

What becomes optional here is learning the implementation principles. Understanding the requirements remains essential to acceptance. When judging correctness requires knowledge of internal mechanisms, software that appears to work is insufficient evidence, and that knowledge remains necessary for effective verification.