The Same AI Should Not Write the Code and Mark It Correct

There is a simple problem with asking the same interpretation to produce both a solution and the evidence that the solution is correct. The two can agree perfectly and still be wrong about what the customer meant.

Imagine a requirement that says an order above a certain threshold must be approved before it can be released. The implementation can be technically neat and the accompanying tests can all pass, yet both can still be wrong if the original requirement actually contained an exception for a particular customer group that was missed at the start. Internal consistency is not the same as correctness.

That's why independence matters more than the sophistication of the test itself. The strongest evidence has something outside the implementation to answer to. That might be an agreed acceptance condition, a business rule or a test case derived from the requirement before the implementation is available. The important point is that the target does not move simply because the code took a particular shape.

AI makes this worth revisiting because it can remove some of the natural friction that once separated these activities. A developer may previously have discussed the requirement, written the code, handed it to somebody else and waited for feedback. When generation and test creation can both happen quickly, it becomes easier for one interpretation to flow through the entire exercise without being challenged.

For delivery leaders, the question is not whether AI should be allowed to help with testing. It is whether the evidence can still challenge the implementation. If the answer is yes, automation can make assurance faster. If the answer is no, a large set of passing tests may provide more confidence than it deserves.

This is not an AI problem in itself. Delivery teams have always needed a definition of done that comes from the requirement rather than from the implementation. AI simply makes the distinction easier to lose because one system can now produce a large amount of code and supporting material very quickly.

A test created after the implementation exists can easily inherit the implementation's assumptions. If the original interpretation was wrong, the test may confirm the same mistake. That gives the team consistency, but not necessarily correctness.

The stronger approach is to keep the intended behavior independent of whatever builds the code. The requirement should establish what success means. The evidence should then show whether the result meets that requirement.

For a Business Central partner, this matters far more than the number of lines generated or the speed of the first build. A live customer environment needs evidence that the requested outcome was delivered, not simply evidence that the code agrees with itself.

The question worth asking is straightforward: what defined correct before the implementation existed, and can the team show that the finished change was checked against it?

This does not require an adversarial relationship between generation and testing. It requires separation of purpose. Generation is trying to produce a solution. Assurance is trying to establish whether that solution meets an independently stated expectation. When both activities are allowed to collapse into one, a passing result can become circular evidence.

Experienced teams already recognize this in other forms. A developer's unit tests are useful, but they are not the whole acceptance process. A technically correct object can still implement the wrong business rule. The arrival of AI does not overturn that principle. It simply makes it possible to produce both the object and its apparent proof much faster.

There is a practical benefit to defining the target early as well. Disagreement becomes visible before it is buried inside code. If the customer, consultant and developer cannot agree on what a test should prove, that is valuable information. Resolving the ambiguity at that point is cheaper than discovering it after a polished implementation has already created momentum around one interpretation.

The quality of AI-assisted delivery will therefore depend less on how confidently a model can explain its own output and more on whether the organization has retained an external standard against which that output can be judged. That is a governance discipline, not a model capability.