Six years ago, I was sitting in meeting rooms at one of Canada’s largest banks trying to convince some very smart people that XGBoost and LightGBM were safe enough to use for credit-risk modelling.
Read that sentence again.
Six years ago.
I was working with teams building models across credit adjudication, account and exposure management, portfolio management, regulatory capital, probability of default, market risk and counterparty credit risk.
Inside a highly regulated financial institution, moving from traditional statistical approaches toward boosted-tree models was a serious transformation.
The conversations were fierce.
And they should have been.
Many of the people challenging us had PhDs in statistics, mathematics or computer science. Some had been building the bank’s models long before I entered the field.
They were risk professionals.
Their job was not to fall in love with the newest algorithm.
Their job was to ask what could go wrong.
Their concern was straightforward:
How do we trust a model we cannot sufficiently explain?
My team and I were arguing that these so-called “black-box” models were not nearly as impenetrable as they appeared.
When we started introducing SHAP and Shapley-value-based explanations into those discussions, I remember how revolutionary it felt.
You would have thought we had invented the thing ourselves.
We had not, obviously. SHAP had been introduced formally by Scott Lundberg and Su-In Lee only a few years earlier as a unified framework for interpreting model predictions.
But inside that environment, at that moment, it felt like we had brought in something extraordinary: a credible way of showing not only what the model predicted, but why.
Eventually, we succeeded.
Importantly, we also had innovative people on the model-risk and validation side who were willing to do the research, challenge us rigorously and help establish what responsible adoption should look like.
I remember that work becoming part of the institution’s early conversations about how these newer modelling approaches could be governed and validated.
That experience has stayed with me because of what happened next.
Three Years Ago, We Were Industrializing Model Development
Fast-forward roughly three years.
I was at another bank, leading modelling and advanced-analytics transformation, and we were building what we called an acceleration platform.
The problem was familiar to anyone who has worked inside a large financial institution.
There were hundreds of models, many teams, enormous amounts of historical code and considerable duplication.
Different models might technically serve different business purposes but belong to the same fundamental methodological archetype.
A probability-of-default model used for regulatory capital and a credit-adjudication model, for example, may operate in very different contexts but share many of the same underlying modelling patterns.
So we started grouping models into archetypes.
Then we created standardized development libraries.
Standardized validation libraries.
Common coding structures.
Pre-reviewed components.
A CLI.
MLOps integration.
And an architecture intended to make model development faster, more consistent and easier to validate.
At the same time, generative AI was exploding onto the scene.
We were working with external consultants and researchers on using large pretrained language models as foundation models, feeding them years of model-development and model-validation documentation and exploring how they could help automate one of the most painful parts of the modelling lifecycle:
documentation.
If you have worked in financial services, you know what those documents look like.
They are enormous.
And modellers — myself included — have historically had a remarkable ability to turn “document the model” into 150 pages of mathematics, methodology, assumptions, testing and validation evidence.
The transformation we were attempting was substantial.
Think about the investment.
Gather the historical code.
Understand it.
Standardize it.
Design the libraries.
Create the archetypes.
Build the platform.
Create the knowledge layers.
Integrate the development process.
Solve MLOps.
Build organizational support.
Then drive adoption.
It was sophisticated work.
At the time, it was genuinely cutting edge.
And recently, thinking about it, I found myself laughing.
Not because the work was bad.
Because the abstraction layer changed before enterprises could finish transforming around the previous one.
That may be one of the most important technology lessons for senior leaders right now.
A transformation can be well designed, technically sound and directionally correct — and still be overtaken by the speed of the underlying technology.
The New Abstraction Layer: Models Building Models
Today, the question is no longer simply:
How do we help data scientists write model code faster?
The question is becoming:
Why should the data scientist be writing most of that code at all?
Agentic coding has changed the equation.
Modern coding agents can inspect repositories, read and modify files, execute commands, run tests, debug failures and work through increasingly complex implementation tasks.
Anthropic’s analysis of roughly 400,000 Claude Code sessions between October 2025 and April 2026 found that a typical user prompt triggered around ten agent actions, including reading files, editing code and executing commands.
I have experienced this personally.
The website for The Decisioning Layer was built almost entirely through an agentic workflow.
I acted as the product owner.
ChatGPT helped with design and QA.
Cursor handled much of the implementation.
Different models proved useful for different tasks.
I built another application that could ingest photographs of clothing, generate structured garment metadata, learn preferences and recommend outfits based on context.
I showed it to my daughter and she treated the thing like a game, photographing everything in her closet and building outfits.
Again, most of the implementation was agent-generated.
Those are personal examples.
The more interesting example came from someone who previously worked for me and later joined a technology startup.
He told me his team was shipping features every day.
Every day?
I asked him how that was possible.
Then he told me something that made the answer obvious:
He had not personally written a line of code in months.
Whether you like the term vibe coding or hate it is becoming irrelevant.
The capability is real.
But software engineering is only the beginning.
The much more consequential question for people like me is:
What happens when we apply the same paradigm to data science?
What happens when models start building models?
Data Science Has a Different Problem
This is where I become both excited and cautious.
In traditional software engineering, a significant part of the acceptance criterion is observable behaviour.
Does the feature work?
Do the tests pass?
Does the application behave as expected?
Data science has an additional problem.
A model can run perfectly and still be catastrophically wrong.
You can build a classifier that executes flawlessly and reports 99% accuracy.
I have seen people proudly present numbers like that.
And sometimes, within seconds, the metric itself tells you that there may be a problem.
Where is the class imbalance?
Was there leakage?
How did you construct the validation sample?
What happened out of time?
How was the model regularized?
How stable is the performance?
Is accuracy even an appropriate metric for the decision the model is making?
You can write syntactically perfect forecasting code that produces operationally disastrous forecasts.
Overforecast demand in retail and you can end up holding excessive inventory, tying up working capital or, in grocery, increasing shrink through expiry.
Underforecast and you create stockouts, lost sales and frustrated customers.
Do it repeatedly and store operators stop trusting your system altogether.
Now move into lending.
A credit model that systematically misidentifies risk can affect decisions across a portfolio worth hundreds of millions or billions of dollars.
The code compiling is almost irrelevant.
The question is whether the model is right enough, stable enough, explainable enough and governed appropriately for the decision it is making.
That is why data science cannot simply copy software engineering’s adoption of agentic coding.
But it absolutely should learn from it.
We Are Creating a Second-Order Black Box
I have started thinking about this problem as second-order black-boxiness.
Years ago, the concern was:
We do not completely understand the model.
That was the first black box.
Now imagine the development lifecycle itself is increasingly agent-generated.
The feature engineering.
The sampling strategy.
The model specification.
The objective or loss function.
The hyperparameters.
The validation code.
The explainability layer.
Potentially even the interpretation of the results.
Now we have:
a model building another model.
We have not eliminated the black box.
We have potentially stacked one black box on top of another.
That is the second-order black box.
And in regulated or high-consequence environments, that changes the governance question substantially.
You cannot sit in front of a model-risk committee, regulator, board or business executive and say:
“I’m not sure why that modelling decision was made. The agent chose it.”
Accountability does not disappear because implementation has been delegated.
If anything, emerging model-risk expectations make that point more important.
OSFI’s final Guideline E-23, which becomes effective May 1, 2027, explicitly incorporates AI and machine-learning models into its model-risk framework. It calls for clear and repeatable development practices, documentation, conceptual soundness, validation, expert judgement and explainability appropriate to a model’s purpose and level of autonomy. It also explicitly recognizes the additional risks created by black-box and autonomous models.
That is highly relevant to agentic development.
Because the more powerful our development tools become, the more deliberate our assurance mechanisms need to become.
Agentic Coding Could Make Shallow Data Science Expertise Worth Less
This leads to what I think will be one of the largest changes in the data-science talent market.
For years, the commercialization of machine learning dramatically lowered the barrier to entry.
Scikit-learn.
TensorFlow.
PyTorch.
Statsmodels.
Online courses.
YouTube.
Bootcamps.
Open-source notebooks.
That democratization was overwhelmingly positive.
But it also created a type of practitioner whose expertise sometimes lived almost entirely at the API layer.
Import a library.
Prepare some data.
Call .fit().
Call .predict().
Calculate a metric.
Ship the model.
The problem is not how somebody learned data science.
This is not a credential argument.
Someone without a graduate degree can develop extraordinary depth, while an advanced degree certainly does not guarantee practical judgement.
The distinction is depth of understanding.
If most of your professional value is knowing which package to import, which function to call and which syntax to use, you now have a very serious competitor.
The agent.
And it may already be better at that part of your job.
An agent can generate the model code.
It can build cross-validation.
It can create diagnostic plots.
It can calculate SHAP values.
It can suggest hyperparameters.
It can write unit tests.
It can document the implementation.
It can often identify problems in code faster than a relatively inexperienced practitioner.
So the value of a data scientist has to move up the stack.
And there is already some fascinating evidence of that happening in coding more broadly.
In June 2026, Anthropic published research based on approximately 400,000 Claude Code sessions. In the typical session, the human made about 70% of the planning decisions while Claude made about 80% of the execution decisions.
Think about what that means.
The human increasingly decides what should be built.
The agent increasingly decides how the implementation gets done.
Even more interestingly, greater task-specific expertise was associated with better results and with the agent doing more work per human instruction. Expert-rated users generated substantially longer chains of agent activity than novice-rated users.
I would not take one vendor’s usage study and declare the future settled.
But the direction is fascinating.
And it aligns with exactly how I think about the future of data science:
The scarce skill is shifting from execution to judgement.
The Data Scientist Becomes a Model Designer
My ideal data-science organization increasingly looks like a team of model designers.
A strong model designer should be able to take a vague business problem and turn it into a rigorous analytical problem.
They need to know what questions to ask before a model is ever built.
They need to understand the mathematics and statistics well enough to determine whether the proposed modelling approach makes sense.
They need to know when the agent has taken a shortcut.
They need to recognize leakage.
Bad identification.
An inappropriate objective function.
An unstable feature.
A poorly constructed validation strategy.
A spurious relationship.
A technically impressive model solving the wrong business problem.
And they need to translate the result back in the opposite direction: from modelling output into a decision that a merchant, risk officer, operations leader or executive can actually use.
The role increasingly becomes a combination of:
- problem framer — translating ambiguous business questions into solvable analytical problems;
- model architect — designing the methodological approach and understanding the trade-offs;
- agent orchestrator — decomposing the work and delegating implementation appropriately;
- validator — challenging methodology, implementation, results and failure modes; and
- decision translator — turning model outputs into consumable, commercially actionable decisions.
The coding still matters.
Understanding code still matters.
But being the fastest person on the team at manually typing it matters less.
Innovation ability, technical judgement and problem formulation matter more.
Model Documentation Should No Longer Be a Bottleneck
One of the most immediate opportunities is documentation.
I currently have a real example.
My team is taking over a product that was originally built by a vendor.
To own it properly, we need to understand far more than the model itself.
How does the backend work?
What libraries were chosen?
What services interact?
Why were particular architectural decisions made?
Where are the dependencies?
How does the application layer interact with the analytics?
Historically, this kind of transition could require weeks of code walkthroughs, reverse engineering and knowledge transfer.
Today?
One of the things we can do is give an agent controlled access to the codebase and have it systematically demystify the system.
Now extend that idea.
Imagine an agentic modelling environment in which one set of agents assists with development, another performs independent review, another executes validation tests and another continuously builds the model documentation from the actual implementation and evidence generated during development.
Documentation stops being an exhausting retrospective exercise performed just before governance approval.
It becomes a compiled artifact of the modelling lifecycle.
But there is an important caveat.
The agent should not be allowed to invent the rationale for decisions after the fact.
Good agentic documentation must be traceable to the code, configuration, tests, prompts, outputs, human decisions and approval trail.
The goal is not simply automated prose. The goal is automated evidence assembly.
That distinction matters.
Standardization Is Not Disappearing. It Is Moving Up a Layer.
This is another place where my thinking has evolved.
Three years ago, I would have told you that the answer to enterprise modelling efficiency was a comprehensive set of standardized archetype-based coding libraries.
I still believe reusable, approved libraries have a place.
But they are no longer enough to constitute the operating model.
In an agentic environment, standardization moves up one abstraction layer.
Instead of prescribing only:
Here is the exact code everybody should start with.
You can increasingly prescribe:
Here is how our organization builds this class of model.
That context can include modelling methodology, approved libraries, architectural patterns, documentation templates, required diagnostics, validation standards, prohibited techniques, naming conventions, monitoring requirements and escalation rules.
Agentic development platforms are already moving toward mechanisms for encoding repository-level instructions and organizational conventions.
For example, GitHub Copilot code review now supports AGENTS.md files that provide repository-level instructions used when generating review feedback. GitHub has also added organization controls, content exclusions and expanded custom-instruction capabilities around agentic code review.
For a financial institution, I can imagine going much further.
A standardized skill for developing credit-risk classifiers.
Another for independent validation.
Another for documentation.
Another for monitoring.
Another for producing the evidence required for governance review.
In effect, the organization codifies not merely the implementation, but how it thinks about the model.
And enterprise consistency cannot depend solely on prompts or parameters controlling model randomness.
It needs:
versioned instructions;
approved model-development skills;
pinned dependencies;
repeatable environments;
automated tests;
approved evaluation suites;
reproducibility checks;
audit trails;
and human approval gates.
The library used to be the standard.
Increasingly, the entire agentic development system becomes the standard.
Five Problems Leaders Need to Solve Before Scaling This
None of this means handing every repository to the most powerful model available and hoping for the best.
I see at least five issues organizations need to work through.
1. Economics
The economics matter.
Running powerful agents across large repositories, long contexts, repeated iterations and multiple independent review agents can become expensive.
And there probably will not be one universal answer.
Organizations should experiment with model routing.
Use frontier models where difficult reasoning genuinely requires them.
Use smaller or less expensive models for routine implementation, testing or documentation where they perform adequately.
Benchmark open-weight models against commercial models.
For some use cases, locally hosted models may be sufficient.
For others, they may not be.
And hosting locally is not “free” after the hardware purchase.
Serving infrastructure, upgrades, cybersecurity, monitoring, engineering support and model operations all contribute to total cost.
The important thing is experimentation.
Anyone who tells you the optimal enterprise architecture for agentic data science has already been definitively solved is getting ahead of the evidence.
We are all learning.
2. Security and Intellectual Property
The second consideration is security.
Source code can contain proprietary business logic.
Models can embody intellectual property.
Training datasets may include confidential or regulated information.
Prompts themselves may expose sensitive context.
So organizations cannot simply send everything to whichever frontier model performed best in yesterday’s benchmark.
At the same time, this needs nuance.
Enterprise commercial platforms can provide materially different privacy protections from consumer AI products. OpenAI, for example, states that it does not use inputs and outputs from its Business, Enterprise and API products to train its models by default, and provides encryption and enterprise data controls.
That does not eliminate the security question.
Organizations still need to consider:
access controls;
secrets;
data residency;
retention;
third-party risk;
execution privileges;
proprietary code;
and potential data exfiltration.
For some organizations, the right answer may be governed commercial platforms.
For others, private infrastructure or locally hosted open-weight models may make sense.
And for organizations with deep historical modelling repositories, there is another interesting possibility:
fine-tuning or otherwise adapting private models using the organization’s own modelling history, standards and code.
That could potentially create a secure, domain-specific capability that improves as the organization itself learns.
It is worth exploring.
And this cannot simply be thrown over the wall to IT.
Data-science teams are often closest to emerging modelling capabilities.
Technology, cybersecurity and architecture teams possess equally critical expertise around enterprise controls.
Neither should design this environment alone.
3. Reproducibility and Control
If an agent can make different modelling choices from one run to another, what does reproducibility mean?
It can no longer mean only:
Can I reproduce the final model?
Increasingly, it may also need to mean:
Can I reproduce and audit how the model came to exist?
Which foundation model was used?
Which version?
Which skills and instructions were loaded?
Which approved libraries were available?
Which data was exposed?
What decisions did the agent make?
What decisions did the human override?
What validation failed?
What was regenerated?
What changed?
Who eventually approved it?
Version the models.
Version the instructions.
Version the skills.
Lock critical dependencies.
Preserve important execution environments.
Log the development trajectory.
Automatically evaluate outputs against known criteria.
NIST’s AI Risk Management Framework and its Generative AI Profile similarly emphasize managing AI risks across the lifecycle rather than treating evaluation as a single end-stage activity.
For high-consequence modelling, reproducibility will increasingly have to include the agentic development process, not simply the predictive artifact it produces.
4. The Talent Pipeline
This one is easy to underestimate.
I have argued that experienced data scientists should increasingly design and validate while agents perform much of the implementation.
Fine.
But how does someone become an experienced model designer?
A new graduate cannot arrive on Monday and architect your enterprise forecasting system on Tuesday.
Historically, junior practitioners developed judgement partly by doing the work.
Writing the code.
Making mistakes.
Debugging models.
Watching something fail.
Being challenged by more experienced people.
Learning why apparently sensible modelling decisions produced ridiculous outcomes.
If we automate all of that away, we may optimize this quarter’s productivity while destroying the pipeline that produces our future experts.
This is why I favour a measured rollout.
As a starting mental model — not a mathematical prescription — perhaps agents eventually perform 80% of routine implementation while humans deliberately retain 20% of work required to build understanding and judgement.
Maybe your ratio is different.
That is not the point.
The point is:
Learning cannot become an accidental casualty of automation.
The senior model designers we will need five years from now still have to come from somewhere.
5. Governance and Accountability
Finally, every agent needs a defined scope of authority.
What can it change autonomously?
What requires human review?
Which modelling decisions can it recommend but not make?
What evidence must be generated?
What triggers independent validation?
Who signs off?
And what does “human in the loop” actually mean?
Because in high-stakes modelling, a human clicking Approve after an agent has done something the human does not understand is not meaningful human oversight.
The human has to be capable of challenging the work.
OSFI’s model-risk framework is particularly relevant here because it explicitly requires responsibilities and accountability across model stakeholders and emphasizes independent review, conceptual soundness, explainability and governance proportionate to model risk.
The technology may become increasingly autonomous.
Accountability cannot become increasingly ambiguous.
This Is Not an Argument for Fewer Data Scientists
It is an argument for different data scientists.
And, just as importantly, different data-science leaders.
Hiring criteria should evolve.
Training programs should evolve.
Career paths should evolve.
Performance expectations should evolve.
Leadership should stop treating the ability to produce large volumes of code as synonymous with technical strength.
Deep foundations in statistics, mathematics, computer science and relevant quantitative disciplines become more valuable, not less, because those foundations help people reason about what an agent has produced.
Curiosity becomes more valuable.
Communication becomes more valuable.
Commercial understanding becomes more valuable.
The ability to move between business ambiguity and mathematical precision becomes more valuable.
And perhaps counterintuitively:
The more code machines write, the more important it becomes that humans understand what the code means.
Every AI-First Organization Needs a “Models Building Models” Strategy
When I say AI-first organization, I do not mean a company trying to insert an LLM into every process because AI happens to be fashionable.
I mean organizations whose businesses are materially powered by models.
Traditional statistics.
Machine learning.
Forecasting.
Optimization.
Deep learning.
Reinforcement learning.
Decision systems.
Organizations where data science is embedded in how commercial, operational or risk decisions actually get made.
Those organizations should be developing a deliberate models-building-models strategy now.
Not a procurement strategy.
Not:
Which coding assistant should we buy?
An operating strategy.
Which modelling workflows should become agentic first?
What level of autonomy is appropriate for each?
How do we encode standards?
How do we independently evaluate agent-generated work?
What changes in model validation?
What evidence gets retained?
How do we protect proprietary methods and data?
How do we manage economics?
What work should juniors still perform?
How do roles change?
Where does accountability remain human?
How do we measure whether the new operating model is actually better?
Because this technology is moving too quickly for organizations to wait until somebody publishes the definitive playbook.
There is no definitive playbook.
I certainly do not have all the answers.
I am experimenting with this myself.
Everyone serious about the space should be.
Three years ago, I was helping build a sophisticated transformation designed to accelerate modelling through standardized libraries and automated documentation.
At the time, it felt like the future.
Today, I can see a future in which an agent understands the modelling standard, writes the implementation, executes the tests, prepares the documentation and hands the work to a human expert whose primary job is no longer to type the solution —
but to design it, challenge it and take accountability for it.
That is an extraordinary change in three years.
And three years from now, I suspect some of what I have written here will look equally primitive.
That is precisely the point.
The competitive advantage will not come from correctly predicting the final form of agentic data science.
The competitive advantage will come from building an organization capable of learning and changing as fast as the technology does.
Models are going to build models.
The question is no longer whether data-science organizations should allow it.
The question is:
How do we make sure they build the right ones?
I would genuinely like to hear how other data scientists, modelling leaders, CDOs, CIOs, risk leaders and consumers of advanced analytics are approaching this.
What are you already allowing agents to do?
What have you deliberately kept human?
What has worked?
What has failed?
And what risks am I missing?
If your organization is working through the same questions and you want to compare notes — or think through what a models-building-models operating model could look like in your environment — let’s connect.
Views are my own and do not represent my employer.
Sources & Further Reading
Anthropic — “Agentic coding and persistent returns to expertise” (June 16, 2026).
Privacy-preserving analysis of approximately 400,000 Claude Code sessions examining the division of planning and execution decisions, task-specific expertise and agentic coding outcomes.
Office of the Superintendent of Financial Institutions — Guideline E-23: Model Risk Management.
OSFI’s final model-risk guideline for federally regulated Canadian financial institutions, including explicit coverage of AI/ML models, black-box approaches, autonomy, explainability, development, validation and governance. Effective May 1, 2027.
NIST — Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile.
Cross-sector guidance for incorporating trustworthiness and risk management into the design, development, use and evaluation of generative-AI systems.
Read the NIST Generative AI Profile
Scott Lundberg & Su-In Lee — “A Unified Approach to Interpreting Model Predictions” (2017).
The foundational SHAP paper introducing the SHapley Additive exPlanations framework for model interpretation.
GitHub — Copilot code review: AGENTS.md support and related organization controls (2026).
Examples of agentic development environments incorporating repository-level instructions, organization controls and customization into coding-agent workflows.
OpenAI — Enterprise Privacy.
Current privacy and data-control commitments for OpenAI business products and the API, including the default exclusion of business inputs and outputs from model training.