Before you work with a coding agent, talk to Robert

Robert has been at your company for twenty years. When two teams contradict each other on a metric definition, he sets the record straight; he knows which customer statuses count as active for board reporting and which count for commission, and that the two lists overlap in specific cases. Yet the knowledge in his head largely remains undocumented.
In short, your data warehouse may hold the records, but Robert holds the meaning behind them.
At “Your Data Stack is Going Agentic”, the Montreal data developer meetup hosted at the Maxa office last week, panelist Geoffrey Bernard, CMO and CDO at La Presse, said:
"Value creation comes from Robert, who has been here for twenty years and has never documented anything. And that logic in his brain is something he doesn't even know how to express."
This is far from an isolated case. Every business has a Robert you should go talk to before automating code that relies on accurately capturing your business logic.
Agents iterate faster than anyone can correct them
The time it took for a data engineer to build a data pipeline gave a domain expert room to check the work. Iteratively, data and business teams collaborated to correct business logic over time.
Coding agents scaffold models, write SQL, generate tests, and stitch sources together faster than any human team. Work that took a small team a quarter can take an afternoon in Claude Code. Though the human in the loop may continue to iterate with AI agents, the time gap between iterations has shortened to mere minutes or hours at most. So when does the business team catch a wrong assumption before it leaks into production?
The barrier to ‘good enough’ has dropped. A POC that does seventy percent of the work looks finished. Whether the result is solid, repeatable, and sustainable is a different question.
At the speed and scale of AI, mistakes ship before even a domain expert with 20 years of experience can flag them. When code is fast and cheap, the bar for quality becomes how closely the output matches how the business runs.
Robert is a role, not one person
Every company has a Robert, often several. The revenue operations lead who has memorized which customer records roll up into which parent account, or the controller who knows three specific ledger codes are legacy and get excluded from the current chart of accounts.
Robert can spot a wrong number the moment it appears, but if you press him for the business rule behind it, he may give you a plausible reason he invented on the spot. His knowledge is implicit, pattern recognition or ‘intuition’ based on years of seeing every use case, every exception.
Automating without business expertise causes dangerous assumptions
A coding agent working from data schemas and column names has to infer business logic from the schema… which leads to a lot of incorrect assumptions made by the agent.
You might even generate code that runs cleanly and passes all the tests, then quietly encodes a dangerous assumption: revenue that picks up a segment finance stopped counting two years ago, or a month that closes on the calendar boundary instead of the accounting one. Every downstream number looks fine, and every downstream decision is slightly wrong.
An experienced analyst catches this kind of drift by feel. But when agents hand results to one another, a single wrong assumption travels down the chain and compounds. So the safest place to settle Robert's reasoning is up front, as a clean spec the build starts from rather than a correction applied after.
Elicitation is now the most important skill for data engineers
Getting Robert's knowledge into machine-readable form is more like interviewing than documenting, and closer to social science than engineering.
As Bernard told the room,
"It sounds trivial, but for anyone who has tried, it's actually hard. It takes skills and methodology that most of us were never taught."
It takes patience to ask ‘why’ a few times over, tolerance for contradiction when two experts define the same term differently, and the judgment to tell a real business rule from a personal preference.
It takes the discipline to test every stated definition against production data. Some of what surfaces turns out to be a process worth removing rather than a rule worth automating. Some of it is a rule Robert had been applying for years without ever naming.
This skill of elicitation used to sit at the edge of data engineering, practiced by the best and skipped by everyone else. Now, it’s emerging as one of the most important skills differentiating a well-rounded data engineer from a coding-agent-wielder.
You see two kinds of engineers thrive in the agentic era: the deep specialist who steers agents better than anyone in the room, and the generalist who understands the business well enough to take the agent's output and put it back in the organization's context.
As one panelist at “Your Data Stack is Going Agentic” put it, the most valuable data professionals were always close enough to the business to extract business impact out of data.
AI in the data stack amplifies the value of being able to describe the business in a way that improves the output of coding agents.
From Robert's head into the tech spec
If elicitation is the skill, the harder problem is follow up.
A definition pulled out of Robert's head in a meeting still ends up in a doc nobody opens, or in the analyst's memory, which puts you back where you started. The knowledge has to live where the build happens.
Maxa Autopilot Spec is for the backstory before the build. It captures business knowledge from call transcripts, documents, dashboards, spreadsheets, then asks focused follow-up questions wherever a definition is incomplete or two sources disagree. The output is a set of spec files a coding agent reads before it writes any SQL, so the build starts from how the company runs.
With a clean tech spec, Robert's knowledge stops being a bottleneck and starts being an asset the whole team can build on. The engineers who capture how the business runs before the agent codes will ship data that matches the organization’s business logic.