Yet, the hype machine keeps going and agentic commerce is undoubtedly the dominant narrative in payments and e-commerce, at least since late 2025, and ever increasingly in 2026. So dominant, if not more so, than mobile commerce was a few years back. For the purpose of this blog post, we define agentic commerce as “single or multiple AI-agents executing end-2-end purchases on behalf of humans”.

If you need a TL; DR for the next 2000 words: agentic autonomy in e-commerce is still more a promise and - for BNPL - an infrastructure problem and a regulatory question that needs solving first.

Now let’s dive in, and immediately skip all the analyst forecasts. They range from $5 trillion (with a t) commerce mediated by agents and 25% of global e-commerce enabled by agents by 2030 all the way to ChatGPT accounting for less than 0,2% of all e-commerce sessions in 2025, with only 10% of all consumers buying anything through AI and Gartner flat out saying that by end of 2027 over 40% of all agentic AI projects will be cancelled. Between all these extremes lies the failed OpenAI instant checkout project that was scrapped after just 3 months in March 2026. Take that how you will.

So instead of living in some vague future of overoptimism or bubble-bursting defeat, let’s look at the two aspects of agentic commerce that are actually relevant, and by relevant I mean: for BNPL (as I keep getting asked about it): Infrastructure and Regulation.

The infrastructure race currently unfolding

To say we are at the early stages would be an understatement. To say the infrastructure play is fragmented even more so. Note that when I talk about infrastructure, I narrow it down to the payment side of things. Here we have to observe things roughly in 3 layers:

• Identity: Who the hell is this bot? Who authorised it / is it even authorised?
• Protocol: How does an agent actually communicate with a merchant?
• Product: What the merchant actually integrates to enable agentic commerce.

Identity: Who the hell is this bot?

Before any transaction can happen, a merchant (and frankly also any BNPL-provider) needs answers to three questions: Is this agent what it claims to be? Was it authorised by a real human? What is it allowed to do? As of today, multiple competing frameworks are trying to answer these. We haven’t got a winner yet.

Visa built the Trusted Agent Protocol (TAP) with Cloudflare – cryptographic HTTP signatures that let merchants verify an agent at the CDN layer without writing new code. Mastercard went a different route with Verifiable Intent – SD-JWT delegation chains that link identity, intent, and action into a cryptographic audit trail, co-developed with Google. Both are being contributed to the FIDO Alliance , which formed an Agentic Authentication Working Group in April 2026. No specs published yet.

On the startup side, Skyfire gives each agent its own digital wallet with USDC settlement, and Experian launched an Agent Trust framework in April 2026 that binds a human identity to an agent via tokens and a registry.

The common theme: everybody agrees agent identity needs solving (urgently!), nobody agrees on how, and the players developing standards (like the FIDO Alliance) are at least a year away from publishing anything usable. The industry has at least coined the (very marketable) term – KYA, Know Your Agent – as the agent equivalent of KYC. But a catchy acronym is not a standard, and regulators haven’t acknowledged the concept yet. Hype looks a bit different, if you ask me.

Protocol: How does an agent talk to a merchant?

Five competing open protocols are shipping simultaneously, some of them already bring their own identity layer, some only the protocol of interacting with the merchant:

If you’re reading that table and thinking “oh my god, this looks like five competing standards that partially overlap, built by companies that are partnering and / or competing with each other” …well, congratulations, that’s 100% accurate. Stripe co-authored ACP with OpenAI while also endorsing Google’s UCP. Google leads UCP but also leads AP2, which sits inside UCP but is its own open-source project donated to FIDO. Confused yet?

Coinbase’s x402 doesn’t care about any of them and just does its own HTTP-native thing, while laying off 14% of staff and having non-techies vibe-code new products and suffering a multi-hour outage . I rest my case.

Product: What you actually integrate

This is where it gets interesting. Protocols are specs on paper – products are what merchants and payment providers actually plug into.

Stripe is everywhere. They co-authored two protocols (ACP, MPP), endorse a third (UCP), and ship the products that implement all of them. Their key solution is Shared Payment Tokens (SPTs) – scoped grants that let an agent use a buyer’s payment method, bounded by time, amount, and seller. SPTs now support card-on-file, network tokens (Mastercard Agent Pay, Visa Intelligent Commerce), and BNPL (Klarna, Affirm). Stripe claims to be the only provider unifying all three through a single primitive. They also very recently shipped Link Wallet for Agents – programmatic access to their digital wallet. At Stripe Sessions 2026 they announced 288 new products, the majority AI-related. If AI has a “hype-man” in payments, it’s Stripe, let’s face it.

Adyen takes a merchant-first approach. Their Universal Token Vault is processor-agnostic and bank-grade. They’re working with Google, OpenAI, Visa, and Mastercard – but the focus is on merchants controlling their own checkout, not ceding it to an agent platform. Still in beta, still very early days.

Shopify has the most advanced platform integration. Their Catalog API exposes products to agents via REST and MCP, natively supporting both ACP (ChatGPT) and UCP (Google AI Mode). Checkout Kit lets agents complete purchases. They’re the closest thing to a merchant-side standard.

And then there is PayPal in the Microsoft Copilot Checkout alongside Stripe . That’s it about PayPal.

So what does this mean for BNPL?

So the three infrastructure layers solve for general problems, some of those also touching BNPL, especially the identity bit. Identity is one of the key factors for fraud risk management in BNPL, and for over a decade, every checkout and payment provider on this planet has optimised for humans and blocked every bot interaction when spotted. That definitely requires a pivot, which is only possible if the identity piece is solved safely, by whichever winners emerge in the infrastructure race.

But, none of these three layers solve the actual hard problem for BNPL: how does an agent trigger a credit decision, capture legally valid consumer consent to BNPL terms, and authenticate the consumer – all without a human in the loop? The identity layer can verify the agent, the protocol layer can route the checkout, and the product layer can process the payment. But the bit in between – “does this human actually want to take on credit right now, and have they agreed to the terms?” – has no clean answer.

The closest thing is maybe Stripe’s SPT, which now supports Klarna and Affirm alongside card tokens. But SPT is a Stripe standard, not an open standard. If you’re a BNPL provider not on Stripe, you currently have no equivalent. Your options are: integrate with Stripe, build direct network-level integrations with Mastercard Agent Pay or Visa Intelligent Commerce, or wait for FIDO standards to mature (2027–2028 at the earliest). None of these options are really optimal. Maybe you should just – dare I say it – wait. Forrester concluded that agentic commerce “suffers from having been overhyped too early.” So waiting to see which standard actually brings solutions, might be viable.

The root cause for this “human-in-the-loop” conundrum is rooted in the regulatory requirements. If you are still reading this, let’s dive into it.

The Regulatory race that doesn’t deserve the name

Now, if you’re thinking “oh boy, the infrastructure bit was confusing as hell and slow and fractured” – welcome to the regulatory hell, where current frameworks don’t even know what AI agents are.

A card-on-file agent transaction is relatively straightforward: the agent presents a scoped token, the card network processes it. No credit decision, no consent to new terms. BNPL is fundamentally different – every transaction involves a credit decision, legally mandated disclosure, and explicit consumer consent. And that’s where regulation has something to say. No, I’m sorry. That’s where regulation has a lot to say.

The human-in-the-loop requirement

Both the EU and the UK are tightening BNPL regulation in 2026, and – in a nice bit of irony for post-Brexit Britain – they landed on essentially the same rules independently. Take that, Reform UK.

The EU’s CCD2 (Consumer Credit Directive, adopted 2023, rules apply November 2026) mandates adequate creditworthiness assessment before each credit decision, explicit disclosure of terms, and clear consumer consent. The UK’s FCA BNPL regulation (oversight begins July 2026) extends the same creditworthiness requirements to low-value and interest-free BNPL – which was previously unregulated . Neither framework mentions AI agents. Neither needs to – the requirements are clear enough: a human must consent to credit terms before credit is extended.

Ask yourself if your bank would grant you a mortgage if you sent your chatbot to negotiate with them. It’s not the exact same thing, but in spirit and much of the legal framework – it is.

The technology to merge an agentic checkout with a human-in-the-loop approach exists. Any agentic workflow could be paused to wait for a consumer to consent to the BNPL terms presented in a 2FA or authentication step. The agent receives the green light from the consumer and continues doing its thing. Whether regulators would be happy with that remains to be seen.

The liability vacuum

And then there’s the question nobody wants to answer: when an agent screws up a BNPL transaction, who pays? What keeps getting lost in this whole debate is that we are dealing with non-deterministic tools to create predicted behaviour - “buy me exactly what I want for the best price and the conditions I accept.” Try prompting this into three different AI models and see what happens. Any product manager who has ever run an AI eval will tell you how reliable LLM output is.

The EU’s AI Liability Directive was withdrawn in February 2025 – member states couldn’t agree. This removed the expected civil liability framework for AI-caused harms. If an agent erroneously initiates a BNPL agreement on a consumer’s behalf, liability between consumer, agent platform, and BNPL lender is legally undefined. Who pays for the damages?

PSD3 doesn’t help either – political agreement reached November 2025, full compliance not expected until late 2027 or early 2028 , and it does not explicitly address AI agents as payment initiators. Europe is in an implementation gap , and nobody is in a rush to close it.

So until regulatory frameworks – which tend to be rather localised – create clarity in handling agents for BNPL and credit-adjacent payment products, the human-in-the-loop approach is the absolute minimum. And even if the infrastructure race produces one or two global standards for identity and protocol, until local regulation catches up, adoption will drag.

Bubble Now, Bust Later

So, all in all, we can confidently say, when it comes to agentic commerce in general and specifically for BNPL payments: we are in the early days. At the current speed of things that might not mean much more waiting, at least not for the technical side of things, but it will definitely mean waiting on regulators to wake up to what the industry has cooked again.

And those are just the entry gateways for BNPL to participate in the alleged agentic revolution. Looking inwards there is definitely more homework to be done. Fraud models need to change fundamentally. Today they assume one human, one checkout. In an agentic world it’s one human, N agents, all taking on debt independently. See why that identity layer matters?

Not to mention that opening up to synthetic IDs comes definitely at a bad time, where agents have allowed fraudsters to commit synthetic identity fraud at an unprecedented scale – it was the fastest growing fraud type globally with an 8x YoY increase .

So maybe – just maybe – you should follow the example of my wife, shake your head silently, have a cup of tea and watch this race unfold, to see the clear winners in these big infrastructure bets. Maybe take all that newfound time to browse through all the virtual storefronts that have been lovingly crafted for your human eyes, buy yourself something nice, and pay later.

I’m all for hybrid-skill PMs, those with deep understanding of other vectors of business, be it data, analytics, engineering, go-to-market, sales. It’s no accident that especially small start-ups with fuzzy to non-existent roles are the fastest movers. It’s just fun to work like that. But most of us operate inside structures we didn’t design, with org-charts drawn by someone who left six years ago. Also, calling everyone “Member of the Technical Staff” is just cosmetics.

During the late 2010s / early 2020s, I would habitually ask mid- to senior PMs in job interviews a very, very open question:

“How would you, as a PM, help us here?”

Some candidates would list me every single product framework and then recite the SDLC like a bible. If I was lucky, I would hear the word “customer”. It was not the flex they thought it was.

Today’s equivalent is getting shown a Github repo filled with vibe-coded greenfield apps and Skills that Claude has written for itself. Again, it is not the flex you think it is.

I ask this to probe if the candidate understands in what context they will work and what that demands of them.

More than any other role, the business context you enter determines how you can operate as a PM. A senior-level IC can have the exact same job title at two different companies, yet they are most likely two completely different jobs.

Such “role plasticity” isn’t encountered as a financial analyst, or a software engineer or customer success manager. But as a PM, it’s a feature. Tools like AI or frameworks can influence (greatly) how you live the job day by day, but they cannot change the fundamental requirements put onto you.

So how do you determine the business context? It’s a chain of simple questions. Who owns the company – PE, VC, self-funded, public? Are they profitable? What’s the growth thesis? How are they planning to make money in three years that they’re not making today? Each answer narrows the tree of possibilities, and at the end of it, you have a rough playbook by which your target business operates – and with it, a much clearer picture of what your PM role actually looks like.

Let’s walk through two examples. Both are roles at profitable mid-market, PE-backed B2B companies. On paper, they are similar. In practice, they’re barely the same job.

You ask the questions. PE-backed? Yes. Profitable? Has been for years. Market position? Solid mid-market, say €20–40M ARR, strong retention, loyal customer base. Growth path? This is where it gets interesting. The PE firm bought in because they see runway the founders never chased – enterprise customers, international expansion, a proper sales motion. The thesis is: professionalise the go-to-market, move upmarket, grow ARR by the PE-usual 3–5x within the hold period, exit at a multiple. Your roadmap is now driven by what’s blocking that exit. Probably SSO, role-based access control, audit logs, SOC 2, multi-tenancy – boring as hell, none of it asked for by your existing customers. You’re sitting in on enterprise demos (or even giving them, we’ve all been there), hearing procurement objections, building pricing tiers that didn’t exist six months ago. Your success metric is the pipeline in a segment the company has never served before, with salespeople who don’t know what the hell they are doing. And the tension you’ll manage daily: your loyal mid-market base is pissed off, because you are neglecting them. Your customers!

Same opening questions, very different answers. PE-backed? Yes. Profitable? Yes. Market position? That sweet, sweet mid-market. But then: how many acquisitions in the last 24 months? Seven (wtaf!). Are they integrated? The PE-consultant says so, but don’t we all know the truth. What’s the exit thesis? Connect the products via shared APIs and a unified data layer, package it as a platform, sell the combined entity at a multiple none of the individual companies can achieve. Your roadmap was sketched on a whiteboard before you were hired. Your “customers” are largely engineering teams of sister companies, solutions architects. Your boss is a CTO, if you’re lucky, a CTpO with a small p. You’re writing specs for APIs, data migration paths, shared authentication. You’re in architecture reviews and haven’t talked to a customer in 2 years. Your success metric is whether three products can demo a unified workflow at the next board meeting (where that PE-consultant sits, claiming it’s all “almost done”). Product decisions are determined only by technical feasibility and integration timelines. Frankly, there is no product management left to do. If there’s a conflict between what end users want and what the integration plan needs, the integration wins.

Both PE-backed, mid-market B2B companies, both completely different roles – that is the key to understanding role plasticity in this job.

If you as a candidate can explain to me your role, based on the business context I present to you in the interview (or you have researched like the over-achiever that you are), I know we will be a successful team. That was true for all those candidates between 2018-2022, and it is true today. No frameworks, tools or AI agents have changed that.

The complex, fuzzy, rapidly shifting context window you hold as a product manager – the business vision, strategy, goals – is not replaceable by markdown files.

And if you believe it is, you might truly have an identity crisis. Maybe touch some grass, I don’t know.

Review

If you are an arachnophobe, you should not read this book under any circumstance. I mean it. If that does not bother you, it is definitely a fascinating thought experiment of evolutionary pathways. For me the end - first contact of 2 different species - was a bit weak.

Building Pi, and what makes self-modifying software so fascinating

The term was coined by Margaret Storey, a computer science professor who’s been studying developer productivity for over two decades. There’s also a MIT paper that frames it more broadly – the accumulated cognitive cost of outsourcing your thinking to LLMs. Consistent underperformance at neural, linguistic, and behavioural levels in LLM-heavy groups compared to non-users. Polemically shortened: the cost of becoming more stupid through AI usage.

But in software, cognitive debt isn’t about individual intelligence. It’s about shared theory or the collective understanding your team has about how a system works, why decisions were made, and what the boundaries are. Technical debt in the same vein is not some magical, autonomous deterioration of code - it’s also the collective human factor, the accumulation of architectural decisions over time that make maintenance harder and harder. Cognitive debt is the same mechanic, but instead of the code degrading, your shared understanding of it does. Then production is down and your team is staring at the code like it’s some ancient Mesopotamian stonewall.

The dangerous thing is that you might recognise it as a problem when it’s already too late to cheaply reverse. Your velocity metrics look fantastic. You shipped (insert fantastic number of choice)% more features this quarter, all on AI-steroids. But when an incident hits an AI-written module and the resolution takes four times longer because nobody can trace the logic – that’s your interest payment on cognitive debt. And more API usage billed for your GitHub Copilot.

So what do you actually do about it?

The natural cure might simply be the end of subsidised token use – I swear, one of these days I will write that blog post about the real pricing of AI-compute, but today is not the day. Maybe it will just stay a meme to hide in every single blog post I write. But running out of a session limit with your Claude Max subscription has the same effect: slowing down. And slowing down is, annoyingly, the point.

The practices to prevent cognitive debt already exist. TDD, pair programming, refactoring, rigorous code review. Nothing new. Code review in particular was never really about catching bugs – it was the primary mechanism for knowledge transfer. Juniors learned architecture by reading senior PRs. Seniors maintained context by reviewing everything. AI bypasses that entire loop. The code shows up, it works, tests pass, it gets merged. Nobody learned anything. Nobody built context.

You could spin up agents to review and document for you – but they cannot retain the shared theory your team needs, the why your code works a certain way. They can generate decision records, sure, but those still need human eyes to become shared understanding. As long as agents can’t hold that memory for your team, the rule is straightforward: at least one team member must be able to explain any AI-generated code change before it ships. Not read it. Explain it. Can I walk a teammate through every line? Do I understand why this approach was chosen over alternatives? Could I debug this at 3 a.m. without reprompting? If the answer to any of those is no, it doesn’t merge.

I am a huge proponent of velocity over everything – it’s literally in the name of the blog. But speed without understanding is not velocity. You will be sprinting on borrowed time.

Further reading:

• Margaret Storey – Cognitive Debt
• Margaret Storey – Cognitive Debt Revisited
• Kosmyna et al. – “Your Brain on ChatGPT: Accumulation of Cognitive Debt When Using an AI Assistant for Essay Writing Task”

Anthropic investigates report of rogue access to hack-enabling Mythos AI – The Guardian

Review

For me personally the weakest of them all, even though it gives a nice conclusion to the entire story. The weakness is mostly rooted in the way Simmons wrote the main protagonist Raul, who at times is much more stupid than the reader observing the world through his eyes.

Review

Road trip through the Galaxy - at different speeds. Also, the best chapter of the original Hyperion makes a fascinating return here.

In a recent podcast appearance, Boris Cherny compared the craft of software engineering to that of the “medieval scribes.” That tiny, hyper-literate elite. Scribes were often more educated than the kings and lords they served, not just copying books in a painstakingly slow process, but being quite literally the interface to written knowledge for masters who weren’t literate themselves.

Then came the printing press

The printing press didn’t destroy scribes overnight. It just made their core skill – slow, perfected, manual reproduction of text – irrelevant. To go back to Boris’s podcast appearance: the notion that scribes became the first authors is not historically provable, and is probably more of a romantic thought than a documented fact. The truth is that literacy skills survived, expanded rapidly, and found new vessels – early printers, editors, translators, scholars. The craft of producing written text and knowledge did not disappear, but the bottleneck for its proliferation disappeared.

The parallels to software engineering today

It is the running in-joke at many a tech company that the nerds writing software are a small priesthood, gatekeeping access to the mystical ways of the machine. If you don’t speak it – or aren’t code-literate – you can’t join the club. I have lively memories of my first encounter, as a very green PM way too many years ago, with an extremely seasoned architect, who folded me like a camping chair for suggesting a technical solution in a sprint planning. Good times.

AI advancements and the current wave of agents are comparable to the printing press. The “tech-illiterates” – CEOs, some PMs, designers – the kings who could not read – are now starting to build things themselves, using code syntax they don’t even understand.

And it’s not just non-techies shipping entire features without touching code. Even seasoned developers with a deep portfolio of programming languages under their belt are, by adopting AI into their workflow, writing less and less code themselves. Boris notes in the podcast that 100% of his code has been written by AI since November 2025. Andrej Karpathy stated in a recent podcast that by December he had already flipped to writing just 20% of his own code – and hasn’t typed a line since.

Now, those two are extreme examples – and Boris, for one, presumably has unlimited access to tokens.

There is a version of this essay where I spend three paragraphs on token economics, the true cost of compute, and whether we are all just characters in a fever dream fuelled by absurd amounts of investment capital. That essay exists. You are not reading it.

What remains

The engineering part is not going away – and it was never the same thing as coding anyway. The job being replaced is “human-as-syntax-translator.” The job that remains – and was always the aspirational one, by the way – is “human-as-system-thinker.”

This is an important distinction for juniors hitting the job market right now. I recently had a conversation about this with a CTO and founder in the European fintech space, and his framing nailed it: the entry-level job of the future will essentially be something like a “junior architect” or “systems orchestrator.”

All the underlying engineering muscles become more valuable, not less. System design, trade-off analysis, understanding failure modes, knowing why something should be built a certain way. Especially when you are orchestrating five agents simultaneously to go and build separate but ultimately interconnected things.

Ironically, this is what senior engineers were always best at. AI has just removed the prerequisite of absolute syntax fluency – and the scribe bottleneck along with it.

An uncomfortable way forward

I am really not trying to play the prophet here. This is just an attempt at a zoomed-out observation at a very specific point in time, which happens to be early 2026.

But as of right now, it’s clear that the transition – for new engineers and experienced ones alike – won’t be clean or comfortable. If your entire professional identity was built on coding at some insane craft level, that identity is under pressure. Speed was always everything, and the scribing bottleneck is gone.

And with the flood – where everyone, including those with little to no systems thinking, can spin up anything – judgement of quality becomes the scarcest resource. Just like an editor is the last line of defence against a bad author’s output. The difference is that this author (agent) never sleeps, never gets offended by your (the editor’s) feedback, and will cheerfully rewrite the entire chapter in thirty seconds.

Boris mentions in the podcast a 15th-century scribe who was asked how he felt about the printing press. The surprising answer was that he wasn’t lamenting the printing press, he was excited. He had never enjoyed copying books over and over and over again – the parts he loved were illustration and bookbinding.

That is perhaps the mental framework to adopt going forward: code syntax becomes a common language, a generalist view on the products we create becomes key, and we get to focus on the bits that actually matter.

That is, until you hit your usage limit.

Review

An absolute banger, and next to the original Hyperion the most fun to read. The end is fascinating and unmistakably alludes to certain real-life things.

Just 2 years ago, the answer might be something like “the programming language used is not relevant, you have to understand the underlying concepts of software engineering” (you are probably talking to a software engineer) or “You working with data? Go with Python!” (you are probably talking to a data scientist).

The answer today is: English. Learn English. (or any language you already speak).

“Coding” is rapidly becoming a commodity. When operating in an AI-powered VS code or directly in Claude Code, the limiting factor is just your ability to express as precisely as possible what you want in the natural language you speak. By “speak” I also mean dictate into your microphone. And then iterate on your steps. Your AI agents (plural) do the rest. December 2025 is the moment we can mark in our calendars when this shift truly happened.

This paradigm shift even justifies a paragraph on the Natural Language Programming Wikipedia page .

It’s very similar to the way translation software works. We have reached an amazing level of precision in text-to-text translations – and we are completely used to it.

Take DeepL as an example. Being tri-lingual, I often try to test the output based on an input I know the meaning of, and time and time again I am amazed that the software even captures some subtle meaning that is far removed from simple line by line, word by word translations.

But still – it has become a commodity. We are so used to it and its quality output that we use it casually, hidden within a browser extension, just one click away from understanding any foreign language.

LLMs have become so precise in translating your natural language input into the appropriate code syntax that learning a new (programming) language is a valiant effort, but not a necessary one. It has the same benefits as learning a new (natural) language – it makes you smarter, believe it or not – but beyond that you will be able to navigate the complicated world of coding pretty easily. Just as you would be able to navigate with Google Translate through your next holiday in Thailand.

The question today is not really about code. It’s about whether you can think precisely enough to tell a machine what you want.

AI didn’t just lower that bar – it blew open the door and removed the secondary skill of learning a programming language completely. And we are getting used to it faster than we realise.

And a small PS: note that I write explicitly about coding. I am not talking about the engineering side of software. That’s for another time.

Review

If you don’t hate cliffhangers (though I am not sure we can call this one, since it is obvious from a mile away) this book is an absolute must-read. I have procrastinated reading anything Simmons, and especially the Hyperion Cantos for ages, but this first book is definitely the masterpiece of the series.

Review

I don’t have many words to waste: this book kept me glued to my e-reader and was one of the best medieval horror fantasy books I have ever read. If you haven’t read it, you should have FOMO.

Review

Personally a slight improvement from Count Zero, as the stories start converging into a satisfying end of the trilogy.

Review

A bit weaker than its predecessor, and for me personally Gibson’s (deliberately) chaotic writing style manifests even more here - I know some critics might say that it’s on purpose, but I simply don’t like it.

Review

Yeah, I was late to a classic, so what. Great book, you should read it, shockingly relevant and the basis for the Cyberpunk genre as we know it. Not a 10 out of 10, because I really struggle with Gibson’s writing style.

For software engineers, it’s the speed at which they spin up things on their local machine via the terminal. And I’d be lying if I said that joke isn’t hidden somewhere in the name of this blog. But I digress.

For a physicist, terminal velocity is the maximum possible velocity of an object once its acceleration equals its drag. In this state, the object stops accelerating and continues at a constant speed.

Skydivers are probably more familiar than most with this concept. According to Wikipedia, the standard free-fall position (face down, belly to the ground) puts them at roughly 55 m/s.

And skydivers also know that reaching one’s terminal velocity is just half the fun. The real kicker is to increase it and – since gravity remains the constant – that means reducing the drag: pull in your arms and legs, lean forward head-first.

Once you dive (pun intended) into that rabbit hole, you realise this is a remarkably hard physical feat. Speeds of up to 90 m/s are possible with enough experience. Which is incredibly fast, if that needs to be stressed again.

To bring the metaphor home: one of my core beliefs is that speed beats literally every other business metric when building software products. Speed to discover the right things to build, speed of execution, speed to market, speed to pivot when experiments go wrong. Good tech companies have already accelerated to terminal velocity. The best companies have found ways to pull in their limbs and decrease the drag to reach even higher speeds. Excellent leaders always find ways to decrease that drag as much as possible.

Reaching such a flow state with your organisation - where things mesh like clockwork, where roles and responsibilities start to blend and teams have a singular focus - is probably the most fun you can have working in tech.

This blog aims to be a collection of posts, essays, personal experiences and active learning on this and related topics. And since it needs to be stressed these days – it is written by a human . Hope to see you around.

Matthias

(PS: This blog migrated away from my old Substack. Some of the early posts will be from my archive.)