If you follow my notes, you know I have been spending time connecting with data folks here on Substack. Reading their work, exploring their projects, tools, research, and everything in between. At some point during a conversation with , something clicked. These people are building genuinely interesting things. Why not bring them together in my publication and get their work in front of more eyes? That is how this started.

Data Stack is an initiative to bring developers, engineers, and practitioners working in Data, ML, and AI together in one place. The goal is simple: build a real community around the work, not just the discourse.

The Roundup is one part of that. Builders submit their own projects, in their own words. A tool, an app, a dataset, a course, a research paper. Something they built and something useful to people in this space. What gets submitted is what gets published, no editing, no paraphrasing.

The first edition features 5 projects from 5 contributors including me :) Different backgrounds, different problems, different tools. Take what is useful, follow who interests you, and if you are building something worth sharing, the next edition is open for submissions.

🛠️ The Projects

01 - SnapTask

By YAZ - Mobile Architect & Independent Developer

🔗 SnapTask

02 - DFM

By - Independent Developer

🔗 No link was shared by Martha.

03 - 2026 Roadmap to Becoming a Data Analyst

By - Data Analyst

Above Average Analyst

2026 Roadmap to Becoming a Data Analyst (1 of 5): Excel or Google Sheets

Hi, fellow future and current Data Coworkers; Brien here…

Read more

4 months ago · 17 likes · 4 comments · Brien Grant | Data Analyst

04 - Blog2Video App

by - AI Engineer

🔗 blog2video app

05 - KI Reads

By 😊

🔗 KI-Reads

That wraps up the first edition of The Roundup.

These are real projects built by people actively working in the data and AI space. If something caught your attention, follow the builder and dig deeper. The best way to support this kind of work is to engage with it directly.

The next edition is already in the works. If you have something worth sharing with this community, submissions are open.

See you in the next one!

Subscribe now

Buy me a coffee

Leave a comment

There’re many blogs who write about data but they’re scattered across platforms(Substack, WordPress, Ghost, Medium) and keeping up meant checking multiple places, forgetting half of them, and missing posts I would have genuinely enjoyed. I wanted a single weekly reading list, curated by me, delivered to me. So I built one.

This post walks through what I built, how it works, and one failure that taught me something useful about cloud infrastructure and platform policies.

The Idea

I started simple. I wanted a script that reads a list of newsletter URLs I chose, fetches whatever was published in the last seven days, and puts it all in one place. No algorithms deciding what I see, no platform telling me what is popular. Just the writers I chose, their latest work, organized the way I want.

The input is a plain Excel file with three columns: the newsletter name, the URL, and a label I assign to group things by topic. The output is a markdown file I can read in VS Code. One command, once a week.

Building for Multiple Platforms

The first real challenge was RSS. Every platform handles it slightly differently.

Substack feeds live at publication.substack.com/feed. WordPress is usually yoursite.com/feed. Ghost uses yoursite.com/rss. Medium uses medium.com/feed/@username, a different structure than you might expect. Beehiiv generates a unique URL per publication that cannot be derived from the main URL at all.

Rather than asking people to find their own RSS URL, the script tries a series of known paths in order until one returns entries:

RSS_PATHS = [
    "",
    "/feed",
    "/rss",
    "/?feed=rss2",
    "/rss.xml",
    "/atom.xml",
]

Beehiiv is the only platform that still requires a manual step. The script detects it and prints a specific message explaining exactly where to find the RSS URL in the page source.

One thing I added after the first few test runs was HTML stripping on the excerpt field. Medium especially embeds raw HTML in their RSS summary field. Feedparser returns it as-is, which means your digest ends up with <img> tags and <a href> strings in the excerpt if you do not strip them. A quick regex pass and html.unescape() handles it cleanly:

def strip_html(text):
    text = re.sub(r"<[^>]+>", "", text)
    text = html.unescape(text)
    text = re.sub(r"\s+", " ", text)
    return text.strip()

Parallel Fetching

The first version fetched feeds sequentially, one at a time. At ten newsletters that was fine. At fifty it would have taken several minutes. The fix was straightforward. Python’s concurrent.futures.ThreadPoolExecutor lets you fetch multiple feeds simultaneously. With max_workers=10 the script fetches up to ten feeds at once. At a hundred newsletters the fetch step now takes roughly the same time as ten did before.

The Feeds File

The input is intentionally simple. An Excel, CSV, or plain text file with your newsletter list. Three columns: name, url, label. The script detects the file type automatically. No config needed beyond pointing it at your file. Labels become the section headers in your digest, so you can group things however makes sense for you, by topic, by reading priority, by platform, anything.

The GitHub Actions Experiment

Once the script was working locally I wanted to automate it fully. GitHub Actions seemed like the obvious choice: free, version controlled, runs on a schedule. I set it up to run every Sunday morning, stored nothing sensitive, and triggered a test run. It failed immediately. Every RSS fetch returned empty. No entries, no errors, just silence. Adding debug output revealed the issue:

HTTP 403 for https://example.substack.com/feed

Substack was blocking every request. Adding browser-like User-Agent strings and Accept headers made no difference. The problem was the IP range. GitHub Actions runners use well-known cloud IP ranges that Substack’s CDN recognizes and blocks. Residential IPs go through fine. Cloud provider IPs do not.

The workarounds I found, residential proxies and third-party RSS caching services, all introduced dependencies I did not want. Some would work today and break in six months. Others added ongoing costs. So I made a pragmatic decision. The script runs locally on Sunday mornings. Total runtime is under a minute. The automation saves hours of manual work even without the cron job.

The Output

The script generates a markdown file named by ISO week number. Each week gets its own file, nothing is ever overwritten, and they accumulate as a personal archive. Posts are grouped by whatever labels you assigned in your feeds file. Each entry shows the post title as a clickable link, a short excerpt, the newsletter name, and the publication date.

Opening the file in VS Code and pressing Ctrl+Shift+V renders the preview with clickable links. Copy from the preview panel and paste directly into Substack, Notion, or anywhere else you want to read it.

What I Would Do Differently

The Beehiiv situation remains unsolved. Their unique RSS URLs cannot be derived from the publication URL and the script cannot auto-detect them. It works but it puts a manual step on the user that every other platform avoids.

For larger feeds lists, parallel fetching handles the speed problem well. But Google Sheets as a backend for a multi-user version would hit limits. A proper database becomes necessary at scale.

Where This Is Going

The personal digest tool works well enough that I packaged it for others to use. If you want your own weekly reading list across any combination of Substack, WordPress, Ghost, Medium, and more, the tool is available with a full setup guide.

But the more interesting direction is community. Once I had the personal version working, I built another one: a community version. A niche hobby community I am part of wanted a way to surface new writing from their members from different platforms every week. So I built a version for exactly that. It has been running for a month now and so far it works exactly as intended.

Two tools, one pipeline, built entirely on free tiers. Sometimes the best projects are the ones you build for yourself first.

Subscribe now

Leave a comment

Buy me a coffee☕

I didn’t start with a grand strategy. No content calendar, no growth hacks. I started because I wanted to write about the gap between what people think data science is and what it actually looks like when you’re in it. The reasoning, the tradeoffs, the messy middle, the quiet decisions that shape real systems and rarely make it into blog posts.

I also wanted to slow down. The AI world moves fast, sometimes too fast, and writing forces me to choose what actually matters. It became a way to reconnect with my own expertise, to put into words the things I’ve learned over a decade of building, breaking, and fixing. So I published the first post. Then another. Now I’m looking back at six months of it.

The First Six Months in Numbers

Six months is long enough to see patterns. Around 15 posts published, just over 120 subscribers, engagement that is slow and steady. The numbers are small, I know. They are also honest.

Data science and AI are crowded spaces, and most content out there is optimized for speed and surface. I was not immune to that pull early on. My first posts leaned into AI topics because that is what felt urgent, what everything was pointing at. It took a few months and a few posts that did not quite feel like mine to figure out what I actually wanted to say. Somewhere along the way I found my way back to the thing I started this for: the practical, often unglamorous reality of working with data at a professional level. That drift and correction probably cost me some early momentum. It also gave me a clearer sense of direction than I would have had otherwise.

I write when I have something worth saying. I focus on insights from real work, the kind that take time to develop and do not compress well into a carousel. That choice leads to slower growth, but it tends to attract readers who stay. I am comfortable with that tradeoff.

The Break I Had to Take

Somewhere around month three, I stopped writing. Not because I ran out of ideas, but because life made it impossible to think about anything else. My mother has been fighting cancer, and I needed to be with her for a while, as I should have.

I am not sharing this for sympathy. I am sharing it because honest reflections on creative work should include the parts where it stops, and why. Writing requires a kind of mental availability that you cannot always guarantee. Sometimes the right move is to close the laptop and be somewhere else entirely. Things are more stable now. I came back when I was ready.

What I Learned in Six Months

The obvious answer is that I found my voice. The less obvious answer is that it took longer than I expected and I am still refining it. I know now that I want to write about data, the real work of it, not the hype. That clarity did not come from planning, it came from publishing things that felt slightly off until something finally felt right.

Time is a real constraint. I have no shortage of ideas but finding the hours to develop them properly is harder than I anticipated. Writing that reflects 13 years of experience does not come out in a sitting.

I also shared a tool I built, something I was genuinely proud of. The response was quiet. That used to be the kind of thing that would make me second guess whether any of this was worth it. Strangely, it did not. I think I am starting to separate the work from the reception, which feels like progress.

What I am still learning is how to share. Building things comes naturally to me. Putting them in front of people, talking about them without underselling or overthinking, that is the muscle I am actually developing here. Substack is teaching me that more than anything else.

And then there are the other writers. I spend time reading how people here structure their thinking, find their rhythm, express themselves. It is the best kind of learning, watching people do the real thing in real time, not a course or a framework, just someone figuring it out in public. I find that genuinely inspiring.

What I’m Working On Now

I build things. That has always been true, and Substack has not changed it, if anything it has given me more reason to connect the building to the writing.

Right now I am working on two projects. One is a fully automated weekly digest for a niche hobby community, a pipeline that aggregates content from writers across Substack, WordPress, Ghost, and Medium, organizes it, and ships a publication every Sunday without manual work. It is the kind of infrastructure problem I enjoy: unglamorous, quietly useful, and harder than it looks.

The other is a research intelligence pipeline that monitors AI sources daily and turns papers and blog posts into structured, actionable summaries. The same system can be configured for any domain. I am still validating whether there is real demand for it, which is its own kind of data problem. Both projects will feed back into this publication. That is the idea anyway.

What I Plan for the Next Six Months

More posts, more projects, more showing up. I want to write with the consistency that I have not quite managed in the first six months, and I want to build something that feels less like a publication and more like a community. A place where people who work with data seriously, not people chasing the hype, can exchange ideas, push back on each other, and learn from real experience. I also hope not to need another break. That one is not entirely in my hands, but things are more settled now and I intend to use that. The honest version of any plan at this stage is just: keep going. So that is what I am doing.

To everyone who stayed subscribed through the quiet months, through the gaps and the silences and the stretches where I was not even here to notice, thank you. It means a lot to me. I will try to be more consistent from here. Not a promise, just an intention, and a genuine one. And if things go the way I hope, I will be back in six months with another one of these posts to see how it all turned out.

Leave a comment

Subscribe now

It sounds like a breakthrough, but if you have spent years in the trenches of data science, this feels like a familiar story with a new coat of paint.

What is the “Context Layer”?

Technically, the context layer is a decoupling of business logic from the raw data storage. According to recent 2026 research from Strategy, it is now categorized as “Context Infrastructure”. Instead of an AI agent looking at a raw SQL table and guessing what “customer_id” means, the Context Layer provides a semantic map, identifying that “customer” in this table is the same “entity” as “user” in another.

This involves Context Engineering, which is the process of making tribal knowledge machine-readable. It ensures the AI knows that “Revenue” in a sales report means something different than “Revenue” in a tax filing. However, a Drexel LeBow study from early 2026 found that while 87% of leaders claim their data is AI-ready, nearly half (42%) admit their infrastructure is actually their biggest obstacle. This disconnect happens because we are trying to build advanced context on top of existing debt.

Anchoring Context in Reality: The Audit

In my previous work, I’ve argued that you cannot build these high-level contextual maps if you are still paying interest on the basics.As I explored in 10-Minute Data Strategy Audit: Part 1 - Infrastructure Debt, infrastructure debt manifests as “Toil”, the manual, repetitive work that eats your team’s time.

If your critical models only run on one person’s laptop, your Context Layer will never be more than a prototype.

Furthermore, in 10-Minute Data Strategy Audit: Part 2 - Data Debt, I noted that the most expensive kind of debt is Data Debt, which destroys trust.

When an AI looks at a Shadow Dashboard created by a VP who doesn’t trust the official numbers, the AI inherits that lack of shared rules and begins to hallucinate.

A Pragmatic Solution

The solution isn’t to buy a “Context Infrastructure” platform and hope it solves your governance. True AI-readiness comes from reducing the surface area of your debt so the AI has a clear signal to follow.

• Define the Handshake: Before building a semantic map for an AI, fix the Data Contract between the software engineers producing data and the analysts consuming it.

• Automate the “Boring” Foundation: Target the manual restart in your pipelines. If a system requires human heroics just to stay online, it will never be stable enough to support an autonomous agent.

• Consolidate the Truth: Identify the core five metrics everyone uses. If your humans haven’t agreed on what “Active User” means, your AI certainly won’t find the answer in the metadata.

AI readiness is often described as something we’re chasing, but it really reflects how well we’ve handled years of ignored data debt, because the “Context Layer” only works when the foundations beneath it are finally stable. Being ready doesn’t come from buying a new tool; it comes from having infrastructure that runs reliably through automation and data definitions that are documented clearly enough for people to trust.

When a team can answer “Where did this number come from?” with a shared, well‑documented explanation, they’re already ahead of the 60 percent of companies Gartner expects to struggle, and they’re in a place where machines can actually learn from the systems humans have built.

Resources& Further Reading

1. Atlan. (2026, March). Key Takeaways from Gartner Data & Analytics Summit 2026.

2. Drexel University, LeBow College of Business. (2026, January). The 2026 State of Data Integrity and AI Readiness.

3. IBM Think. (2026, February). Why AI Data Quality is Key to AI Success.

4. MicroStrategy / Strategy Software. (2026, April). Why Gartner Just Put the Semantic Layer on the Same Level as Cybersecurity.

   Leave a comment

   Subscribe now

Subscribe now

Where it started

It started the same way a lot of side projects start, with a problem I couldn’t find a good solution to. I wanted to understand my own taxes as a self-employed person in Quebec. I tried building an Excel sheet first, which worked until it didn’t. Then I looked at existing free tools and found most of them were built for employees, not for people running their own business. So in December, I put together a very basic first version in Streamlit, just enough to answer my own questions. It was rough. It only covered QC, the QPP calculation wasn’t fully correct, and it didn’t explain much. But it worked well enough to show me the shape of what I actually wanted to build. So I kept going.

The tech stack

Nothing exotic here. The whole thing is built with:

• Python: core logic, all tax calculations.

• Streamlit: app framework and structure. Streamlit’s native components are fine for quick prototypes but they have real UI limitations when you want something that looks finished. So a meaningful chunk of the visual layer, the metric cards, the breakdown table, the styling, is hand-written HTML and CSS injected directly inside Streamlit. Not the most elegant approach but it gets the job done and gives you control that native Streamlit components simply don’t offer.

• Plotly: the charts. The donut chart for income distribution is straightforward. The Sankey diagram was a deliberate choice, it traces every dollar from gross income through expenses, contributions, and taxes to take-home pay in a way that’s immediately readable even if you’ve never looked at a tax breakdown before. An accountant doesn’t need it but someone trying to understand their taxes for the first time does.

• Pandas: expense tracking and data handling.

The tax data lives in a separate Python file as structured dictionaries, federal brackets, all 13 provincial bracket tables, Basic Personal Amounts, CPP and QPP data. No database, no JSON files, just clean Python dictionaries. Simple, readable, and easy to update when rates change every year. Keeping it completely separate from the calculation logic was one of the better early decisions, it means updating 2026 rates next year is a straightforward data change with no risk of touching the calculation logic.

The whole thing is deployed on Railway on the free tier for now. Straightforward setup, no surprises.

The hardest part: verification

Building the UI was the easy part. The hard part, genuinely the most time-consuming and at times frustrating part of this whole project, was making sure the numbers were actually right.

Canadian tax is deceptively complicated. On the surface it looks straightforward: progressive brackets, apply the Basic Personal Amount, done. But the details add up quickly. CPP has two tiers now with different deductibility rules. QPP in Quebec has an additional first tier contribution that most calculators miss entirely. The Quebec federal abatement needs to be applied to pre-credit federal tax, not post-credit. Ontario has a surtax and a Health Premium that are separate calculations. Alberta introduced a new 8% bracket in 2025. Provincial Basic Personal Amounts vary across all 13 jurisdictions and several of them changed for 2025. GST and HST rates differ by province and Nova Scotia quietly reduced its HST from 15% to 14% in April 2025.

Every one of those things had to be found, verified, and cross-checked. My process for this was layered, I used both Claude and Gemini to check the logic and flag potential errors, then verified every number against official sources: the CRA website, Revenu Québec, provincial government pages, and trusted third-party references like TaxTips.ca. This sounds methodical but in practice it meant a lot of back and forth, a lot of “wait, that doesn’t match what the CRA page says,” and more than a few cases where one AI flagged something the other missed, or where both were wrong and the official source was the only thing that settled it. The QPP first additional contribution debate is a good example, there was genuine ambiguity about whether 10.8% or 12.8% was the right self-employed rate depending on how you interpreted “base rate,” and it took going directly to Revenu Québec’s own documentation to confirm the correct answer and understand exactly why.

I used AI assistance throughout the build, for logic checks, catching errors, and as a starting point for research. But I treated every AI output as a first draft that needed verification, not a final answer. For something like tax calculations where being wrong has real consequences for real people, that extra layer of checking against authoritative sources wasn’t optional. It was the whole point.

The final sanity check was running manual calculations for three provinces(Ontario, Quebec, and Alberta) at $80,000 gross income with no expenses, verifying every single component by hand against CRA published figures, and confirming the tool’s output matched to the cent. That’s when I felt confident enough to share it.

What’s next

Honestly? Not much in terms of features, at least not immediately. This tool was built for me and for other self-employed people in Canada who just want to understand their taxes without paying for software or hiring an accountant for a back-of-envelope estimate. It’s free, it’s going to stay free, and there are no plans to monetize it. No premium tier, no subscription, no ads.

What I will do is update it with 2026 rates when they’re confirmed, probably toward the end of the year when CRA and the provinces finalize their numbers. So if you’re bookmarking it for next year, it’ll be there and it’ll be current.

If you also build tools, I’d be curious what you would have built differently. Different stack, different architecture, different trade-offs. There’s no single right way to go from a messy Excel sheet to a deployed tool and I think those decisions are worth talking about.

If you haven’t read my previous post, you can read it here.

If you’re self-employed in Canada and haven’t tried it yet, access the tool here.

If you’d rather read how it works before diving in, there’s a full user guide here.

If you have any questions or any feedback let’s chat in the comments.

Important Disclaimer: This tool provides estimates only based on publicly available 2025 Canadian federal and provincial tax data. It does not account for all tax situations (e.g. RRSP deductions, disability credits, provincial surtaxes, investment income, capital gains, etc.). Always consult a licensed Chartered Professional Accountant (CPA) for accurate, personalized tax advice. Use at your own risk. The CRA and Revenu Québec are the authoritative sources for all tax obligations.

Leave a comment

Subscribe now

Subscribe now

Then AI coding assistants became actually useful. And something shifted, not in what I could do, but in how fast I could do it and what the end result looked like. I want to be honest about what that shift actually means in practice, because the current conversation tends to swing between “magic” and “useless,” missing the nuance of the middle ground.

The part nobody talks about

AI is genuinely useful to me when I already understand the problem. When I know what I’m trying to build, what the constraints are, what the right approach looks like, AI helps me get there faster. It fills in the gaps, handles the parts I’d otherwise spend an hour Googling, and helps me move from idea to working code without losing momentum.

But when I don’t fully understand the problem, AI makes things worse, not better. It gives me answers, confident, well-formatted, plausible-sounding answers that go in the wrong direction. And if you don’t have the background to recognize that, you can spend a lot of time going down the wrong path very efficiently.

This is the part that doesn’t get said enough: AI is a speed multiplier, but only on top of existing knowledge. It doesn’t replace understanding the problem. It doesn’t replace knowing your options. It doesn’t replace the judgment that comes from years of doing the work.

What it actually changed for me

I’ll give you a concrete example. I recently built KI-Tax, a free tax estimator for self-employed Canadians. It started as an Excel sheet, which is honestly where a lot of my projects start. I knew Python, I knew Streamlit, I knew enough HTML and CSS to build a decent UI. What AI helped me do was glue those things together faster, catch errors in logic I might have missed, and move from a rough December prototype to a properly built tool covering all 13 Canadian provinces in a fraction of the time it would have taken me before.

But here’s the thing, the hardest part of that project had nothing to do with code. It was verifying the tax logic. Canadian tax rules are genuinely complicated, and I used both Claude and Gemini to cross-check calculations, then verified everything against official CRA and Revenu Québec sources anyway. Because AI got things wrong, sometimes confidently wrong. Knowing enough about the subject to catch those errors was the difference between a tool that works and one that gives people bad numbers about their taxes. That’s not a small distinction.

I’m currently working on an RFM analysis project, customer segmentation work that I’ve done variations of many times over the years. Before, I’d have a working prototype or an MVP with a rough interface. Now I’m building a proper UI for it, something that actually looks like a finished product rather than an analyst’s internal tool. AI is helping me get there. But the analysis itself, the decisions about how to structure it, what to surface, what matters, that’s still coming from a decade-plus of seeing how these models actually perform in production.

What I’d actually say to someone earlier in their career

Learn the fundamentals first. Seriously. Not because AI won’t help you, of course it will, but because without that foundation, you have no way of knowing when it’s actually helping or just leading you into a hallucination. The people getting the most out of these tools are the ones who could have solved the problem without them; it just would have taken longer. AI didn’t make me a better data scientist. It made a competent data scientist faster. That’s a massive shift, but we should be honest about which one it actually is.

Leave a comment

Subscribe now

Subscribe now

So back in December I built a first version of the tool in Streamlit, nothing fancy, just enough to answer my own questions. But the more I used it, the more gaps I noticed. It only covered Quebec, the QPP calculation wasn’t fully right, and it didn’t really explain anything, it just produced a number. So I kept working on it. I added all 13 provinces and territories, got the tax calculations properly verified, built out the expense tracker, added the charts, and made sure the breakdown was clear enough that someone with no tax background could actually follow it. A few months later, here we are. I’m sharing it now because if I was this confused sorting out my own taxes, I figure other people probably are too, and I’d rather put something useful out there than keep it to myself.

Here’s how it works

You start by selecting your province and entering your gross income, the total amount your clients paid you this year, before anything is taken out. That’s it to get your first estimate. Everything updates instantly as you type, so you can play with numbers and see the impact in real time.

From there, you can track your business expenses. This is where things get interesting for a lot of self-employed people, your expenses directly reduce the income you’re taxed on, so keeping track of them matters. The tool uses the same expense categories as the CRA’s T2125 form, which is the form self-employed people file at tax time. Things like advertising, professional fees, home office costs, travel, software subscriptions, you add them in, and the tool adjusts your estimate accordingly. Meals and entertainment are automatically handled at the CRA’s 50% deductible rule so you don’t have to think about it.

Once you’ve entered your income and expenses, the tool shows you a full summary: your net business income, your taxable income after deductions, your federal tax, your provincial tax, your CPP/QPP contribution, your total tax bill, and what you actually take home. Each number is explained so you can understand what it represents and why it’s there, not just a black box spitting out a result.

There’s also a visual section with two charts. The first is a simple donut chart showing what percentage of your income goes where, federal tax, provincial tax, CPP/QPP, and take-home pay. The second is a flow diagram that traces every dollar from your gross income through expenses, contributions, and taxes all the way to your pocket. If you’ve ever wondered “where did my money go,” that diagram answers it pretty clearly.

One thing I found really useful personally is the quarterly installment planner. As a self-employed person in Canada, if your income tax owing exceeds $3,000, or $1,800 if you’re in Quebec, you’re required to make quarterly payments to the CRA (or Revenu Québec) throughout the year rather than paying everything in April. The tool checks your estimate against the threshold for your province and tells you whether you need to be making payments, how much per quarter, and when the due dates are. It sounds obvious but it genuinely surprised me the first time I realized I should have been doing this. Quebec was actually one of the trickier provinces to get right in general, between the QPP instead of CPP, the federal tax abatement, and Revenu Québec’s own thresholds and rules, there are more moving parts than most other provinces. But everything is handled automatically regardless of where you are, whether you’re in Ontario, BC, Alberta, Quebec, or anywhere else in the country, the tool picks up the right rates, thresholds, and rules for your province the moment you select it.

Finally, you can export all your tracked expenses as a CSV file and reload them next time. It’s not accounting software, it doesn’t save automatically, but it means you don’t have to start from scratch every time you open it.

One last thing worth mentioning, the tool doesn’t collect or store any data whatsoever. No account, no tracking, no analytics on what you enter. Your income and expenses stay in your browser and disappear when you close the tab. I think that’s the right way to build something like this, especially when people are entering sensitive financial information. What you type is yours.

If you’d like to try it, just drop your email at the link below and I’ll send you the access link right away. No spam, no waitlist, just the tool.

Try it here.

You can also find the user manual here.

PS: Please use it on your desktop.

And if you do try it, I’d genuinely love to hear what you think. What’s useful, what’s confusing, what’s missing, drop a comment below or reply to this post. This is very much a work in progress and honest feedback is the most useful thing you can send my way.

Leave a comment

Subscribe now

Important Disclaimer: This tool provides estimates only based on publicly available 2025 Canadian federal and provincial tax data. It does not account for all tax situations (e.g. RRSP deductions, disability credits, provincial surtaxes, investment income, capital gains, etc.). Always consult a licensed Chartered Professional Accountant (CPA) for accurate, personalized tax advice. Use at your own risk. The CRA and Revenu Québec are the authoritative sources for all tax obligations.

In a recent study published by Harvard Business Review (March 2026), researchers Julie Bedard, Matthew Kropp, and their colleagues identified a new type of exhaustion they call “AI Brain Fry.”

Subscribe now

What exactly is “Brain Fry”?

The researchers define it as mental fatigue resulting from excessive use or oversight of AI tools beyond a person’s cognitive capacity. Unlike general burnout, which is often emotional, this is an acute cognitive strain. Key findings from the study include:

• The Oversight Tax: The most taxing part of AI work isn’t the creation but it’s the monitoring. High degrees of AI oversight led to 12% more mental fatigue and 19% greater information overload.

• The Three-Tool Limit: While using two AI tools can boost productivity, the study found that productivity scores actually dipped once a user tried to manage more than three tools simultaneously.

• The Business Cost: This “fry” leads to a 33% increase in decision fatigue and a significantly higher frequency of self-reported major errors.

The Silver Lining: Less Toil, Less Burnout

The study also found that when AI is used specifically to replace routine or repetitive tasks (what the authors call “toil”), burnout scores actually dropped by 15%. Participants in this group reported higher work engagement and more time for social connection with peers.

Three Lessons for Professionals

To avoid the cognitive “fry” while still reaping the benefits of AI, the study suggests a few critical shifts in how we work:

1. Set Agent Limits: The data suggests adverse productivity gains after the use of three AI agents at the same time. Don’t juggle more than your brain can reasonably comprehend.

2. Focus on Impact, Not Intensity: Incentivizing the quantity of AI use leads to waste and mental strain. Start with clear business objectives rather than just “rewarding token consumption.”

3. Develop Management Skills: Advanced AI users often feel blocked unless they develop new skills like problem framing and strategic prioritization. Working harder to manage the tools is not the same as solving the problem.

The Responsibility of the Organization

Perhaps the most critical takeaway from the study is that “AI Brain Fry” is not an individual failure; it is an organizational risk that leadership must manage. The researchers found a measurable “AI orphan tax” where mental fatigue spikes when managers expect employees to figure out these complex tools on their own. To prevent a crisis of cognitive overload, companies must move away from using AI as a tool for work intensification. True success requires leadership to set explicit guardrails, provide clear strategy and training, and prioritize “cognitive thriving” over raw token consumption. It is up to organizations to ensure that AI is used to subtract the drudgery of work, rather than simply adding a new, exhausting layer of digital oversight to an already full plate.

AI is an amplifier. It can amplify your creativity, or it can amplify your exhaustion. The goal for 2026 isn’t just to use more AI, it’s to use it in a way that leaves us with more energy at 5pm, not less.

How are you feeling lately? Are you hitting that “AI sweet spot,” or is the “mental static” starting to creep in? Let’s chat in the comments!

For the full deep dive into the data, check out the original article by Bedard et al. in Harvard Business Review.

Leave a comment

This isn’t a hot take. It’s where the data keeps landing, year after year. And in 2025, with AI spending hitting record highs and boardroom pressure mounting, the gap between investment and measurable returns has become one of the most urgent conversations in business. Spending is up but confidence in measuring the outcome is not. So what’s actually going on?

The Formula Isn’t the Problem

ROI, at its core, is simple math: take what you gained, subtract what you spent, divide by what you spent, multiply by 100. The formula works great for capital equipment, ad campaigns, and new hires. It falls apart for AI. The problem isn’t the formula. It’s the inputs.

AI can definitely make work faster but faster doesn’t mean ROI.

When you implement AI in, say, a customer service workflow, some things are measurable: ticket resolution time, cost per interaction, headcount saved. But what about the quality of decisions your team makes because they’re less burnt out? The institutional knowledge that didn’t walk out the door because turnover dropped? The competitive deal you won because your sales team had better intelligence? These aren’t hypothetical benefits. They’re real and they’re nearly impossible to attribute cleanly to a single AI tool.

The Attribution Trap

Even when you do see measurable improvements, attribution is a minefield. Say productivity goes up 20% after deploying an AI writing tool. Was that the AI? Or did you also restructure the team, hire a great manager, and streamline your approval process at the same time? Most organizations are running multiple initiatives in parallel, which means clean causation is rare.

There’s also the baseline problem: you can’t measure improvement if you didn’t carefully document where you started. According to IBM, most companies skip baselining the pre-AI process entirely and then regret it when they try to make the case to their CFO six months later.

The Four Reasons AI ROI Is Hard to Measure

• Soft benefits (morale, decision quality, talent retention) are real but can’t be cleanly quantified

• Attribution is nearly impossible when multiple initiatives are running simultaneously

• Most companies skip baselining before deployment, leaving no “before” to compare against

• AI’s value often compounds over time, the payback period is 2–4 years vs. the typical 7–12 months for traditional software

The Data Quality Problem Nobody Talks About Enough

Here’s a stat that should make any AI buyer pause: 85% of business leaders cite data quality as their biggest challenge in AI strategy, according to KPMG. If your data is messy, your AI produces unreliable results. If your results are unreliable, your ROI measurement is built on sand. This is the hidden cost that rarely makes it into the pitch deck.

Hard ROI vs. Soft ROI and Why You Need Both

Financial analysts split AI returns into two buckets. Hard ROI is the stuff that shows up directly on the P&L: fewer support tickets, reduced infrastructure costs, faster turnaround times. These are measurable, defensible, and CFO-friendly.

Soft ROI is everything else: employee satisfaction, better decisions, improved customer experience, reduced burnout. Harder to quantify, but arguably more important for long-term organizational health. CIO Magazine suggests tracking “squishy ROI” employee sentiment, usage rates, self-reported productivity early on, because adoption and trust are what eventually unlock the hard numbers.

The trap is treating these as separate. The companies seeing the best returns are the ones connecting them: using soft signals to drive adoption, which drives usage, which generates the data and processes needed to measure hard impact.

What the Best Companies Do Differently

Gartner’s research on early AI adopters found that the organizations achieving real results, an average 15.8% revenue increase, 15.2% cost savings, and 22.6% productivity improvement, had one thing in common: they started with a specific, measurable business problem rather than a general AI aspiration.

The companies that struggle tend to do the opposite. As one IBM researcher put it: “Step one: we’re going to use LLMs. Step two: what should we use them for?” That’s a very expensive way to learn a lesson.

The practical playbook from organizations that do this well tends to look like: define the specific business problem first → baseline current performance obsessively → run a controlled pilot → measure against the baseline → only then scale. It’s boring but it works.

The Bottom Line

AI ROI isn’t uncalculable, but it is genuinely difficult, and anyone who tells you otherwise is probably selling you something. The math is simple. The inputs are unreliable, the timelines are longer than traditional technology, the attribution is messy, and the most meaningful benefits often resist neat quantification.

That doesn’t mean you shouldn’t invest. It means you should invest differently: with a clear problem in mind, a documented baseline, realistic timelines (think 2–4 years, not quarters), and a measurement framework that accounts for both hard and soft returns.

The companies pulling ahead aren’t the ones who spent the most on AI. They’re the ones who were honest about what they were measuring and why. The AI payback period is typically 2–4 years. Most companies are evaluating it on a 6-month horizon. That’s a mismatch worth talking about.

Leave a comment

Sources

1. Deloitte. (2025, October). AI ROI: The paradox of rising investment and elusive returns. https://www.deloitte.com/nl/en/issues/generative-ai/ai-roi-the-paradox-of-rising-investment-and-elusive-returns.html

2. IBM Think. (2025). How to maximize AI ROI in 2026. IBM. https://www.ibm.com/think/insights/ai-roi

3. Fruhlinger, J. (2025, December 16). AI ROI: How to measure the true value of AI. CIO Magazine. https://www.cio.com/article/4106788/ai-roi-how-to-measure-the-true-value-of-ai-2.html

4. Steinert, J., Turner, N., & Kapoor, P. (2025, June 30). Closing the ROI gap when scaling AI. Guidehouse. https://guidehouse.com/insights/financial-services/2025/close-the-roi-gap-when-scaling-ai

5. Gartner. (2024, July 29). Gartner predicts 30% of generative AI projects will be abandoned after proof of concept by end of 2025. https://www.gartner.com/en/newsroom/press-releases/2024-07-29-gartner-predicts-30-percent-of-generative-ai-projects-will-be-abandoned-after-proof-of-concept-by-end-of-2025

6. KPMG. (2024). AI quarterly pulse survey: Q2 2024. KPMG LLP. https://kpmg.com/us/en/articles/2025/ai-quarterly-pulse-survey.html

Subscribe now

Through years of hands‑on work in data, I’ve seen that high‑performing teams are built on resilience, not tools. If your department is one resignation away from a total system collapse, you aren’t scaling, you’re just gambling.

What Knowledge Debt Actually Looks Like

It’s the silent friction that makes everything take twice as long as it should:

• The “Archeology” Onboarding: A new hire spends their first three weeks just trying to find the right table definitions because the documentation hasn’t been updated since 2022.

• The Hero Dependency: There is a specific “hero” on the team who is constantly interrupted during their deep-work time because they are the only person who knows how a core system works.

• The “Black Box” Logic: You have a critical pricing or churn model that everyone uses, but nobody actually knows how the features are calculated. “It just works, don’t touch it.”

• The Duplicate Effort: Two different teams spend a month building the exact same data asset because neither knew the other existed.

Why We Get Stuck Here

Knowledge debt is a byproduct of speed. When the business is screaming for a result, documenting the process feels like an indulgence we can’t afford. We tell ourselves we’ll “write it up later,” but in the data world, “later” is where good intentions go to die.

The Path to “Green”: Lowering Your “Bus Factor”

You don’t need to spend a month writing a 200-page wiki. You just need to build a culture where knowledge is treated as a shared asset rather than a personal secret. Here are three ways to start:

1. The “Two-Person” Rule

This is the simplest way to lower your “Bus Factor” (the number of people who would have to get hit by a bus for your project to stall).

• The Solution: For every critical system or pipeline, ensure at least two people have actually “touched” the code. This isn’t just about reading documentation; it’s about cross-training. Have them swap tasks for a week. If the second person can’t run the system without calling the first, you’ve identified a debt gap.

2. Documentation as “Code Review”

Documentation shouldn’t be a separate task you do at the end of a project; it should be a requirement for finishing it.

• The Solution: Make basic documentation a mandatory part of your Peer Review or Pull Request process. If the code isn’t commented and the README isn’t updated, the PR doesn’t get merged. It’s much easier to write three sentences today than a 10-page manual six months from now.

3. Capture “The Why,” Not Just “The What”

Most documentation fails because it explains what the code does (which the code itself already says) but ignores why it was done that way.

• The Solution: Focus on “Decision Logs.” When a team member makes a major architectural choice, have them spend 5 minutes recording the reasoning. Knowing why you chose one database over another is much more valuable to a future team member than a list of table names.

The Bottom Line

Knowledge Debt is the “interest” you pay in the form of anxiety and wasted time. Getting to “Green” doesn’t mean you have a perfect library of documents, it means you have a team that is interchangeable and resilient. It’s the peace of mind that comes from knowing that if your top contributor takes a three-week vacation, the business won’t stop moving.

Is there a “Hero” on your team who has become a bottleneck for everyone else? That’s your biggest risk factor. Let’s talk about how to start the knowledge transfer in the comments.

Leave a comment

In my 13 years in this field, I’ve seen that Model Debt is the hardest to track because it’s invisible. You don’t get a “404 Not Found” error when a model starts underperforming. You just get a slow, silent erosion of business value.

What Model Debt Actually Feels Like

It’s not just “bad accuracy”; it’s the operational weight of a black box:

• The “User-as-Monitor”: Your first sign that a model is failing is an angry email from a stakeholder saying the recommendations “look weird today.”

• The Pipeline Jungle: To get the model to work, you have a series of “temporary” scripts and manual data exports that have somehow become permanent parts of the production flow.

• The Hidden Feedback Loop: Your model is predicting user behavior, but its predictions are actually changing that behavior, creating a “death spiral” of data that no one is auditing.

• The Fear of Retraining: The original creator of the model left the company, and now the team is afraid to retrain it because “we’re not sure exactly which features were used in the final version.”

Why We Get Stuck Here

We get stuck because we celebrate the “Launch” but ignore the “Life.” In most organizations, the glory is in the deployment. But in ML, deployment is only the first 10% of the work. The other 90% is the lifecycle management, and that’s where the debt accumulates.

The Path to “Green”: Turning Off the Zombies

Getting to a “Green” score in Model Debt doesn’t require a $100k MLOps platform. It requires standardized guardrails. Here are three practical ways to start:

1. Build a “Circuit Breaker”

In electrical engineering, a circuit breaker stops the flow of power when something is wrong. Your models need the same thing.

• The Solution: Set up a simple “sanity check” script. If the distribution of your model’s predictions shifts by more than 20% in a day, the system sends an alert. It’s better to show a “default” result than a confidently wrong prediction.

2. Kill the Manual Retrain

If retraining your model requires a Data Scientist to spend two days manually running notebooks, you have a high-interest debt problem.

• The Solution: Don’t worry about “Auto-ML” yet. Just focus on reproducibility. Can a junior scientist run a single script and get the same model you have in production? If the answer is “no,” your first priority is version-controlling your training data and parameters.

3. Define the “Sunset” Date

Every model has an expiration date.

• The Solution: When you launch a model, decide then and there when it will be re-evaluated. If it’s not meeting its KPIs or if it hasn’t been updated in six months, it gets turned off or replaced. This prevents “Zombie Models” from haunting your infrastructure for years.

The Bottom Line

Model Debt isn’t about being “bad at math.” It’s about the gap between the code we wrote and the reality of the data today. Getting to “Green” means you’ve moved from reactive monitoring (waiting for things to break) to proactive evaluation. You want a system where you can sleep soundly because you know that if a model starts failing, the system will tell you before the users do.

Is there a model running in your production environment right now that nobody has checked on in months? That’s your highest interest debt. Let’s talk about how to audit those “Zombies” in the comments.

Subscribe now

In my 13 years in this field, I’ve found that data debt is the most expensive kind to carry. Unlike infrastructure debt, which slows down your engineers, data debt slows down the entire company. It destroys trust. And once trust is gone, people start building “shadow dashboards”, their own private versions of the truth, which only makes the problem worse.

What Data Debt Actually Feels Like

It’s rarely about “missing data.” It’s about the friction caused by a lack of shared rules:

• The “Shadow” Dashboard: A VP doesn’t trust the official company dashboard, so they have an analyst manually export data to a “private” Excel sheet every Monday.

• The Broken Pipeline: A software engineer renames a column in the production database to “clean things up,” and three downstream dashboards instantly go dark because there was no “contract” between the producer and the consumer.

• The Metric War: Two teams are looking at the same KPI, but one is using “Gross” and the other is using “Net,” yet both labels just say “Revenue.”

• The “Data Archeologist”: You have one person on the team who is the only one who knows which tables are “real” and which ones are “legacy trash from 2021.”

Why We Get Stuck Here

Data debt usually happens because of silos. We build for the immediate need of one department without thinking about how that data will be used by the rest of the organization. We prioritize “getting the data out” over “getting the data right.”

The Path to "Green": Building a Culture of Trust

You don’t solve data debt by “cleaning” the data, that’s just treating the symptom. You solve it by fixing the governance. Here are three ways to move toward a Green score without a year-long overhaul:

1. Standardize the “Core Five”

You don’t need to define every single metric in the company on day one.

The Solution: Identify the five most important metrics that everyone uses (e.g., Active Users, Revenue, Churn). Get the stakeholders in a room, agree on a single definition, and document it in one place. If it’s not in the “Source of Truth,” it doesn’t exist.

2. Introduce “Data Contracts” (The Handshake)

Data debt often happens because the people producing data (software engineers) don’t know who is consuming it (data scientists).

• The Solution: Start a simple “handshake” process. Before a source table changes, the producers must notify the consumers. This shifts the mindset from “I’m just changing a database” to “I am delivering a product.” It turns federated data into a consistent, reliable service.

3. Kill the “Zombie” Reports

Shadow dashboards thrive in the dark.

• The Solution: Run an audit of your BI tool. If a report hasn’t been viewed in 60 days, archive it. If someone complains, you’ve found a hidden dependency. If nobody notices, you’ve just reduced your “surface area” for errors. Reducing the number of reports makes it much easier to ensure the remaining ones are accurate.

The Bottom Line

Data governance sounds like a boring corporate buzzword, but in reality, it’s just etiquette for data. It’s the agreement that we won’t break each other’s work and that we’ll use the same language to describe our success. Getting to “Green” doesn’t mean your data is perfect. It means that when someone asks, “Where did this number come from?” you have a clear, documented answer that everyone trusts.

Is your team spending more time “cleaning” data than actually analyzing it? That’s the classic sign of a trust deficit. Let’s talk about how to fix the “handshake” in the comments.

Leave a comment

Subscribe now

What Infrastructure Debt Actually Looks Like:

It’s never a single catastrophic failure; it’s a thousand tiny papercuts:

• The “Local Machine” Trap: A critical model only runs on one person’s laptop because the production environment is missing “certain libraries” no one can identify.

• The Weekend Pipeline: A data load fails every Saturday morning. Instead of fixing the root cause, the team has a rotating “weekend shift” just to hit the restart button.

• The Ghost in the Machine: You change a variable in Staging, it works perfectly, you move it to Production, and everything breaks. Why? Because six months ago, someone manually changed a setting in the Prod console and never told anyone.

• The “Surprise” Cloud Bill: You realize you’ve been paying $2,000 a month for a GPU instance that was spun up for a “quick test” in 2023 and forgotten.

Why do we fall into this? We do it because we are under pressure. We tell ourselves: “I’ll just fix this manually today so we can hit the deadline, and I’ll automate it properly next week.” But “next week” never comes. Eventually, the team spends 60% of their time just “keeping the lights on,” leaving only 40% for actual innovation.

Three Ways to Start “Getting to Green”

You don’t need to be a DevOps engineer to fix this. You just need to be disciplined about where you spend your team’s energy.

1. Target the “Manual Restart”

Find the one thing your team has to “check on” every day. Is it a server that runs out of memory? A pipeline that needs a manual kick-start?

• The Solution: Don’t rebuild the whole architecture. Just add a simple automated “health check” or a script that cleans up the memory. If you save 20 minutes a day, you’ve just bought your team two hours of deep work a week.

2. Declare “Console Freeze”

One of the biggest sources of debt is “Click-Ops”, manually clicking buttons in the AWS or Azure console. It’s fast in the moment, but it’s invisible to the rest of the team.

• The Solution: Start a “Source of Truth” document (or a repo). If a setting is changed in the cloud, it must be updated in the doc first. This moves you toward “Infrastructure as Code” without needing to learn complex new tools overnight.

3. Set “Budget Guardrails”

Infrastructure debt often manifests as financial waste.

• The Solution: Instead of complex cost-optimization, just set up automated alerts. If a specific project’s cost spikes by 20% in a single day, the lead gets an email. Visibility alone usually changes team behavior overnight, people start cleaning up their “zombie” instances when they know the bill is being watched.

The Bottom Line

Infrastructure shouldn’t be a “hobby” your team does on the side. It is the foundation of your velocity. Getting to “Green” doesn’t mean your cloud is perfect; it means your cloud is boring. You want an infrastructure that is so stable and automated that you actually forget it’s there.

Does your team have a “Hero” who is the only one who knows how to fix the servers? That’s a major debt signal. Let’s talk about how to break that cycle in the comments.

Leave a comment

However, as a Lead or Senior Scientist, you don’t always have time to re-read academic papers. You need a way to look at your department today and know where the rot is. I have synthesized these practical leadership heuristics into a 10-minute diagnostic tool designed specifically for data leadership.

Subscribe now

This isn’t just about code; it’s about the four systemic pillars that determine whether your team can scale or if you’re one resignation away from a total system collapse.

The Audit: A Practical Synthesis

Note: This framework adapts Fowler’s quadrants and Google’s ML debt categories into four “Data Strategy” buckets.

1. Infrastructure Debt (The Operational Lens)

The Concept: Influenced by Google’s Site Reliability Engineering principles.

The Question: How much manual “toil” is required to maintain your environments? Do you struggle with environment drift (staging vs. prod), unpredictable cloud costs, or gaps in system observability?

1 (Red): High manual overhead; environment configurations are inconsistent; costs are opaque.

2 (Yellow): Basic automation is in place, but system performance and costs require frequent manual troubleshooting.

3 (Green): Infrastructure is version-controlled; costs are optimized via automation; full observability into pipeline health is the baseline.

2. Data Debt (The Governance Lens)

The Concept: Derived from Zhamak Dehghani’s Data Mesh and the Data Contract movement.

The Question: How many “shadow dashboards” exist because users don’t trust the primary data products? Is there a clear framework for data quality, or do inconsistencies lead to constant cross-team debates?

1 (Red): Frequent debates over “whose numbers are right”; no shared definitions for key metrics across domains.

2 (Yellow): Domain-specific data assets exist, but lack a unified governance layer to ensure consistency.

3 (Green): Clear data contracts in place; federated governance ensures consistent metrics across the organization regardless of which team owns the data.

3. Model Debt (The ML Lifecycle Lens)

The Concept: Directly applying the Google “Hidden Technical Debt” research.

The Question: What percentage of production models lack automated drift detection or a scheduled retraining trigger?

1 (Red): “Zombie models” exist; monitoring is reactive (we wait for the user to complain).

2 (Yellow): Standard monitoring is in place, but retraining is manual and ad-hoc.

3 (Green): Robust MLOps; automated circuit-breakers for model performance.

4. Knowledge Debt (The “Bus Factor” Lens)

The Concept: A standard software engineering metric for team resilience.

The Question: If your top two contributors left tomorrow, could the remaining team maintain the systems without a “black box” failure?

1 (Red): Critical systems are undocumented; knowledge is siloed in 1-2 heads.

2 (Yellow): Documentation exists but is 6+ months out of date.

3 (Green): Culture of documentation and cross-training; low “bus factor.”

The Debt-Action Matrix: Your Strategic Playbook

Based on your scores above, here is how I recommend prioritizing your next quarter:

Why Curation is Leadership

The goal of this audit isn’t to achieve a perfect 12/12. As Martin Fowler famously noted, “Deliberate Debt” can be a tool for speed. The danger is “Inadvertent Debt”, the mess that happens when you aren’t looking . By running this audit, you’re moving from accidentally messy to strategically managed. What’s the “highest interest” debt your team is paying right now? Let’s discuss in the comments.

Leave a comment

Further Reading & Industry Influences

If you want to dive deeper into the theories that shaped this audit, I highly recommend these foundational resources:

• The Technical Debt Quadrant (Martin Fowler): The original 2009 framework that categorized debt into Deliberate vs. Inadvertent and Prudent vs. Reckless.

• Hidden Technical Debt in Machine Learning Systems (Google Research): The “must-read” paper for any data leader. It explains why ML systems have a unique way of “eroding boundaries” and creating high-interest debt

• The 4 Core Principles of Data Mesh (Zhamak Dehghani): The origin of the “Data as a Product” mindset, which is the best defense against “Data Debt.”

• Eliminating Toil (Google SRE Book): The definitive guide to identifying “Infrastructure Debt” and why manual, repetitive tasks (Toil) are the enemy of scaling.

With experience comes optionality. You know multiple stacks. You understand tradeoffs. You’re aware of long-term maintenance costs, scalability concerns, vendor lock-in, UX debt, and monetization risks. All of that knowledge is real and earned. The downside is that every new idea immediately explodes into ten possible implementations.

• Web app or script?

• Custom front end or no-code?

• Self-hosted or platform-based?

• Build once or design for extensibility?

At a junior level, these questions don’t exist. At a senior level, they exist all at once. The result is a peculiar kind of stagnation: lots of planning, lots of evaluation, occasional prototypes, but nothing crossing the line into a paid, real-world product.

I had a working Python tool that I created some time ago. It wasn’t theoretical. It ran. It produced outputs. It solved a real problem. Yet it lived in a kind of limbo. I explored multiple directions: different hosting options, potential rewrites, broader product ideas, future extensions. Each option was reasonable in isolation. Collectively, they kept reopening the decision space. Nothing was “wrong,” so nothing felt urgent. The problem wasn’t technical debt or missing features. The problem was that every new option reset commitment.

The turning point came from recognizing a simple but under-discussed distinction: some tools feel finite, others feel infinite. Files(spreadsheets, scripts, static dashboards) have edges. You finish them. You ship them. They resist scope creep by their nature. Web apps feel infinite. There’s always another page, another flow, another edge case. That infinity is intoxicating, especially for experienced builders. It also delays shipping. This doesn’t mean web apps are bad. It means they require discipline that most people underestimate, particularly when building solo.

The mistake I was making was treating every move as a reinvention. Instead of asking “How do I build the best possible version of this?”, the better question was: “How do I move this existing thing closer to being selleble, with the least new surface area?”. That led to a simple rule set:

• Don’t rebuild working logic

• Don’t expand scope

• Don’t improve UX beyond parity

• Don’t mix learning goals with product goals

The decision was to keep the Python core exactly as it was and move only the front end to a more flexible UI layer. No new features. No architectural elegance. Just a better door.

No-code tools are often framed as either magic or malpractice. In reality, they’re neither. They’re just tools with failure modes. The key constraint that made this viable was separation of concerns:

• All business logic stays in Python

• The UI layer only collects inputs and displays outputs

• The backend is exposed as a simple API

• No logic duplication

Under these constraints, a no-code front end becomes a wrapper, not a platform dependency. It accelerates UI and payments without contaminating the core. This distinction matters if you care about long-term optionality.

Another hard-earned lesson: “free” is not a harmless default. A free version without a clear boundary becomes a comfortable stall. It delays the moment where the product has to justify itself. If there’s a free tier, it needs a visible ceiling:

• limited runs

• reduced output

• preview-only results

Not as a dark pattern, but as an honest signal: this tool has value, and that value isn’t infinite. Nothing dramatic happened overnight. There was no breakthrough insight about markets or technology. What changed was commitment. By freezing scope, accepting imperfection, and treating learning as a side effect of shipping rather than the goal, the product finally crossed from “interesting” to “real.” That shift, from exploration to execution, is uncomfortable for senior people precisely because they can see all the ways it could be better. The discipline is choosing not to pursue them yet.

The broader lesson is that experience rarely fails by making people incapable. It fails by making everything feel provisional. When you’ve seen enough systems, tools, and tradeoffs, it becomes easy to keep decisions open “just in case,” even when closing them would unlock progress.

For experienced technical professionals trying to build products, the real tension is often between correctness and completion. It shows up in the habit of reopening decisions that were already good enough, or in treating learning as a prerequisite when, in reality, it quietly postpones commitment.

Constraints aren’t a loss of freedom. They’re the mechanism that allows experienced people to ship. Sometimes the most senior move isn’t building something better or more elegant, but finishing something good enough and letting reality do the rest.

This migration is further accelerated by what many contributors describe as the "hostile culture" of Stack Overflow. For years, the platform has faced criticism for its rigid moderation and the often abrasive tone of senior "gatekeepers" toward newer users. While these strict standards once ensured high data quality, they have now become the platform's greatest liability. In the face of a frictionless, polite AI alternative, the social cost of participating in a hostile human forum has become too high for most. As the "human layer" of the platform erodes, the very social friction that once polished the site's data is now driving the community toward extinction.

This leads directly to the "knowledge plateau" paradox. While Stack Overflow’s historical archive remains the most valuable training set for coding AI, the cessation of new human content creates a terminal bottleneck for future intelligence. If the community stops producing public documentation of 2026-era technologies due to AI reliance and forum hostility, AI models will eventually run out of "ground truth" to learn from. We are entering a cycle where developers use AI to solve problems in private, which prevents those solutions from ever being indexed for the next generation of LLMs. Consequently, AI risks becoming a "static mirror" of the past, increasingly incapable of reasoning through the bugs and nuances of future software releases because the human-led "global brain" that fed it has gone silent.

Ultimately, the paradox suggests that by opting for the convenience and safety of AI today, we may be inadvertently starving the models of the tomorrow. The reasoning is clear: AI is a reflection of human collective intelligence, not a replacement for it. If the hostile culture and the lure of instant answers permanently kill the public "commons" of programming knowledge, the AI itself will eventually hit a ceiling, unable to advance alongside the very technology it is meant to help us build. This perspective is frequently countered by the claim that modern documentation is now so robust that community forums have outlived their usefulness. Yet, this sentiment overlooks the critical distinction between a manual and a troubleshoot. Official documentation provides the "happy path", the idealized way technology is designed to work in a vacuum, whereas Stack Overflow archives the "unhappy path" of version conflicts, deployment errors, and real-world failures. For those who "hate Stackoverflow" it is easy to ignore that these threads contain the "negative training data" that prevents AI from hallucinating. Without a continuous, public record of how 2026-era technologies actually break, AI models will eventually reach a knowledge plateau where they can quote documentation flawlessly but lack the learned intuition required to solve the messy, unscripted bugs that define professional engineering.

Sources / Further Reading

-Anderson, T. (2026, January 5). "Dramatic drop in Stack Overflow questions as devs look elsewhere for help." DevClass.

-Stack Overflow Data Team. (2025, December). "2025 Developer Survey: The State of AI and Community Trust." Stack Overflow Blog.

In September 2025, Salesforce became the poster child for the “AI will replace humans” narrative. CEO Marc Benioff casually confirmed that the company’s customer support organization had been reduced from roughly 9,000 people to about 5,000. The justification was straightforward: AI agents were already handling around half of all customer conversations, and according to Benioff, that simply meant he “needed less heads.” He framed the moment as a breakthrough, an overdue rebalancing enabled by generative AI and described the period as the most exciting phase of his career.

That confidence did not survive the year.

By December, Salesforce executives were publicly walking back earlier assumptions. Sanjna Parulekar, the company’s Senior Vice President of Product Marketing, admitted that leadership had been far more optimistic about large language models a year earlier. What changed wasn’t ideology, but exposure. As these systems were pushed into more complex, real-world workflows, their limitations became difficult to ignore. LLMs turned out to be inherently probabilistic, prone to drifting off task, skipping instructions, or behaving unpredictably once the problem space became even moderately complicated.

Salesforce’s own engineers confirmed the issue. CTO Muralidhar Krishnaprasad explained that once an AI agent receives more than a handful of explicit instructions, often as few as eight, it begins to fail silently, omitting steps or ignoring constraints. This wasn’t a theoretical concern. Customers like Vivint discovered that AI agents built on Salesforce tooling were failing to perform basic actions, such as sending customer satisfaction surveys, despite being clearly instructed to do so. Fixing these failures required the introduction of “deterministic” safeguards: rigid, rule-based triggers layered on top of the AI to ensure it actually did what it was supposed to do.

By the end of 2025, the company’s strategy had quietly shifted. The loud “AI-first” positioning gave way to something more restrained: a “data-first” approach focused on foundations, controls, and predictability rather than model intelligence. Benioff himself began emphasizing the need to reduce hallucinations and uncertainty by prioritizing structured data over autonomous reasoning. And while thousands of support roles had been cut earlier in the year, Salesforce spent the closing months of 2025 ramping up hiring on the sales side, acknowledging, somewhat sheepishly, that AI still lacks the human judgment, trust, and relational depth required for complex business interactions.

What this gap between expectations and reality makes clear is that AI didn’t fail, it was oversold, and then over-deployed. The expectation was replacement: fewer people, flatter teams, cleaner processes. The reality has been messier. Today’s models are powerful but fragile, impressive in demos and unreliable at the edges where real work lives. They accelerate some tasks while creating new ones: monitoring, correcting, scaffolding, and building guardrails around systems that cannot be trusted unattended. We’re no longer in the phase of asking whether AI works, but where it breaks, and how costly those failures are. That’s where caution becomes necessary, not as resistance to progress, but as an acknowledgment that probabilistic systems don’t behave like software, and pretending they do leads to brittle organizations and expensive reversals.

The Salesforce example brings the reality into sharp focus. The expectation was that AI would allow companies to do the same work with fewer people, cleanly and permanently. The reality has been closer to a reshuffle than a reduction. Headcount was cut where AI looked impressive on paper, then quietly rebuilt elsewhere once the limits became obvious. Automation handled the surface-level interactions, but humans were still needed to define boundaries, resolve ambiguity, repair failures, and carry relationships that models couldn’t sustain. What looked like efficiency at the executive level often translated into fragility on the ground. The lesson isn’t that AI has no place in tech organizations, it clearly does, but that treating it as a substitute for human judgment is a category error. Salesforce didn’t eliminate complexity; it displaced it, and then had to pay attention to where it landed.

Sources / Further Reading

– Slashdot (Sept 1, 2025): Coverage of Marc Benioff’s comments on reducing Salesforce support headcount following the rollout of AI agents.
– The Economic Times (Dec 23, 2025): Reporting on Salesforce executives acknowledging declining confidence in large language models and a shift toward more predictable automation.
– Salesforce Newsroom (Nov–Dec 2025): Official posts outlining Salesforce’s transition toward deterministic, data-first AI systems.

One of the comments mentioned that many STEM exams in Russian universities have traditionally been oral and extremely difficult. That resonated with me. Oral exams force you to expose your reasoning in real time, there’s no hiding behind polished output. You can’t just arrive at the right answer; you have to justify how you got there, respond to follow-up questions, and adapt when challenged. From a data science perspective, this is closer to how expertise actually shows up in practice. In real work, nobody hands you a perfectly phrased problem and gives you unlimited time to respond. You’re constantly asked to explain assumptions, defend trade-offs, and revise your thinking on the fly. Oral exams, when done well, measure understanding rather than pattern reproduction.

Another comment pointed out that this doesn’t mean students can’t use AI, it just means they still need to learn the material well enough to speak about it. I think that distinction is crucial. AI is already a learning tool, whether institutions like it or not. Trying to ban it entirely is like trying to ban calculators after they already exist. The more interesting question is how we design assessments so that AI use shifts from shortcut to scaffold. If a student uses AI to study, practice explanations, or test their understanding, and then has to demonstrate that understanding orally, that’s not a failure of education, that’s arguably a better alignment between tools and outcomes.

There was also a comment praising oral exams for valuing communication skills, which are undeniably important in the real world. As someone working in data science, I can say this is true but incomplete. Yes, being able to explain complex ideas clearly is a career advantage. But another comment rightly raised concerns about accessibility: oral exams can be a real barrier for people with speech impediments, neurodivergence, anxiety, or even just discomfort hearing their own voice. From a systems perspective, this matters. If an assessment method systematically disadvantages certain groups, then its signal is noisy. You’re no longer measuring “who understands the material,” you’re measuring “who performs best under a very specific social constraint.”

What I take away from all these comments is that oral exams aren’t inherently good or bad, they’re a tool. And like any tool, their value depends on how and why they’re used. AI didn’t break education; it exposed how much of our testing was optimized for recall rather than reasoning. The real question isn’t “how do we stop students from using AI?” but “are our pedagogy and evaluation methods keeping up with the world students are entering?” From a data scientist’s lens, if your metric is easy to game, you don’t blame the player, you redesign the metric.

This week’s escalation

OpenAI launched GPT‑5.2, positioning it as its strongest model for professional, multi‑step work, with notable gains in coding, long‑context handling, image perception, and complex project execution. OpenAI highlighted benchmark wins (e.g., perfect AIME 2025 performance for the “Thinking” tier versus GPT‑5.1’s 94), underscoring a push toward more dependable reasoning without external tools.

On the same day, Google unveiled an upgraded Gemini Deep Research agent powered by Gemini 3 Pro, designed to synthesize large information sets, produce research reports, and embed a research‑grade agent across Google products like Search, Finance, NotebookLM, and the Gemini app, signaling a strategy to fuse AI directly into the information stack users already touch daily.

These moves followed weeks of mounting pressure: reporting described OpenAI declaring a “code red” internally in response to Google’s Gemini 3 surge, a clear sign of how seriously both companies are treating this moment.

Where the models are diverging

• Reasoning and complex tasks: OpenAI is promoting GPT‑5.2’s gains in long‑context understanding, math, and multi‑step workflows, framing it as better suited for professional use and tool‑assisted projects. Benchmarks and capability claims emphasize stronger structured problem‑solving.

• Embedded research agent: Google’s Gemini Deep Research leans into synthesis at scale, managing large context dumps, due diligence, and domain‑specific research (e.g., drug toxicity), and is being woven into core Google surfaces, reducing friction between “search” and “analysis” for everyday users.

• Platform strategy: OpenAI focuses on model tiers (Instant, Thinking, Pro) and professional utility; Google focuses on pervasive integration across its product ecosystem. The former bets on better “brains,” the latter on better “placement” in users’ workflows.

Industry coverage this week has described the dynamic as a genuine face‑off, with both sides explicitly timing releases and messaging to compete head‑to‑head on reasoning, coding, and research‑grade use cases.

Practical impacts for users

• Faster, more capable assistants: Expect better spreadsheet generation, presentations, code scaffolding, and long‑context comprehension in chat interfaces, reducing the need for manual stitching of tools. These are specifically cited as improvements in GPT‑5.2’s capabilities.

• Research built into search: Gemini Deep Research’s embedding into Google products could turn “search” into “synthesized answers + sources,” cutting the time from query to usable summary or due diligence brief.

• Lower friction in daily workflows: If your work lives in Google’s ecosystem (Docs, Drive, Search), Gemini’s integrations may feel more natural. If you rely on structured task execution (coding, multi‑step prompts, long project threads), GPT‑5.2’s tiers and reasoning focus may fit better.

• Benchmark‑driven trust but keep perspective: OpenAI’s benchmark wins convey progress, but real‑world reliability depends on context, guardrails, and product integrations. Google’s approach may prioritize consistency within its ecosystem over benchmark headlines.

Risks and trade‑offs

• Rapid changes, uneven reliability: With both companies iterating quickly, users may see capability spikes alongside shifting behaviors, UI changes, and evolving limits. Coverage this week characterized the pace as an intensified “arms race,” which often brings volatility alongside innovation.

• Ecosystem lock‑in: Deeper integration means convenience, but switching costs rise. Gemini’s embedding across Google products and OpenAI’s tiered model access could nudge users into vendor‑specific workflows.

• Opaque differences behind similar claims: Both sides claim superior reasoning and coding; the real distinction often shows up in edge cases, long‑context stability, factual precision under heavy synthesis, and tool orchestration quality.

How to choose right now

• If you live in Google’s stack: You’ll likely benefit from Gemini Deep Research’s native synthesis in Search, NotebookLM, and Finance, especially for research, briefs, and context‑heavy reviews.

• If you need structured execution: GPT‑5.2’s reported improvements in long‑context, math, coding, and multi‑step projects, plus its “Thinking” tier’s benchmark gains, make it strong for complex, repeatable workflows.

• Test with your own tasks: Run the same multi‑step prompt or research question on both. Compare context retention, citation quality, and how well each integrates with your daily tools. The week’s news suggests both are improving, but your workflow will expose the practical winner.

This week’s duel (OpenAI’s GPT‑5.2 vs Google’s Gemini Deep Research( brings tangible gains: stronger reasoning and coding from OpenAI, and more embedded, research‑grade synthesis from Google. For users, the real benefit is choice: pick the assistant that best fits your workflow, not just the strongest headline benchmark.