DEV Community: Liviu Tudor

AI Efficiency or Just Plain Cost Cutting?

Liviu Tudor — Thu, 29 Oct 2026 14:35:13 +0000

Another week, another round of job cuts with AI in the press release. On Thursday Barclays said it would cut around 5,000 roles (about 5% of its staff) as part of a push for AI-driven efficiency, with roughly 60% of the cuts in support functions, developers included (CNBC has the story). This in the same quarter its pre-tax profit went up 12%. Earlier in the month HubSpot announced it was cutting nearly 660 jobs (about 7%) as it reorganises around AI, while its CEO wrote that the cuts are “not driven by AI-related efficiencies”. And eBay announced a 9% reduction this week without mentioning AI at all.

So depending on who you ask, AI is the reason, isn’t the reason, or isn’t worth a mention. Go figure. LinkedIn this week seemed split right down the middle in between “this is the future, adapt or die” and “AI is just the excuse for cost cutting”. I think both camps are missing the more useful question, which is the one I’d ask if I were the CTO in those rooms: show me the numbers.

Efficiency You’ve Measured, or Efficiency You’ve Been Promised?

Here’s the thing: there’s a big difference between “we’ve measured that AI does this work, so we need fewer people” and “we expect AI to do this work, so we’ll cut the people first”. The first one is a normal (if painful) business decision, the same as automating a factory line. The second one is a bet, and the people who lose their jobs are the stake.

And the evidence on the second one is a lot shakier than the press releases make it sound. Engineering leaders in surveys report big productivity gains from AI, but when you look at what actually ships, the picture gets murkier. LinearB’s 2026 benchmarks, for example, found that pull requests written by autonomous agents waited 17.6 hours to be picked up for review, against 3.4 hours for unassisted work, and got merged less often. In other words, the code got faster to write and the bottleneck moved to the people reviewing and releasing it. Cut those people and, quite likely, you’ve made the bottleneck worse, not better.

Now you can argue that a bank cutting support functions isn’t the same as cutting a product engineering team, and that’s fair. A lot of support work is repetitive, and some of it really is a good fit for automation. But “developers” being on that list is what caught my eye, because I keep seeing what happens when you take people out of a system before the replacement is proven: the work doesn’t disappear, it lands on whoever is left, and the knowledge of why things are the way they are walks out with the people who leave.

The Bit Nobody Puts in the Press Release

Anyone who has led an engineering team through a reduction knows the cut itself is only half the story; the other half is what happens to the team afterwards. Every reduction sends a message to the people who stay, and right now the message a lot of engineers are hearing is “the better you get at using AI, the sooner we’ll replace you”. That’s a terrible incentive! The people you most need to figure out how AI fits into your engineering process are the ones who now have every reason to keep their productivity gains to themselves.

The other cost is the one that shows up in 3 to 5 years. Cuts made in the name of AI tend to aim at junior and support roles (60% of Barclays’ are in support functions), because that’s where AI looks most capable on paper. But that’s also where your future senior engineers come from. If nobody hires juniors because “the AI does that now”, then in a few years there won’t be anyone around who learnt the system well enough to supervise the AI. I’d argue that’s the biggest risk in all of this, and it’s one no quarterly report will flag.

What I’d Ask

If I were sitting on the leadership side of one of these decisions, these are the questions I’d want answered before anyone signed off:

Which specific work is AI doing today, measured in production, not in a pilot or a vendor deck?
Where does that work go next? Who reviews it, who’s on call for it, who fixes it when it’s wrong?
What happens to the team’s workload and knowledge if the AI turns out to be 30% less capable than planned?
What are we telling the people who stay about how AI gains will be shared, and is it true?
How does our junior pipeline look in 3 years?

Don’t get me wrong, I’m not saying companies should never reduce headcount because of AI. If the efficiency is real and measured, it would be odd not to act on it, and pretending otherwise isn’t doing anyone any favours. But measured comes first and the cuts come second, not the other way around.

Bottom line: AI can be a very good reason to change how a team works. It’s a lousy excuse for not knowing how your team works in the first place.

Originally published on liviutudor.com.

Could You Switch AI Providers by Friday?

Liviu Tudor — Wed, 28 Oct 2026 15:09:25 +0000

If you missed it, Replit made OpenAI the default model provider for Replit Agent instead of Anthropic (Amjad Masad announced it at TechCrunch Disrupt on 16 October), and The Information then reported that most of Replit’s AI spend, a contract said to be worth more than $100M a year, moved over after OpenAI offered a discount of more than 30%. Replit hasn’t confirmed the terms, and Claude is still there if you pick it. But the default is what most users get, so for Anthropic that’s a big number walking out of the door. And, according to the same reports, Replit isn’t the only one: Rippling and DataCamp got similar offers.

I’m not going to argue about which model is better (that changes every few weeks anyway, which is rather the point). What interests me is the question every CTO reading those headlines should be asking: if a competitor of my AI provider offered me 30% off tomorrow, could I actually take it?

The Price Is Part of the Architecture

Here’s the thing: a year or two ago the AI bill was a rounding error for most products. Nowadays, for anything with an agent in it, tokens can easily be one of the biggest lines on the cloud invoice. As such, the ability to switch providers isn’t an engineering nicety any more, it’s a negotiating position. Replit could only take that discount because its product could run on someone else’s model. If switching would have taken them two quarters of rewrites, the discount would have been academic.

And bear in mind it’s not only about price. Providers change rate limits, deprecate models, have outages, change their terms, or (as we’ve seen this month with discounts being withdrawn) change the commercial relationship. If one vendor going sideways can take your core feature down, that’s a single point of failure, and we’d never accept that for a database.

Where the Lock-In Actually Lives

I had a look at our own code in Calendrz with this in mind, and I’ll be honest: it’s a mixed picture, which I suspect is true for most teams.

We have two AI features. The simpler one turns your free slots into a friendly paragraph you can paste into an email. It calls the Anthropic API directly, with the URL and the model right there in the class. Not pretty! But it has a plain-text fallback if the call fails, so the worst case of losing the provider is a less chatty message, and swapping it for another vendor is an afternoon’s work.

The Smart Scheduler (the agent you can email to book meetings) is a different story. On the plus side, the model name is configuration, not code, the system prompt lives in a Markdown file rather than in Java strings, every call goes through a single gateway interface, and there’s a circuit breaker so a provider outage degrades gracefully instead of piling up requests. On the minus side, the tool definitions and the conversation handling are built on the Anthropic SDK’s own types. That gateway interface was written for testability, not portability, so switching would mean rewriting the tool plumbing and, more importantly, re-testing every prompt against a new model. I’d guess days rather than weeks, but not an afternoon.

And that last point is the bit people underestimate. The API call is the easy part; you can wrap it in an hour. The real lock-in is in the prompts, the tool-calling quirks and the behaviour you’ve tuned without realising it. Every model reads instructions slightly differently, so a prompt that works beautifully on one can be subtly wrong on another, and “subtly wrong” for a scheduling agent means a meeting booked at the wrong time.

What I’d Do About It

Don’t get me wrong, I’m not advocating some grand abstraction layer that supports every model on the planet. That’s how you end up with the lowest common denominator of all of them, plus a framework to maintain. Right tool for the right job. What I’d do instead:

Keep model names, limits and prompts in configuration, so changing them is a deploy rather than a rewrite.
Put one thin seam between your business logic and the vendor SDK, and keep the vendor’s types behind it.
Build an evaluation suite: a set of real (anonymised) requests with the answers you expect. That’s what makes a switch safe, because you can run a new model against it and see what breaks in an hour rather than in production.
Know your number: what you spend per provider per month, and roughly what it would cost you in engineering time to move. Then you know which discounts are worth taking.
Have a fallback for every AI feature, even if it’s a dumb one. “The AI is down” should never mean “the product is down”.

The evaluation suite is the one I’d start with, by the way, because it pays off even if you never switch: it’s also how you know whether next month’s model upgrade from your current vendor quietly broke something.

Bottom line: you don’t have to switch providers, but you should be able to. Could you do it by Friday? I’d be very interested to hear how other teams have handled this, drop me a line.

Originally published on liviutudor.com.

Beware of the Markdown File in Your Downloads Folder

Liviu Tudor — Tue, 27 Oct 2026 14:14:26 +0000

I read a story at the weekend that made me want to go and check my own laptop straight away. Researchers at Forever Security found a malicious AGENTS.md file sitting in a customer’s ~/Downloads folder (BleepingComputer has the details). Someone started a coding agent in that folder, the agent did what agents do and read the instruction file it found there, and then it dutifully installed a rogue npm package. No exploit, no zero-day, no clever buffer overflow. Just a Markdown file politely asking the agent to do something bad, and the agent obliging.

The researchers reproduced it against OpenAI Codex with a harmless payload (it opened the calculator) and it worked in 90% of their tests. A related trick with a CLAUDE.md file redirected Claude Code’s API traffic to a server they controlled, which exposed the agent’s OAuth token and let them return tool calls that ran code in roughly half the attempts. And here’s the bit that made me wince: their telemetry showed Claude Code alone had been launched more than 1,300 times from people’s Downloads folders. Why? Because “tidy up my Downloads” is exactly the sort of chore people hand to an agent!

Instructions Are Code Now

Here’s the thing: for 30-odd years us engineers have been trained to be suspicious of executables. Don’t run the .exe from the email, don’t curl | bash a script you haven’t read, and so on. A Markdown file, on the other hand, was always the most harmless thing on your disk. It’s documentation! Nobody ever got hacked by a README.

Well, that’s no longer true. The moment an agent with shell access treats a text file as instructions, that text file is code. It doesn’t matter that it’s written in English rather than Python: it changes what runs on your machine, with your permissions, your tokens and your SSH keys. As such, an AGENTS.md or CLAUDE.md deserves the same suspicion as a shell script, and the folder you start the agent in is effectively its trust boundary.

Bear in mind the researchers point out there’s nothing for OpenAI or Anthropic to “patch” here. Browsers save files to Downloads without asking (that’s a feature), agents load instruction files from their working directory (that’s also a feature), and put the two together and you get a security hole. Two perfectly reasonable defaults combining into an unreasonable outcome is the oldest story in security, and I suspect we’ll see a lot more of it as agents get more autonomy.

What I’d Do on Monday Morning

If I were running an engineering team right now (and I’ve sat in that seat as a CTO), this is what I’d ask for this week, none of which needs a budget:

Agents start in a project’s root, never in a home directory, Downloads or any other “junk drawer” folder. Write it down as policy, because people won’t guess it.
Instruction files (AGENTS.md, CLAUDE.md, Cursor rules and the likes) live in the repo and change through pull requests, like any other code. If one appears that nobody reviewed, that’s a red flag.
Agent permission settings get reviewed too. An allow list that lets the agent push to main or read your secrets folder is a decision, not a default.
Approval prompts and sandboxes stay on. I know they’re annoying (trust me, I know!), but “the agent kept asking me” is a much better complaint than “the agent installed something”.
Anything untrusted gets opened in an isolated environment first: a container, a throwaway VM, a cloud sandbox.

None of this is new, by the way. It’s least privilege and code review, which is exactly the point: we don’t need a new security discipline for agents, we need to apply the old one to a new kind of code.

The Same Problem, From the Builder’s Side

I’ve been on the other side of this too, because Calendrz has an agent that reads text written by people it can’t fully trust: you can email the Smart Scheduler and ask it to book a meeting. Email is about the most hostile input there is, so we treat every message as untrusted until proven otherwise. A message has to come from the address of an existing account before the agent even sees it, and unless the email passes both SPF and DKIM checks the agent does nothing until the account owner clicks a one-shot confirmation link. Even then, the agent proposes a time and asks before it creates anything, and its tools are deliberately narrow (it can look for free slots and book events, it can’t go wandering off to install packages).

Is that bulletproof? No, nothing is. But the principle is the same one the AGENTS.md story is screaming about: decide up front which text is allowed to give your agent orders, and treat everything else as data. Don’t get me wrong, I love working with coding agents and I use them every day. I’m just not going to start one in my Downloads folder. Come to think of it, I’m not sure I’ll start one in my home directory either.

Bottom line: if a file can tell your agent what to do, it’s code, so review it like code. Your security team will thank you 😉

Originally published on liviutudor.com.

Of Leaders, Workers and Too Many AI Agents

Liviu Tudor — Thu, 22 Oct 2026 14:40:31 +0000

I keep seeing a version of this with the companies I advise: the leadership team comes back from a conference (or a vendor demo) fired up about AI agents, a few months later there are agents for everything, and when you go and sit with the people actually doing the work, the mood is… let’s say more reserved. So I wasn’t surprised when a new Asana report, covered by CIO Dive this week, put some numbers on it. Asana surveyed more than 4,500 CIOs, AI leaders and workers in the US and UK, and found a proper gap between how leaders and workers experience agents.

The Numbers

68% of the leaders use three or more agents every week, compared with 36% of the workers. Fewer than a quarter of the workers say the agents available to them can handle the tasks they most need help with. Nearly half of the workers who use agents say they spend about 10% of their working time switching between tools, figuring out which agent to use, managing outputs or sorting out conflicts between them. And 38% of them say more than a quarter of the agents’ work is duplicated or overlapping.

Let me translate that last bit: a good chunk of these people now spend half a day a week managing the things that were meant to save them time. Go figure.

Why Leaders and Workers See It Differently

Here’s the thing: I don’t think either side is wrong. The work a leader hands to an agent (summarise this thread, draft that email, pull together the numbers for the board deck) is exactly the work agents are good at: self-contained, low on hidden context, and easy to eyeball for mistakes. The work an engineer, a support person or an accountant needs help with is the opposite. It’s full of context that lives in people’s heads, in five different systems and in “oh, we never do it that way because of that customer in 2023”. An agent that doesn’t have that context produces something that looks right and isn’t, and the worker is the one who has to spot it and fix it.

So when the report says the workers’ caution is “calibrated, not uninformed”, I’d go further. The people closest to the work are your best sensor for whether an agent is actually helping. If they’re lukewarm, treat that as data, and resist the urge to file it under “resistance to change”.

Measure the Work, Not the Agents

The line in the report I liked most comes from Arnab Bose, Asana’s chief product officer, who reckons CIOs should stop measuring agent activity and start measuring whether the work actually gets finished. Amen to that! I keep seeing dashboards that show “AI adoption” as the number of prompts, active users or agent runs. That’s like measuring a restaurant by how many times the kitchen door swings: busy, sure, but did anyone get fed?

When I built the AI scheduling assistant in Calendrz, the very first phase had no user interface at all. It was plumbing: the feature switched off by default (globally and per user), and an audit log where every single request ends with a definite outcome (done, poll started, rate limited, error, and so on). Not exactly glamorous, but it meant that from day one the question “did it actually do the job for this person?” had an answer in the database, rather than in somebody’s gut feeling.

What I’d Tell a Leadership Team

Count your agents, then cut them. If 38% of people see overlapping agent work, you have too many tools doing the same thing. Fewer agents with real context beat a dozen generic ones.
Ask the workers which task they’d most like gone, and start there. Not the task that’s easiest to demo.
Measure finished work: tasks completed end to end without rework, time to resolve, errors that reached a customer. Activity metrics will always go up and to the right, and they tell you nothing.
Know what every agent is doing. Nearly two-thirds of executives in a Workato report expect an agent in their own environment to cause a public security or compliance incident within 18 months. If you believe that, an audit trail isn’t optional.
Use the same agents your team uses, on their work, for a week. Truth be told, nothing closes a perception gap faster than a leader fighting with the tool themselves.

Bottom line: if your agents are busier than ever and your people are too, something in that picture is off. I’d be very interested to hear what you’re seeing in your teams, drop me a line.

Originally published on liviutudor.com.

Faster Code, Same Release Date: What Gives?

Liviu Tudor — Wed, 21 Oct 2026 15:12:15 +0000

I came across a survey this week that made me laugh out loud, and then made me want to write a blog post, which is usually a sign it touched a nerve. Coleman Parkes asked 300 senior engineering leaders (on behalf of Undo, who make debugging tools, so bear that in mind) how AI coding agents are working out for them. 79% of them said the agents generate code significantly faster. And the same leaders said the release cycle is “no faster than before”.

Wooow! What gives?

The rest of the numbers explain it pretty well. Their teams spend on average 9.8 hours a week producing code and 16.9 hours debugging it. And 35% of the generated code reaches production before the team has fully understood it. Meanwhile, Stack Overflow’s 2026 developer survey says 73% of the developers who use AI coding tools use them every day, and BairesDev’s latest barometer has 42% of developers saying AI writes at least half of their code (up from 12% a year ago). So the code is pouring in, and the releases are coming out at the same speed. Can you see the problem here?

Typing Was Never the Bottleneck

Let me explain. If you’ve ever looked at where the time goes in an engineering team, writing the code was always the smaller part of the job. Understanding what the code should do, how it fits with what’s already there, reviewing it, testing it, debugging it at 2am when it does something nobody expected: that’s where the weeks go. Speed up the typing tenfold and you’ve sped up maybe a quarter of the work (any engineer who remembers Amdahl’s law from university is nodding right now). Worse, you’ve just poured a lot more code into the slow part of the pipeline, so the queue in front of review and debugging gets longer, not shorter.

And as such, every line of code is a liability before it’s an asset. More lines produced faster just means more liability, unless something on the other end of the pipe can absorb it.

What It Looks Like From Where I Sit

Don’t get me wrong, I’m not one of the sceptics here. I build Calendrz with Claude Code nowadays, most changes are written by the agent, and I wouldn’t go back. But I can tell you exactly where my time goes now: reviewing.

A recent example: a change to the API behind Calendrz’s AI scheduling assistant added a new field to the response for when the assistant starts a meeting poll. The field was declared, documented in the API contract, the tests were green… and nothing in the code actually set it. Neat, huh? It got caught in the second round of review. Another one, a few days later: an endpoint answered 401 instead of 403 when asked about the wrong profile, and since both the web app and the mobile apps read a 401 as “your session has ended”, it would sign people out. That one got caught when the iOS app started using the generated API client.

Neither of these would show up in a chart about “AI writes buggy code”. The code compiled, the tests passed, it looked perfectly reasonable. Greg Law, Undo’s CEO, describes it as code that’s “almost, but not quite right”, and to be honest I can’t think of a better description. That’s the expensive kind of bug, because it survives right up until a real user finds it.

So What Would I Do About It?

If I was sat in front of an engineering team on Monday morning wondering why all this AI hasn’t moved the release date, here’s what I’d look at:

Measure the whole pipe. Lead time from idea to production and how often a release breaks something, never lines of code or the number of pull requests. The agents will win the latter every time, and it means nothing.
Treat review as the constraint, because it is. Keep changes small, and budget reviewing time as real work rather than something squeezed in between meetings.
Let machines check machines. In my case, a committed API contract with generated clients caught things that a human eye skimmed over. Contract tests, types, property tests, a second agent doing the review: the more the agent’s output gets checked automatically, the less your senior engineers become a very expensive linter.
You merge it, you own it. If nobody on the team can explain what a change does, it doesn’t ship. That 35% figure should scare any CTO.
Point the agents at understanding, not just at writing. The survey says about a third of teams only use agents for debugging and comprehension in the simple codebases, which is exactly backwards: the gnarly legacy code is where a tireless reader helps the most.

I suspect the teams that pull ahead over the next year or so will be the ones who rebuilt their review and verification around a simple fact: code is now cheap, and understanding it isn’t.

Moral of the story: the agent made the typing free. Nobody said anything about the thinking 😉

Originally published on liviutudor.com.

Of Banks and AI Agents: Lock the Window, Build a Door

Liviu Tudor — Tue, 20 Oct 2026 14:12:43 +0000

So this week two of the biggest names in US finance said, more or less out loud, that they don’t want your AI agent anywhere near your money. Jamie Dimon said on JPMorgan’s third-quarter earnings call that the bank won’t let outside agents operate inside client accounts, as it’s too risky for the clients and for the bank. And Charles Schwab’s CEO, Rick Wurster, told Bloomberg that Schwab blocks dozens of agents every week trying to move client money, and that he gets a weekly report on it. (Citi and Bank of America are reportedly doing the same.)

My first reaction was “good”. My second one was a bit more nuanced, because buried in the Schwab story is the bit that actually matters for anyone building software right now, and it has very little to do with banking.

The Window and the Door

Here’s the thing: the agents being blocked are mostly getting in the old-fashioned way. They use the customer’s login and password, or they drive a browser and click around the website as if they were the customer. Schwab is specifically stopping that (credentials and browser automation), but it is happy to let outside AI tools read balances through controlled MCP servers, and it would rather clients use its own assistant for the rest.

Let me translate this for you: “please stop climbing in through the window with a copy of the customer’s keys, there’s a door over here, and the door has a bouncer”. And that is exactly the right answer. An agent that logs in with your password IS you, as far as the system can tell. It can do everything you can do, nobody can tell it apart from you in the logs, and the only way to cut it off is to change your password (which also cuts off you). An agent that comes through a proper door has its own identity, a limited set of things it’s allowed to do, a token that expires, and an off switch.

Now look at the other two agent stories of the same week. OpenCode disclosed that stolen API keys affected 1.4% of its Console users, with those keys then used for unauthorised charges (some of them report four-figure bills). And Workday agreed to buy C1 (ConductorOne) to manage access for people and AI agents. Three different companies, one theme: the hard problem with agents nowadays is identity, as in who the agent is and what it’s allowed to touch. The model is the easy bit.

I Had to Make This Call Too

I went through the same design question on Calendrz earlier this year, when I wanted people to be able to use it from Claude and ChatGPT. The quick option was an API key: generate one, paste it into the AI tool, done in an afternoon. Which is precisely the sort of long-lived secret that just bit those OpenCode users.

So instead Calendrz became an OAuth 2.1 authorisation server for its MCP server. You add it as a connector in Claude or ChatGPT, sign in with Google or Microsoft as usual, and the AI tool gets its own tokens: access tokens last 60 minutes, refresh tokens 30 days. The tools are marked as read-only or not, the Google and Microsoft tokens of your connected calendars never leave the server, and the endpoints that only make sense in a browser (adding a calendar account, paying for a plan) simply answer 403 to an agent. Was it more work than an API key? Bloody right it was! But the security model now fits in one sentence a user can understand: the assistant can read your calendar and press a few buttons, it never sees your passwords, and you can cut it off at any time.

Sure, But Isn’t This About Money?

Some analysts reckon the banks’ real worry is commercial: an agent that happily sweeps idle cash out of a low-interest account into something better is not great news for the bank’s interest income. I’ll give them that, there’s probably a bit of both in there. But commercial motive or not, the engineering answer doesn’t change, and it’s the same whether you run a bank or a two-person SaaS.

What I’d Do on Monday as a CTO

Find out how agents already get in. Look at your logs for headless browsers and logins that behave like scripts. Schwab’s CEO gets a weekly report; quite likely you don’t even know the number.
Split what agents can do into reading, changing and irreversible (moving money, deleting data, emailing customers). Reading is cheap to allow. Irreversible stuff needs a human in the loop, at least for now.
Build the door: OAuth, scopes, short-lived tokens, a separate identity per agent and a way to revoke it. If you expose an MCP server, the spec already asks for OAuth, so half the thinking has been done for you.
Treat every API key like cash in an envelope. Ask the team what the blast radius is if one leaks tomorrow, and whether there’s a spending limit on it. If the answer is “errr…”, you have your next sprint.

Bottom line: the agents are coming in, one way or another. You just get to choose whether it’s through a door you built or through a window you forgot to lock.

Originally published on liviutudor.com.

Trust Is a Feature: Verification Lessons From Building the Calendrz Mobile Backend

Liviu Tudor — Sun, 18 Oct 2026 03:39:41 +0000

Trust was everywhere in my LinkedIn feed last week. LinkedIn is testing a feature that lets verified members confirm their connections’ work and school history, with enough confirmations earning a profile badge. Its engineering team also explained how it detects low-quality AI content. And in Europe, the AI Act’s transparency rules had their first real effect: OpenAI said it will add invisible watermarks to text generated in the EU.

Each of those is a different problem, but the theme is the same. “Trust me” isn’t good enough any more. Platforms are being asked to prove things: that a person really worked where they say, that a piece of text really came from where it claims, that an account is really who it says it is.

I’ve spent the last couple of weeks on a less glamorous version of the same problem: preparing the Calendrz backend for native iOS and Android apps. Most of that work wasn’t about features. It was about making sure that the thing calling our API really is who it claims to be, and that the trust stops when it should.

Why mobile apps make trust harder

A web app has an easy setup: a session cookie, on a domain you control, in a browser that enforces a lot of rules for you. A mobile app is a public client. It runs on a device you don’t control, it can’t keep a secret (anything shipped in an app binary can be extracted), and it stays signed in for weeks. If a token leaks, you need to know, and you need to be able to shut it down.

Calendrz holds access to people’s work and personal calendars. That’s sensitive data: who you meet, when, and often why. So the bar here isn’t “good enough for a to-do app”.

What we built: verification at every hop

Here’s a quick tour of the trust-related pieces that landed in the Calendrz backend over the past couple of weeks.

1. Proof of who’s calling: PKCE public clients

The iOS and Android apps are registered as first-party OAuth clients with no secret, because a secret in an app isn’t really secret. They sign in with PKCE instead, which proves that the app finishing the login is the same app that started it. A malicious app that intercepts the redirect can’t do anything with the code it grabbed.

2. Proof that the link is really ours: Universal Links and App Links

When a login finishes, the browser has to hand control back to the app. Custom URL schemes can be claimed by any app, so we serve the Apple and Android “well-known” verification files from our own domain. That’s how the operating system knows a link to calendrz.com really belongs to the Calendrz app. If an environment isn’t configured, the files return a 404, so a misconfigured server can never claim links it shouldn’t.

3. Detecting stolen tokens: refresh-token reuse detection

This is the one I’m proudest of. The mobile apps get short-lived access tokens (60 minutes) and a refresh token that rotates: every time it’s used, it’s replaced. The catch is that a plain rotation setup only knows about the current token. If an attacker copied an older one, the server just sees an unknown token and rejects it, but never notices that something is wrong.

So we now keep a record (a SHA-256 hash, never the token itself) of every refresh token that has been rotated out. If one of those shows up again, that’s the signature of a stolen token chain, as described in the OAuth security best-practice RFC (RFC 9700). Calendrz then revokes the whole authorization, so both the attacker and the legitimate app have to sign in again, while the user’s other sessions are left alone. Refreshes for a given authorization are serialized at the database level, so two refreshes racing each other can’t be mistaken for an attack, and can’t undo a revocation.

4. Trust that ends when it should: revoke on account deletion

When you close your Calendrz account, or unlink one of your connected calendar accounts, every OAuth authorization tied to that identity is now removed. That covers the mobile apps and any AI assistants you’ve connected over MCP. Their refresh tokens die with the account. The revocation runs only after the deletion has committed, so a failure can’t leave you half-deleted.

5. Failing honestly instead of failing quietly

A smaller one, but it’s the same idea. When the new mobile event endpoints can’t load your calendar from Google or Microsoft, they now return an explicit “service unavailable” error instead of an empty list. An empty calendar is a claim (“you’re free all day”), and an app or agent would act on it. If we can’t verify the answer, we say so.

Trust is a feature, even if nobody sees it

LinkedIn’s colleague vouching will show up as a badge on a profile. Most of the work I’ve described won’t show up anywhere. Nobody opens an app and thinks “great refresh-token rotation”. But it follows the same principle: don’t take identity on faith; verify it, and be able to revoke it.

There’s also a lot of AI in this story. Much of this backend work was planned, written and code-reviewed with AI agents, and several of the review rounds caught real issues: a race between two concurrent refreshes, a revocation that could have been rolled back, a log line that leaked more than it should have. As more code gets written this way, having automated checks verify the work before it ships is the engineering version of the trust problem LinkedIn and the EU are trying to solve for content.

The Calendrz mobile apps are still in progress, but most of the trust layer underneath them is already in place. That felt like the right order: build the part people need to rely on before the part they’ll see.

Calendrz keeps your work and personal calendars in sync, privately and securely. Find out more at calendrz.com.

Originally published on liviutudor.com.