Human-on-the-Loop AI Control

I was in a meeting last month where someone from a financial services team walked us through their AI oversight process. Every automated trading decision above a certain threshold gets routed to a human reviewer. The reviewer checks the decision, approves or rejects, and the system proceeds.

“How many decisions per day?” I asked.

“About forty thousand.”

“And how many reviewers?”

“Three.”

Nobody laughed. I think because everyone in the room already knew the answer before I asked. The math doesn’t work. It never did, really, but we’re only now being honest about it.

Frank Kschischang and the Future of Engineering Impact

Earlier this month, the University of Toronto named Frank Kschischang a University Professor — the institution’s most distinguished academic rank, held by fewer than 2% of tenured faculty. Unless you work in information theory or error-correcting codes, you’ve probably never heard of him.

You’ve almost certainly used his work.

The Invisible Layer #

Kschischang co-created factor graphs, a mathematical framework for representing and computing with complex probabilistic relationships. If that sentence made your eyes glaze over, let me put it differently: factor graphs are a foundational tool used in error-correcting codes that make your wireless communications work, in the LDPC decoders inside your WiFi chipset, and in the probabilistic models that underpin a growing chunk of robotics and machine learning.

Panel: Global DevRel in the Age of AI Documentation

I spent last week at DevRelCon New York and the shift in conversation was impossible to miss. Two years ago, every panel was about community building and developer experience. This year? Half the sessions were about one question: how do you make your platform visible to AI agents?

The developer discovery pipeline has fundamentally changed. It used to be simple: developer has a problem, searches Google, finds your docs, reads them, evaluates your API. That model still exists, but it’s no longer primary for a growing segment of developers. The new path is messier: developer has a problem, asks Claude or ChatGPT, gets a recommendation that either includes your platform or—more likely—doesn’t.

Year of Missing ROI on GenAI Investments

Full disclosure: Google signs my paychecks. AI sits at the core of everything the company does. So understand the position this comes from — the enterprise GenAI ROI story ranks, for most organizations, as pure fiction.

Not for every organization. And not forever. But right now, in March 2025, the gap between investment and measurable return staggers. The industry’s collective unwillingness to talk about it honestly? That starts to feel irresponsible.

Building AI-Native Teams: Lessons from OpenAI Codex

I read about how OpenAI structures their Codex team last week, and something clicked that I struggled to articulate for months. The shift to AI-native engineering goes beyond giving developers better tools—it reorganizes around the assumption that AI participates in every workflow. Not an add-on. Not a plugin. A participant.

The Codex team operates with roughly 40 people: 1 PM, 2 designers, the rest engineers. They ship multiple releases per week, sometimes pushing four internal builds in a single day. Those numbers would sound like chaos at most companies. At OpenAI, that’s just Tuesday.

SEMR Report 2025: AI Moves from Experimental to Essential

Jellyfish just published their 2025 State of Engineering Management Report, and one number jumped off the page: 90% of engineering teams now use AI coding tools. A year ago, that figure was 61%. Only 3% of respondents said they have no plans to adopt.

The adoption question is settled. The measurement question—wide open.

The Adoption Curve Collapsed #

I’ve managed engineering teams through several technology shifts—containerization at TaskRabbit, cloud migration at earlier companies—and none moved this fast. From “should we try Copilot?” to “everyone’s using something” in twelve months. GitHub Copilot leads at 42% adoption, but here’s the part that surprised me: 48% of teams report using two or more AI coding tools simultaneously.

Strategic Restructuring for AI-Centric Operations

Here’s a stat that should keep every CTO up at night: 92% of enterprises invest in AI, but only 1% have achieved scaled impact across their operations. Gartner estimates that 40-85% of AI projects never make it from proof of concept to production.

Those numbers aren’t a technology failure. They’re an organizational failure. And I’ve seen it firsthand.

The PoC Graveyard #

Every company I’ve worked with in the last year has an AI proof of concept. Most have several. They demo well. Leadership gets excited. And then nothing happens.

The Decline of DEI Programs in High-Tech Leadership

Women Who Code shut down in April. Girls in Tech dissolved in August. Tech Talent Charter closed the same month. Three organizations that collectively supported hundreds of thousands of women and underrepresented people in tech—gone within five months of each other.

This isn’t a coincidence. It’s a pattern, and the data behind it is damning.

The Numbers #

DEI-related job postings declined 44% by mid-2023 compared to the prior year. By late 2023, the decline accelerated further. CNBC reported in December 2023 that Google, Meta, Zoom, and the company formerly known as Twitter all made significant cuts to their DEI teams and programs. Not trims. Cuts.

AI Adoption Divide: The Global North vs. South

I grew up in Rio de Janeiro. My first startup ran on a shared hosting plan that went down every time it rained hard enough to flood the server room in Botafogo. That was 2010. The infrastructure has improved since then, obviously, but when I watch the AI discourse from San Francisco — all the breathless predictions about how AI will transform every industry — I keep thinking about that server room.

AI-Driven Attrition in Data-Heavy Support Roles

The AI job displacement everyone warned about? It’s not happening the way people imagined. No dramatic announcements. No factory floors going dark. No headlines about a hundred thousand people being replaced by a single model.

Instead, someone on the customer support team quits and the position doesn’t get backfilled. A market research analyst retires and the team absorbs the work using GPT-4. A data entry contractor’s engagement ends and nobody renews it. The org chart shrinks by one, then two, then five — and nobody calls it a layoff because technically, nobody was fired.

Crossing the Chasm: AI's Impact on Team Performance

Geoffrey Moore’s Crossing the Chasm came out in 1991. It describes what’s happening with AI adoption in engineering teams right now — with uncomfortable accuracy.

Here’s the framework: new technology gets adopted by innovators and early adopters (the enthusiasts), then hits a chasm. That’s the gap between early adoption and mainstream use that kills most products. Crossing it requires a fundamentally different approach — stop selling to enthusiasts and start solving a specific, painful problem for the pragmatic majority.

Developers Share What Helped Them Land New Roles in 2024

A friend of mine — senior backend engineer, twelve years of experience, ex-Stripe — applied to 340 jobs last fall. Got four callbacks. Two interviews. One offer.

That ratio would’ve been unthinkable in 2021. But in the post-layoff market of 2024, it’s become disturbingly normal. I’ve been on the hiring side at DreamFlare AI for the past few months, and what I see from the other end of the table confirms it: the market is brutal, the volume of applicants is staggering, and most of the advice floating around online is outdated.

OpenAI Codex: Structuring AI-Native Teams

Six months into building DreamFlare’s engineering team with AI tools baked into the daily workflow, some opinions have formed. A few of them are probably wrong. But the experience turned concrete enough that the lessons on structuring teams — when AI pair programming is the default, not the exception — deserve sharing.

The 55% number and what it misses #

GitHub published a study in September 2023 showing that developers using Copilot completed tasks 55.8% faster than those without it. The earlier academic study from February 2023 (Peng et al., published in collaboration with GitHub Research) found similar results across controlled task scenarios. These numbers get cited constantly; they’re real.

Post-COVID Layoffs: Framing the Industry Correction

I’ve been putting off writing this post because the topic is genuinely painful. People I know and respect lost their jobs over the past two years. Friends. Former colleagues. Engineers, PMs, designers who did nothing wrong except work at companies that hired too many people too fast.

But the framing I keep seeing — that tech is “in crisis,” that the layoffs represent some fundamental collapse — doesn’t match the data. And bad framing leads to bad decisions, for companies and for the people navigating this market.

The Product Manager Role: Lessons from the PM Debate

New year. I want to talk about the most contentious debate I saw in tech this past year — and somehow it had nothing to do with AI.

At Figma’s Config 2023 conference back in June, Brian Chesky told the audience that Airbnb “got rid of the classic product management function.” The internet went nuts. PMs panicked. Founders cheered. Twitter threads stretched for days. Hot takes piled up like laundry nobody wanted to fold.

GitHub Universe 2023: The Power of Micro-Mentoring

Yesterday was the application deadline for GitHub Universe 2023’s micro-mentoring program. If you missed it—don’t worry. I’m not here to promote something you can no longer sign up for. I’m here because the model itself is worth stealing.

GitHub offers 30-minute virtual 1:1 sessions between students and GitHub employees ahead of their annual Universe conference (November 8-9 this year). They’ve been doing it for five consecutive years now. And honestly? It’s one of the most underappreciated ideas in developer community building.

HashiCorp Terraform License Shift: Strategy vs Community

Two days ago, HashiCorp announced that Terraform — and all their products — would switch from the Mozilla Public License (MPL 2.0) to the Business Source License (BSL 1.1). The news dropped on August 10th and the internet hasn’t stopped arguing about it since.

I have complicated feelings about this one.

What Actually Changed #

BSL isn’t proprietary, exactly. You can still read the source code. You can still use Terraform for your own infrastructure. What you can’t do is offer a competing commercial service built on HashiCorp’s code without their permission. After four years, the code converts to MPL 2.0 automatically — the “change date” mechanism.

Platform Engineering: Bridging the Dev/Ops Gap

“You build it, you run it.” That was the DevOps promise. Engineers would own the full lifecycle of their services — from writing code to operating it in production. No more throwing things over the wall to an operations team. No more “works on my machine.” Full ownership, full accountability.

In theory, this was liberating. In practice? It buried engineers under a mountain of operational complexity they never asked for and weren’t trained to handle.

Generative AI: Cognitive Industrial Revolution

The Industrial Revolution mechanized physical labor. Steam engines replaced muscle. Factories replaced workshops. The economic transformation took decades, displaced millions, and ultimately created more wealth and more jobs than the systems it replaced.

I think we’re at the start of something equivalent for cognitive labor. And unlike the original, this one is moving on a timeline measured in years — not generations.

The Numbers #

McKinsey’s latest analysis projects that generative AI could add $2.6 to $4.4 trillion in annual value to the global economy. To put that in perspective, the UK’s entire GDP is roughly $3.1 trillion. We’re talking about a technology whose economic impact — by McKinsey’s estimate — is comparable to adding another G7 economy to the world.

Formula Racing: Pivot to Electric and Tech Success

I’ve been thinking about constraints lately. The kind that make you better instead of smaller.

Formula E started in 2014 as motorsport’s awkward experiment. The cars were slow compared to F1 — embarrassingly slow, actually. The races were short. The tracks were temporary street circuits in city centers. Nobody in the traditional racing world took it seriously; most coverage had a patronizing tone. “Electric racing. How cute.”

Nine seasons later, the Gen3 car produces 350kW (roughly 470 horsepower), hits 200 mph, and recovers up to 600kW through regenerative braking. That regenerative figure is wild — it means the car harvests energy during deceleration at a rate that would’ve been the total power output of the original Formula E car.

Learning to be a Great Leader is a Marathon, not a Sprint

I almost called this post “Leadership Lessons I Wish I’d Learned Sooner” — then realized that framing misses the entire point. The lessons aren’t late. They arrived exactly when I was ready to absorb them, which is the whole problem with leadership development: you can’t speed it up the way you speed up a code deployment.

I’ve managed engineering teams for the better part of a decade now. Small teams (3 people at Backer), distributed teams (9 engineers across 4 time zones at TaskRabbit), and DevRel teams at Google spanning multiple offices. The contexts differ wildly, but one pattern has been consistent: the leadership skills that matter most are the ones that resist being learned quickly.

Productivity: How to ship faster and on time

Managing both kinds of teams — on-time and perpetually late — taught me one thing above all. The talent gap between them ran roughly zero. The process gap ran enormous.

An uncomfortable truth in this industry: shipping speed ranks as a leadership problem far more than a technical one. Engineers love to blame late deliveries on “complexity” or “technical debt” or “scope creep,” and those factors are real enough. More often, nobody established clear boundaries around what “done” means, nobody surfaced blockers early enough, and nobody had the nerve to cut scope when reality diverged from the plan.

Finding the 6th Day: A Productivity Guide for Engineers

Here’s a number that keeps bugging me: the average engineer at a large tech company spends only 30-40% of their workweek on actual engineering work. The remaining hours vanish into meetings, Slack, email, context switching, and whatever passes for “alignment” this quarter.

That means in a 40-hour week, you’re getting maybe 16 hours of real output. Two full days, gone.

After years managing engineering teams — at TaskRabbit, at Google — the pattern holds consistent across companies, team sizes, and seniority levels. Smart people sit down to write code, get interrupted, attend a meeting that should have stayed a doc, get interrupted again; by 4pm the day has accomplished roughly nothing.

ADRs as Feedback Loops for Distributed Performance

I wrote about Architecture Decision Records a while back. Back then, I saw them as documentation—a way to capture the why behind decisions so future teams wouldn’t repeat past mistakes. Useful, sure. But kind of… administrative?

I’ve changed my mind. Or rather, I’ve realized I was only seeing half the picture.

At Google scale, working with distributed teams scattered across time zones, ADRs turned out to be something else entirely. They’re feedback loops. And that distinction matters more than I expected.

The Log4Shell Aftermath: Why Maintenance is Creation

A critical vulnerability in Apache Log4j dropped this morning. CVE-2021-44228. Remote code execution in a logging library embedded in basically everything Java touches. Scrambling starts now, if it hasn’t already.

Writing this the same day the news broke because the conversation already heads the wrong way. Patching, scanning, who updated dependencies fastest — those things matter. Symptoms, though. All symptoms.

The disease? The industry treats maintenance like it counts for nothing.

Psychological Safety in Knowledge Sharing

A few months into my time at Google, I watched a junior engineer ask a question in a team meeting that I thought was obvious. The answer was in the documentation—technically. It was covered in the onboarding guide—sort of. Three senior engineers had the answer off the top of their heads.

What struck me wasn’t the question. It was the silence before someone answered.

Two full seconds of silence where I could feel the junior engineer regretting asking.

Retaining Talent through Developer Experience (DevEx)

I lost good engineers to bad tooling—not once, but at every company where the build pipeline rotted and leadership shrugged.

Not officially, of course. The exit interview says “career growth” or “new opportunity”—the usual script. But in the months before departure, the complaints ran identical: slow CI, flaky tests, outdated docs, a deployment process requiring three manual steps and a Slack message to someone in another timezone. Death by a thousand paper cuts.

nasscom TechForGood: The Strategic Value of Social Good

Most companies treat social impact the way they treat office plants. Someone remembers to water them occasionally, they look nice in photos, and nobody measures whether they’re actually doing anything.

nasscom’s TechForGood initiative makes a different argument. Technology for social good isn’t a line item in your CSR budget. It’s a strategic lever that compounds over time.

I find this framing compelling because I’ve seen it work firsthand. Before moving to the Bay Area, I co-founded Doare.org in Brazil — a donation platform for non-profits that became the largest of its kind in Latin America. We built it because the problem was real and the technology to solve it was accessible. But what surprised me was how the mission attracted talent. Engineers who could have taken higher-paying jobs elsewhere chose to work on something that mattered to them. That retention advantage was worth more than any signing bonus.

Adaptability: The Core Engineering Skill for 2021

Nine months ago my entire team went remote overnight. Not the planned, phased, “let’s pilot this for a quarter” kind of remote. The kind where you close the office on a Friday and hope Zoom works on Monday.

Some engineers barely missed a beat. Others struggled for weeks. The difference wasn’t seniority or technical skill. It was how quickly they could rewire their working habits.

I keep coming back to that observation as 2020 wraps up.

Using Architecture Decision Records (ADRs) to Prevent Chaos

Last month I watched two senior engineers spend an entire sprint debating whether to use GraphQL or REST for a new internal API. They eventually chose GraphQL. The thing is, we’d already made that decision eight months ago for a different service — with reasoning that lived nowhere except maybe in Dave’s head. (Dave left in March.)

This happens constantly. A decision gets made in a meeting, or a Slack thread, or occasionally in someone’s head while they’re showering. Then people leave, context evaporates, and the next team walks into the same intersection and argues from scratch. Same debate, same circular reasoning, same outcome — or worse, a different one.