English | EN 
A few months ago, I gave an AI coding agent a large set of legacy data mappings and asked it to translate them into a new data lakehouse implementation.
The repository contained technical design documents, domain semantics, business rules, mapping metadata, governance artifacts, validation logic, and the existing implementation. The agent could inspect code, query data, review documentation, and retrieve additional context from the project environment. I let it work across a large part of the problem autonomously. By the next morning, I had a lot of completed work and an unwanted mess.
The generated SQL and logic compiled. The columns existed. The transformations looked reasonable in isolation. Yet several mappings were wrong because the agent had followed the wrong evidence, missed an important constraint, or substituted a field that looked like the concept it was trying to derive.
In one case, legacy behavior conflicted with the current business rule. In another, the required business concept did not exist in the new source model, so the agent selected the closest available field. Elsewhere, it explained a reconciliation difference with a plausible theory without proving that the theory was correct. These were not ordinary coding failures. The code itself often looked acceptable and was not the real problem. The problem was that the agent had implemented an interpretation I would not have approved.
That raised a different question: What specification was the agent actually implementing?
For a small greenfield function with a clear contract, the answer may be obvious. Enterprise data lakehouse development work is different. The intended behavior of a transformation is often distributed across business definitions, regulatory guidance, SME decisions, source-system behavior, legacy code, architectural decisions, governance artifacts, and the data itself. And those sources do not always agree.
Legacy code establishes what the old system did. It does not prove that the behavior was correct. A business definition explains what a concept means, but it may not explain how to represent that concept when the required source data is incomplete. Reconciliation shows that two outputs differ but does not determine which result should control the new implementation.
The August 2026 SWE-RPG study, A Unified Issue Resolution Benchmark for Requirement Clarification, Planning, and Code Generation for Coding Agents, found that implicit requirement recovery was the primary failure category in its evaluation, accounting for 24.5% to 46.0% of agent runs. The July 2026 ClarifyCodeBench study reached a similar Conclusion: strong code-generation capability did not translate into strong requirement clarification, and performance fell as ambiguity increased. My experience reflected the same distinction.
When the intended semantics were unambiguously established, the agent performed well. It could translate approved mappings into Spark, generate repetitive implementation code, convert structured rules into executable logic, and accelerate documentation work. The difficult work began when the agent had to determine the semantics itself.
At that point, the problem was no longer:
Specification → Code
It became:
Distributed Evidence → Interpretation → Specification → Code
This was where most of the serious errors occurred. One observation appeared repeatedly throughout the project: access to context was not the same as understanding context. The agent had access to design documents, semantic rules, governance artifacts, source mappings, repository code, and actual data. That did not guarantee that it would retrieve the right information, interpret it correctly, apply it consistently, or recognize when different sources conflicted. Making information available was necessary but insufficient. In many enterprise data platforms, the requirement is not simply missing or ambiguous. It must be reconstructed from evidence created at different times, by different roles, and for different purposes.
I eventually changed how I worked with the agent after the overnight experiment.
Instead of asking it to derive many complex mappings simultaneously, I reduced the work to one decision at a time. Before proposing an implementation, it had to inspect the relevant business intent, dependencies, legacy behavior, source schema, and actual data. If the new result differed from the old one, the difference had to be investigated. If evidence was missing, that remained an unresolved problem until additional information was found.
The change was not a better prompt. It was making the path from evidence to implementation visible enough to challenge. Coding agents can use platform instructions, project instructions, repository artifacts, and other sources of organizational knowledge. Those capabilities expand the evidence available to the agent but they do not answer a more important question: How did the agent decide what the system was supposed to do?
The consequence extends beyond code review. Once an AI-assisted interpretation enters a mapping, validation rule, semantic model, or other machine-readable artifact, it can control runtime behavior and later become context for another agent. An unsupported interpretation can acquire the appearance of established truth because it has been encoded and reused.
Reviewing generated SQL or Python remains necessary. But if the main error occurred while the agent was determining what the implementation should mean, code review begins after the most important decision has already been made.
For straightforward development work, that distinction may have little practical effect. For regulated reporting, financial calculations, eligibility logic, enterprise metrics, or brownfield modernization, the interpretation may determine whether technically valid code produces an acceptable result.
As coding agents become better at producing implementations, I increasingly want to inspect what came before the code. What evidence did the agent use? What did it treat as controlling? What did it ignore? Where did it make an assumption? When the evidence conflicted, how did it determine what the system should do?
The code is only the final artifact in that chain. In complex data architectures, the challenge is making the reconstructed specification visible and reviewable before any software is generated.