The AI Tax and “legal” ways to minimise it
Introduction: The AI Tax Analogy
Krishna, a software developer, opens by comparing organizations' approach to AI adoption with tax planning, arguing that most teams 'throw AI at things' without considering the hidden costs or 'deductions' available, unlike careful tax planning. Technical difficulties briefly interrupt the presentation before he resumes his central metaphor: just as people plan ahead to minimize taxes, engineering teams need to proactively manage the hidden costs of AI adoption rather than blindly adopting it and hoping for the best.
The Hidden Costs: Data from Pharos and NBER Surveys
Krishna presents data from Pharos, which analyzed 22,000 developers, showing that while AI increased throughput by 66%, it also increased production incidents by 200%, code review time by 400%, code rewrites by 800%, and unreviewed PR merges by 31%. He extends this with NBER survey data showing 89% of 6,000 surveyed CEOs/CFOs saw no marginal gain from AI, illustrating that raw productivity metrics mask significant hidden costs—akin to paying full tax rates without claiming deductions.
Historical Parallel: The Dynamo and Delayed Productivity Gains
Krishna draws a historical parallel between AI adoption and the invention of the dynamo in 1882, noting that despite being groundbreaking technology, factories saw zero productivity gains for 40 years because they simply plugged dynamos into existing steam-engine-era processes. He explains that real productivity gains only came when someone rethought factory design entirely—enabling multi-floor factories and distributed small motors—paralleling how organizations must rethink processes rather than just bolt AI onto legacy workflows, citing the copy-paste-into-ChatGPT support ticket example as a modern equivalent of this mistake.
The Productivity J-Curve and Framework Overview
Krishna introduces economist Paul David's insight that general-purpose technologies require time and process rethinking before yielding productivity gains, and presents the concept of the 'productivity J-curve'—an initial investment/dip phase before returns emerge. He argues that we are currently only 3-4 years into the AI era, still in the 'paying down the tax' phase, and previews that the talk will now explore three specific types of AI tax teams must manage: speed tax, skill tax, and scale tax.
Speed Tax: The Cost of Moving Too Fast
Krishna defines the 'speed tax' as the hidden cost of increased AI-driven velocity without corresponding safeguards, citing dramatic examples like Pocket OS deleting its entire production database due to unchecked AI access, and Uber burning its entire yearly AI budget in four months. He recommends mitigation strategies including 'gating before scaling'—implementing stronger CI/PR review checks, pre-push hooks, and validation loops—since AI-written code can't be trusted with the same assumptions as human-written code.
Speed Tax Solutions: Right-Sizing Models and Context
Continuing the speed tax discussion, Krishna advises right-sizing AI model selection rather than defaulting to expensive top-tier models like Opus 4.8, and emphasizes writing detailed context files so AI understands business processes. He stresses maintaining rigorous review flows, citing GitHub's practice of requiring human review on every single PR as a best-practice example to counter the earlier statistic of 31% of PRs merging without review.
Skill Tax: Anthropic's Findings on Cognitive Decline
Krishna discusses the 'skill tax'—the erosion of personal and organizational skills as AI takes over cognitive work—citing Anthropic's own research showing a 17% decrease in task performance and code comprehension among heavy AI users. He also highlights a 50% drop in junior hiring since 2022 (per Mag Seven data), warning this breaks the talent pipeline, and recommends countermeasures like manual code reviews and prioritizing in-person mentorship over AI-driven learning.
Skill Tax Solutions: Tool Sprawl and Junior Talent Protection
Krishna presents BCG research showing that three tools is the productivity sweet spot for teams, with a fourth tool causing a 20% productivity loss, cautioning against indiscriminate tool proliferation. He emphasizes protecting the junior talent pipeline through structured in-person training rather than relying solely on AI to teach new skills, arguing that human mentors provide better guidance than AI for deep learning.
Scale Tax: The Leadership-Worker Adoption Gap
Krishna introduces the 'scale tax,' revealing a stark adoption gap where roughly 76% of frontline leaders use AI aggressively compared to only about 25% of frontline workers, causing significant productivity loss across organizational layers. He cites a 43% productivity loss among middle managers due to unclear KPIs, unreachable goals, and approval bottlenecks, noting only 6% of companies have met their AI ROI expectations—mirroring the dynamo's slow 40-year adoption curve.
Scale Tax Solutions and Case Studies: Zapier, Shopify, and BCG
Krishna offers solutions for scale tax—training managers top-down, budgeting dedicated 'playtime,' and surfacing learnings through regular knowledge-sharing sessions—then presents real-world case studies: Zapier boosted AI adoption from 10% to 97% via a mandatory hackathon, Shopify built guardrails before mandating AI use to avoid Uber/Pocket OS-style failures, and BCG found a 40% increase in complex workflow performance when combining human oversight with AI ('cyborg' approach). He closes by reiterating that the real 'AI tax' is the cost of converting flashy demos into dependable production work, and directs the audience to his source links and LinkedIn for further reading.
everyone. I'm Krishna. And like AJ mentioned, I'm a software dev that writes code every day. And so clearly, tax and legal are not really my cup of the tea. I'm neither an accountant nor a lawyer, so definitely the right person to talk about it in this room. So, this is exactly what I'm here to do.
Let's begin the class. Now, this is a very coincidental thing, but we are in the favorite season of the year, the tax season. How many here really love paying their taxes? Wow. One, two. So, you guys need better accountants.
I don't have any numbers, but I'm sure somebody in this room does. But for most other people, the usual thing that we do is we plan early. We plan for the taxes we wanna pay. We go to our lawyers, go to our accountants, clear up all kinds of legal ways on where you can avoid tax, and try to pay as low as possible.
Oops. Oh, yeah. The problem is most engineering teams, in fact, most organizations are not looking at AI from the exact same perspective. We are looking at it more in terms of let's throw AI at things and we'll figure it out. You're not really looking at the deductions that come with filing that AI tax. So, Okay.
That's not working. Give me a minute, please.
Okay.
Alright. Think it stopped working after that? I I know what's I'm guessing the PPT gods are not with me today. Give me one minute, please. Let's restart.
K. Alright. Oh, just gonna open it up again and see if that works. Oops.
That was not what I was expecting. My bad guys. One minute, please. Okay. Yep. Alright. Got it.
I did not answer my prayers this morning. Apologies. Let's go again. Right. So we're not looking at taxes or the AI tax that our teams pay the same way we're looking at taxes. What do I mean by that? There's a company called Pharos, which sort of manage engineering pipelines.
And they did a They've got huge amounts of data on managing git pipelines, any other code tools that you have, Gitlabs. And they came up with a report around 22,000 developers and how their productivity has gone up slash down in the AI world. And good news is, people who were using AI had 66% extra throughput, which means for every 100 lines of code that you could write before AI, you could now write 66 lines more.
Great. Your team is so much more productive. But that was the only good news from that report. They also saw that, just like that, the incidents that were happening in the product PRs that have gone up to production increased by 200%, 242. The number of the amount of time it took for a regular code review went up by 400%, four times what you would take before that.
The amount of code that got rewritten went up by 800%. Because it's very easy to write code, which also meant you could write really easy wrong code. You had to rewrite it a lot of times. Believe me, I've done that. The amount of time it took, sorry, the amount of PRs that got merged without any review, just here's a PR, we don't have time to review it, we need it outside, let's go merge it, happened 31% of the times.
Now, those are big numbers. What that really means is that while at the face of it, you feel, wow, there's a new feature coming up. I can write it in two minutes. I'm done. And that goes up, you're good. But it comes back and bites you like your regular tax season if you don't plan ahead. And what you end up with, really, is a big bill that says, sorry, you're not really further ahead.
You're far behind than what you should be. Pay a 100,000 more in taxes. So if your team is looking at the 66% throughput that you're getting right out of AI and you're saying, perfect. AI is great. I'd say, look again. Read your full invoice. And they're not the only ones.
This has been a recurring theme across different industries, different domains, different surveys. For example, NEBR, NBER, the Economic Research Survey. They surveyed 6,000 CEOs and CFOs. And what did they find? 89% of the people believed they have not gained any marginal gain out of using AI.
They've tried it, they've used it and they just, it works. Not really. They were paying the full rate but they were not filing any deductions, so they'd not really see the profits that should come through. Your revenue was super high, so were your costs. Now, I did not I do not know if that was the right term in the accountancy world.
Can anybody correct me if that was? And to be very honest, AI is not really new. When I first started writing code, there was this new shiny thing called Wix that came up. And everybody told me, you know what? Stop writing code. The front end developers and most development website building is gonna die off.
Now, here we are, more than a decade later, I do not think it died off. People started building more websites and people started writing more code. Yes, Wix worked great for a lot of people, but we still write code. The industry IT industry in general has not gone down really. What has changed is how we work.
Now we have a lot more frameworks and stuff. And it has been a recurring theme throughout history. How many here know what a dynamo is? Just one person? Two? That's it? Alright. So dynamos are effectively little motors that can kind of run anywhere. Would I be right? Yeah. And they first came out in 1882.
Edison claims that he was the one who invented it or at least commercialized it. And it changed the world. It changed the world that we we live in today. The problem was, it did not change the world back then. In fact, it took forty years to change the world. They had zero productivity gain out of a groundbreaking technology for forty years. Now, why was that?
Let's look at it this way. You've got, say, a new vacuum cleaner. Any of you use the robotic vacuum cleaners in the house? Now, the great thing about them is you turn them on, you leave them around and they keep doing their work. And you're like, perfect. What happens if you keep following it around saying, let's see if it does it correctly.
Let's mop it away wherever it does not work. That's exactly what people did with Tynamos. They replaced the existing steam engine, really big bulky rooms, exactly that way. Just plug it in and say we're done. We've got the new shiny tech. Our perfect system is working exactly as it should be.
We are happy. But what that did not do is it gave zero productivity gain because the exact processes around it did not change. Just because you have this shiny new tech, shitty process do not work for themselves. And by nineteen twenties, forty years after that, most factories gained barely 5% productivity.
That's just because dynamos work faster. But then, some brilliant guy came up and said, you know what? Let's tear down the whole factory. Let's rethink how we can use the dynamos rather than using them like shiny and newer steam engines. They built better pipelines. They removed So with dynamos, there was more of a central structure.
You had one Sorry. With steam engines, you had a central structure, one big place where everything worked and everybody had to work close to it to get your assembly lines working. With dynamos, you did not need that. You could plug it in wherever you need to. Really small dynamos, like the small LLMs we talked about earlier, which does exactly what it needs to, where it needs to.
You could now build multi floor factories. You could build pipelines that work in really small rooms and then ship products to the next room rather than having one big room that needs to connect everything. And suddenly, productivity productivity went up by a lot. Then we live in a newer world where we have faster cars, more industrialization and none of it would work on the existing steam steam engines. Now, why is this important?
The story here is not did they have bad tech. The historical pattern here was they had great tech. They had brilliant minds. What they were missing is rethinking of how to work with that tech. And we are in a similar world today where we need to start thinking about not how can we plug in AI into our existing systems and try getting it work.
I'll give you an example. Support tickets. I've seen teams try something along these lines. Tell me if this is something you've seen. You've got your knowledge base on Confluence. You've got a support ticket, say, in services that come in. You copy paste it, throw it in chat g p t, copy paste your knowledge base, throw it in chat gpt and assume it will work. And probably, fingers crossed, pray, I don't know, do some donations or something, burn paper money and hope that just works out of the box. That's your existing process that's just being thrown at AI. That's not really rethinking anything.
And somebody, Paul David, great economics, captured it. He said, any new technology, any general purpose technology, when that comes out, does not give you productivity gains out of the box. It takes time. And what takes time is that it's introduction of the new technology that you need to rethink your process with.
It's not gonna right off the bat just make you super productive because it exists. In fact, an economist recently came up with the idea of a productivity j curve. What is this? For any new general purpose technology, when you start off, there's a period of investment. That is where you're paying down the tax and figuring out how to minimize it. And then you slowly go up, claim it back, get productive, get faster, get cheaper.
Right now, we are year three slash four of the AI world. I know, it feels like forever. But it's just very early and we are in the paying down the tax phase. So we're good to go. We still we still have time to get our refunds. And at this phase, what we really need to start doing if you wanna gain that productivity gain that 90 89% of those managers did not see is start thinking about where does your investment go?
What are the different taxes you're paying? Where are the areas of rethinking? Now, that's a lot of talks about process. So let's start jumping into a little bit of it. What are the three different So with taxes, I'm not sure where how many people of here are from Australia, but outside of Australia, the world is a little more weird where you have too many taxes. I come from India and I remember filing my taxes around ten years ago where we had 12 different brackets of really small taxes, 5% for state tax, 12% for CGT, and a bunch of other taxes for no fucking reason.
It does exist. So there's different types of taxes you gotta pay down. The government wants it. You can't really help it. It's the perfect money laundering scheme in the world, to be honest. But what can we do? Same with AI. You gotta pay your taxes. What's the the first tax? I've tried to keep it down narrow. The first the first tax that you gotta pay down is the speed tax. What does it mean?
You've given your team AI. They're going faster and faster and faster. But with that speed comes a comes a cost that you pay gotta pay down to maintain it. Not just, you can't take an f one car and expect it to run on the road. That's gonna be a recipe for disaster. There's a skill tax. People who are using these tools, there are lots of studies showing how people are losing their existing skills.
Also, there's a lot of requirement of people learning new skills. And there's a skill tax, which is as an individual, it's great that you can figure out things on your own and you can learn a lot of things. But for a company that has a 100,000 people, that is not gonna work. Because if everybody starts experimenting, who puts the bill?
So let's talk about the speed tax. This was regular dev day. You'd open up your laptop, spreadsheets, do some work. Probably not spreadsheets. Not a big fan of them, but it just chill out, calm down, do some work. And AI came into the picture.
People started becoming a little more like this. Because now, everybody could do everything. You could open up websites, you could write code to do Python scripting, you could build presentations in five minutes. For that matter, this one was built on AI because I am absolutely horrible with PPTs. So I used HTML to build my own.
But it opened up a world of possibilities. The problem is, it has to come with its own guardrails. Otherwise, everything around you starts breaking down and you notice it when it comes to you. So a quick example of what that looks like. I think this example has been talked about a lot in this room. Pocket OS, they deleted their entire production dataset.
They just gave AI the wrong access. It found credentials somewhere that it should not have. And it thought, let's fix it. And the fixing was, let's delete production database because it does not need to exist. And other examples. Some Uber had this recently, I think a few weeks ago, where they started with let's experiment with AI and they did not think they need to put any guardrails.
They just said, go on, try what you want to. Let's see how that goes. It did not go well, unsurprisingly. They burned all of their yearly budget in just four months. So how do you reduce your speed tax? What can you do there? Gate before you scale. The first and foremost thing, the most important thing that you wanna do, this is more for the engineering level tech leads, senior leads.
You wanna start gatekeeping things. The right checks are much more important now than they were before. If I, as a developer, could write say a 100 lines in one minute, I cannot, but let's assume I could. I would write those 100 lines and a few more and then send it to somebody to review. And then there's a human assumption that I did not do shitty work. Yes, there's also peer reviews and checks and everything else, but there's an underlying assumption that I did not do shitty work.
I could have, I would probably would have in the start, probably still do. And there's people that think, you know what? Krishna is great. He writes good code. And they keep finding themselves wrong eventually. But with AI, that's a very hard assumption. Depending on what models you're using, what structures, paradigms you have, what kind of knowledge you've given it, it does not know everything that you do in your team.
The six months of discussions on what your business process are are not known to AI. So what happens is that it writes some code that it thinks is right and then if you do not have right checks in place for your CI, PR reviews, all kinds of pre push, commit hooks, it takes more time but it helps your AI models to run faster. Your people using those AI models to run faster.
Because now you can be much more sure about how they're not writing bad things. For example, my own loop kind of has a keep checking it using play iRoot every time you do it. So something that AI could have written in two minutes usually takes twenty for me. But I'm very sure that the output is right. Right size for the model.
Now this one is a little bit tricky. It's a little more related to what was talked about earlier. You don't wanna throw everything at super high cost OPUS 4.8 or Codex 5.5 models. Wanna size it right, a lot of the cheaper models do really good and that protects your scale. Context. This is really, really important. We've started doing this a lot more aggressively in all of our teams that we've worked with where every time you have tokens to burn, say end of the month, you've got a lot of tokens to burn on your Kiro, Copilot or CoCloud subscriptions, write context files.
Make sure your AI is aware of your business process. That is the key structure requirement for them to be able to write good code. Follow your process. Your process need to be available. It needs to be part of your team infrastructure. Review flows. Remember this previous number where we saw 30% of your reviews go unreviewed? That should not be happening.
And there's good examples of this. GitHub, for example, aggressively maintains this. Not a single PR goes out without a human review. Sorry? True. I mean, yes, true. Skill tax. Now, I have noticed in my own experience that with AI, I've I've probably started writing a lot more code.
I've started learning a lot less from writing code because now it's less of me figuring out how to write code, more of me figuring out how to make the system work. And everybody kinds of feels like this kind of. Because you can write code, you know quantum physics, you know spirituality, you know history, you know geography. Everything that was once research and Google searches and asking to peers is now available at your fingertips.
The sad reality is you've got the AI tools, superhuman stuff. The person inside is really not able to keep cope with it. You kind of start feeling, I don't know, like are you losing your skills? You start having that mental load and there's a lot of other things that can happen in terms of how your mental health is. But for this one, let's focus on how your skills are degrading. And this is not just me saying it.
Anthropics says it. Yes, that one. The one that got trillion dollar valuation just a couple of days ago, who thinks they are the best at AI or claims they are the best at AI and I'd I'd probably agree with them at most points. But people who keep using AI aggressively have seen 17% decrease in terms of how good they are in regular everyday tasks. How good they have a comprehension of their own code.
And I've seen the same thing in my examples, to be honest. Now, that's not the only problem. I think a lot of the firing that has happened recently and a lot of hiring freezes and people talking to people who are recent grads, There's a huge gap in terms of people who are being hired. 50% according to Mag seven since 2022.
What does the what does this do? It removes the pipeline that you are building for the seniors that you're gonna build. How to reduce the skill tax? I'd say think first, definitely. Stop giving AI all the work you need to do thinking. Cognitive tax is really bad. Code reviews. We've started this in our teams.
A lot of people have slowly realized that this is probably the most important part of how you can still skill up without having to write code yourself, which is manually aggressively review. Don't leave it to Copilot to review your code. Tools. Now, there's a lot of push in and a lot of companies where they just give everybody AI and see what they come up with. And there's PlotCode, Codex, Notion, bunch of PPT tools, All kinds of different solutions that just are available.
Having more tools did not make you more productive, unfortunately. BCG did did a research in terms of how many tools is good number of tools. Boston Consulting Group, one of the huge consulting groups. And they found three is the sweet spot. Anytime after three, if you had four, you'd lose around 20% of your productivity. Protect the junior pipeline.
This is also hiring but a huge amount of it is also training and learning. Where your training and learning should not be go talk to AI. It should be more in person. When you talk to AI, you're not really understood in terms of what do you need to learn. It's a figure out challenge for most people. Like, if I wanted to go learn quantum computing, I would not know where to start.
And I'd probably learn whatever my Claude or Chad GPT tells me. But that's probably not the right way to get deep into it. It's the best people who can tell me what to do is the people who are doing it. Scale tax. Now this is my favorite one. It's also got my favorite meme. A lot of the companies today look a little like this.
How many of you agree? There's a huge race happening in terms of let's adopt AI and try and do more and more and more. And the consequence of that, it's just being given to everybody and let's try fit AI into everything. The problem is along these lines.
What do you guess the number is how many frontline leaders are using AI aggressively? Just a vague guess. Any number. Sorry? Alright. 76. So they're using it a lot more aggressively.
What about frontline workers? Any other guesses? 90. Sorry? Five. Alright. Too low. 25. You see the big gap there? Most companies are not built purely on leaders. They're built on everybody in the company.
There's a huge divide in terms of who's using it and who's not. I know I'm running out of time. Sorry. Right. Now, that divide is where most of your productivity is eaten up. And studies show 43% of the middle managers and the of layers from top level leaders to the bottom level front line workers is where a lot of that is lost.
And there's different reasons for it. It could be approvals, it could be deprioritizing AI work because you don't really need know what to do. You wanna use AI, you don't know what to do with it. How to do it? How do you measure your KPIs? There's no way to really say one bucket fits all. Or there's unreachable KPIs.
Let's get 500% more customers for some reason. Reality is only 6% of the companies have hit their ROI expectations in terms of API, which is pretty low, close to what we had in the historical 5% after forty years frame. I expect it does not take forty years, you know. Now what do you do here?
Train your managers first. It has to flow top down one by one. Every level has to get trained and then upskilled and then keeps upskilling the next level. Budget of playtime, you gotta have that time to say, here's one day, go try it out. Surface learnings. So I work in a company with a thousand people and everybody's learning new things.
So we've started doing monthly one time alls or weekly smaller group setups where you go learn things about how people are using AI. It could be absolutely common sense, but a lot of times it's just not very common. You gotta look at somebody doing it to be, oh shit, that was so obvious. And track your clocks in terms of how much you're spending on productivity and how much you're spending on learning.
You gotta do both sides. You can't just excite to work without doing the other. Now, we've talked a lot about what taxes are and what we can do to fix it, but I did not come up with all of this, guys. I apologize. A lot of companies have tried these things. A lot of companies have worked on different things that worked out.
So let's look at a few examples. It's not exhaustive. It's not complete. Now this one is from Zapier, the company that's connecting and doing automations. Their literal whole job is let's do automations. And their company had 10% adoption for some reason. Because they had a lot of people that did not wanna try using AI or did not think they're comfortable using AI.
What did they do? They built guardrails, built budgets, created a one week hackathon saying, go try it out. Everybody's allowed to. Everybody sort of needs to. And that peer to peer motivation slash peer pressure, however you put it, worked for them. They had 97% option just one week later.
Alright. Shopify, the other big company that has lots of lots of infrastructure. Now these guys also did not mandate their company or rather, they they did mandate, but they did not mandate until they were ready for it. One of the biggest problems like Uber or Pocket OS saw is that they did not build the right guardrails. Hence, the whole we burned our production database kind of problems.
So build your guardrails first before you do the mandate. This is my favorite. Oh, shit. Yeah. BCG, they did a study where they trained managers or even developers to start doing more invested code reviews or invested code development where people do not just give AI to do stuff.
They saw 40% increase in what their complex workflows look like. The censure approach where you're half human and half AI. I would say Cyborg is the right one for it. But yeah, so I think that's what I'd leave you guys with. The tax of converting astonishing demos into dependable work is what your AI taxes are on.
You can come up with a really good slide like this one very quickly. Does it help? Production? Not really. And then you spend three days in churning and churning and churning and sort of coming up with something. Alright. I've used a lot of sources in this one. If someone wants to click a picture, take slides and go read up all the surveys and documents and research studies, there's links there.
If anybody wants to collect, there's my LinkedIn. Thanks guys. I took up a lot of your time. Thank you so much. Great audience.
People
- Paul David
- Thomas Edison
Technologies & Tools
- ChatGPT
- Claude
- Codex
- Confluence
- Copilot
- Dynamo
- Kiro
- Notion
- OPUS 4.8
- Python
Concepts & Methods
- AI Tax
- Gate Before You Scale
- Productivity J Curve
- Right Size For The Model
- Scale Tax
- Skill Tax
- Speed Tax
Organisations & Products
- Anthropic
- Boston Consulting Group
- GitHub
- NBER
- Pharos
- Pocket OS
- Shopify
- Uber
- Wix
- Zapier
AI tools feel productive. That’s the problem.
A 2025 METR study found experienced developers were 19% slower using AI on their own codebases, yet believed they were 20% faster. I didn’t need a study to tell me something was off. I could feel it: more code shipping, more bugs slipping through, reviewing functions I couldn’t quite explain, and a growing sense that I was managing a workflow rather than doing engineering.
That’s the AI tax. The hidden overhead that accumulates every time you prompt, verify, redirect, and re-contextualise. It doesn’t show up in your commit count. It shows up in your cognitive load, your code familiarity, and eventually your production incidents.
This talk is about what that tax actually looks like day to day, why it’s hardest to spot when you’re most productive-feeling, and the practical strategies I’ve used to minimise it without throwing away the tools.














