It was right around 2017 when after spending a decade working with SQL Server I had a moment of panic thinking my career was heading for a dead end. In a way dbt revived my career.
Thanks for this, Olga. Handy's context-layer argument is one of the more directly tested claims in this space right now: four independent measurements in the past two weeks converged on the same split, with an AI agent answering business questions correctly around 70 percent of the time pointed at a raw database, and around 95 percent when pointed at a governed set of definitions for something like "revenue" or "active customer." The organizations already living in that 95 percent (banks, regulated drug companies, telecoms) mostly built those definitions for compliance reasons that predate the AI question by years. That splits the shift Handy describes into two very different jobs: for an org with that discipline already in place, "translating ambiguous concepts into precise definitions" is a small last step; for one still running on spreadsheets and tribal knowledge, it's a multi-year build.
That tracks, and it's not really about company size, it's about what forced the definitions into existence in the first place. Banks and pharma got 'revenue' and 'active customer' pinned down because a regulator or auditor demanded a single answer; B2B and SaaS never had that forcing function, and metrics like 'active user' or 'churn' are often genuinely contested even internally, not just undocumented. That's a deeper hole than 'haven't gotten around to it.'
Folks in more conservative industries or organizations will benefit from considering what stays the same before as after the analytics industry has shifted focus from data to context. This is good to know, but just a note that all your previous content is just as valuable....Glad it's all still on the shelf. Thanks as always.
AI is not going to build data warehousing data models any time soon.
Nor is it going to build ETL any time soon.
Why?
We already have the means to build data models very cheaply and to deliver ETL for those data models very cheaply, at a higher quality level than AI can achieve.
There is no point building something with AI where it is more expensive with more bugs than what can be done today.
AI can be affordable, accurate, precise, and handle most data-related tasks. It takes time and expertise to get there. But every day, there are more and more businesses who does that well.
I have been in data warehousing 35 years now and IT 44 years. I am yet to find a good use for AI apart from I use it to make voice overs for my blog posts using a female voice. This is because men will listen to a female voice longer than men will listen to a male voice.
I have also used AI to create some non copyrighted images that I can use as thumbnails in blog posts. That's helpful. And I use co-pilot for search on the web now because it brings back examples.
When I find a good use for AI I will surely use it.
And just so you know, I wrote my first AI in 1989, so I do know what an AI is. I have been waiting for it to become useful in my industry segment of building data warehouses and analyzing the data.
To give you some numbers and background?
I was the man who invented the technology to map 1,000 fields per 220 hour work month in a data warehouse project in 1996. I was the first man in the world to sell fixed price data warehousing projects where we would take ALL a companies data and put it into the dimensional data warehouse for $A300K in Australia or USD300K in Asia. That being the services component.
At 1,000 fields mapped per 220 work month in development we were the world leaders. I sold my first two multi-million dollar projects in February 1997. I sold over USD10 million in projects in 1997 because our numbers were compelling. We could build the worlds lowest cost dimensional data warehouses and it wasn't even close.
The 1,000 field mapped per work month from source systems to dimensional models remained the world leading mark until 2017. We didn't improve on it because we didn't see any need to go faster. We sold million dollar deal after million dollar deal from 1997-2010 at the mapping rate of 1,000 fields per work month.
Even today, in 2026, you can ask companies what is their development rate for mappings and many of them are still below the 1,000 fields per 220 hour work month even with AI. In fact many companies will tell you they don't even know how many fields they map in development per work month. The usual is still around 500.
In 2017 I invented some new ideas and got to 6K-8K fields mapped per 220 hour work month. And recently I invented some more new ideas and we are now at 12K-15K fields mapped per work month. No one else is even close. Not with AI. Not with anything.
In fact, I have had days, very long days, where I have now mapped 1,000 fields in a single day. But now I am 62 I can't work such long days. I used to get paid USD25,000 to map 1,000 fields from a source system to a target. Now I can do that in a day and can't get paid to do so. LOL!
In terms of the future? AI or not? We are now in the era where we can create data warehouses for very large systems. There is just such a data model under development with more than 50,000 fields in the source system and already there are over 100,000 fields in the target data warehouse data model. We expect that model to go past 250,000 fields.
When you can properly map and generate the ETL for 12K-15K fields per work month you can take any source system and build a data warehouse for it.
We can now also co-habit multiple customers data in a single data warehouse data model and we can either have co-habiting data in tables or we can have zero customer data co-habitation in tables and implement security at table level in a co-habited data model. And that data model with one set of tables per customer can be maintained with a single suite of code generated at the rate of 12K-15K per work month with very low maintenance costs.
The logical limit on that single data model on a single machine in a single database is 90 customers.
So you see Olga. We can do all that with zero AI, except for the blog posts to talk about it in a womans voice.
No one else is even close to that level of productivity. And very few people will ever be able to build what it is we are building. It should be fun. :-)
It was right around 2017 when after spending a decade working with SQL Server I had a moment of panic thinking my career was heading for a dead end. In a way dbt revived my career.
I don't think there is another data processing tool out there that "revolutionized" analytics in a way as dbt did.
Thanks for this, Olga. Handy's context-layer argument is one of the more directly tested claims in this space right now: four independent measurements in the past two weeks converged on the same split, with an AI agent answering business questions correctly around 70 percent of the time pointed at a raw database, and around 95 percent when pointed at a governed set of definitions for something like "revenue" or "active customer." The organizations already living in that 95 percent (banks, regulated drug companies, telecoms) mostly built those definitions for compliance reasons that predate the AI question by years. That splits the shift Handy describes into two very different jobs: for an org with that discipline already in place, "translating ambiguous concepts into precise definitions" is a small last step; for one still running on spreadsheets and tribal knowledge, it's a multi-year build.
I think we under-estimate how many businesses are still running on spreadsheets. Especially in B2B and SaaS.
That tracks, and it's not really about company size, it's about what forced the definitions into existence in the first place. Banks and pharma got 'revenue' and 'active customer' pinned down because a regulator or auditor demanded a single answer; B2B and SaaS never had that forcing function, and metrics like 'active user' or 'churn' are often genuinely contested even internally, not just undocumented. That's a deeper hole than 'haven't gotten around to it.'
Spot on.
Folks in more conservative industries or organizations will benefit from considering what stays the same before as after the analytics industry has shifted focus from data to context. This is good to know, but just a note that all your previous content is just as valuable....Glad it's all still on the shelf. Thanks as always.
Hello Olga and @Engineer of Data
AI is not going to build data warehousing data models any time soon.
Nor is it going to build ETL any time soon.
Why?
We already have the means to build data models very cheaply and to deliver ETL for those data models very cheaply, at a higher quality level than AI can achieve.
There is no point building something with AI where it is more expensive with more bugs than what can be done today.
AI can be affordable, accurate, precise, and handle most data-related tasks. It takes time and expertise to get there. But every day, there are more and more businesses who does that well.
Hello Olga,
I have been in data warehousing 35 years now and IT 44 years. I am yet to find a good use for AI apart from I use it to make voice overs for my blog posts using a female voice. This is because men will listen to a female voice longer than men will listen to a male voice.
I have also used AI to create some non copyrighted images that I can use as thumbnails in blog posts. That's helpful. And I use co-pilot for search on the web now because it brings back examples.
When I find a good use for AI I will surely use it.
And just so you know, I wrote my first AI in 1989, so I do know what an AI is. I have been waiting for it to become useful in my industry segment of building data warehouses and analyzing the data.
To give you some numbers and background?
I was the man who invented the technology to map 1,000 fields per 220 hour work month in a data warehouse project in 1996. I was the first man in the world to sell fixed price data warehousing projects where we would take ALL a companies data and put it into the dimensional data warehouse for $A300K in Australia or USD300K in Asia. That being the services component.
At 1,000 fields mapped per 220 work month in development we were the world leaders. I sold my first two multi-million dollar projects in February 1997. I sold over USD10 million in projects in 1997 because our numbers were compelling. We could build the worlds lowest cost dimensional data warehouses and it wasn't even close.
The 1,000 field mapped per work month from source systems to dimensional models remained the world leading mark until 2017. We didn't improve on it because we didn't see any need to go faster. We sold million dollar deal after million dollar deal from 1997-2010 at the mapping rate of 1,000 fields per work month.
Even today, in 2026, you can ask companies what is their development rate for mappings and many of them are still below the 1,000 fields per 220 hour work month even with AI. In fact many companies will tell you they don't even know how many fields they map in development per work month. The usual is still around 500.
In 2017 I invented some new ideas and got to 6K-8K fields mapped per 220 hour work month. And recently I invented some more new ideas and we are now at 12K-15K fields mapped per work month. No one else is even close. Not with AI. Not with anything.
In fact, I have had days, very long days, where I have now mapped 1,000 fields in a single day. But now I am 62 I can't work such long days. I used to get paid USD25,000 to map 1,000 fields from a source system to a target. Now I can do that in a day and can't get paid to do so. LOL!
In terms of the future? AI or not? We are now in the era where we can create data warehouses for very large systems. There is just such a data model under development with more than 50,000 fields in the source system and already there are over 100,000 fields in the target data warehouse data model. We expect that model to go past 250,000 fields.
When you can properly map and generate the ETL for 12K-15K fields per work month you can take any source system and build a data warehouse for it.
We can now also co-habit multiple customers data in a single data warehouse data model and we can either have co-habiting data in tables or we can have zero customer data co-habitation in tables and implement security at table level in a co-habited data model. And that data model with one set of tables per customer can be maintained with a single suite of code generated at the rate of 12K-15K per work month with very low maintenance costs.
The logical limit on that single data model on a single machine in a single database is 90 customers.
So you see Olga. We can do all that with zero AI, except for the blog posts to talk about it in a womans voice.
No one else is even close to that level of productivity. And very few people will ever be able to build what it is we are building. It should be fun. :-)
Ok?