DEV Community: Raffaele Pizzari

The Gap Between Estimated and Delivered

Raffaele Pizzari — Wed, 08 Apr 2026 22:03:25 +0000

Here's a pattern I've seen play out dozens of times. A team estimates a feature at 5 story points. Low complexity, clear requirements, well-understood domain. By every estimation framework, it's a small task.

It ships three weeks later.

The team gets blamed for bad estimation. Leadership pushes for better grooming, more detailed breakdowns, tighter story points. The team tries harder. Next sprint, the same thing happens.

The estimate was never the problem.

Estimation does what it's supposed to do

Modern estimation frameworks are actually good at what they measure. The best ones decompose work into multiple dimensions: complexity (how hard is this to understand), effort (how much raw work), uncertainty (how many unknowns), and risk (what external factors could derail it). Each dimension gets scored, and the combination drives the story points.

This works. A 5-point story really is a 5-point story. The team correctly assessed the complexity of the code, the effort required, the technical unknowns. They weren't wrong.

The problem is that estimation measures the work. It was never designed to measure the environment the work has to travel through.

The gap has a name

Between "estimated" and "delivered" sits everything the estimation framework doesn't capture. I call it org friction: the invisible overhead that organizational structure, processes, and cross-team dependencies impose on every piece of work.

That 5-point story took three weeks not because the team misjudged the complexity. It took three weeks because a schema change needed approval from another team. The design review sat in a queue for days. Security wanted to sign off because it touches user data. The one person who understood the legacy service was unavailable. And the engineer doing the work got two focused hours per day between meetings, incidents, and "quick questions."

None of that is estimation error. It's organizational drag. And unlike technical debt, which at least gets mentioned in retros, org friction is untracked and unowned. It doesn't show up in Jira. Nobody has "reduce org friction" in their OKRs. But it's eating 30-40% of your team's capacity.

Seven sources of org friction

After paying attention to this for a while, I see the same patterns everywhere.

Cross-team dependencies. The work itself takes hours. The waiting takes days. Waiting for the Platform team to review your PR. Waiting for Design to finalize a spec they promised last sprint. The estimate captured the work. Nobody captured the queue time.

Process overhead. Change management boards, architecture review committees, compliance gates. Each one was created for a good reason. None of them were ever removed when the reason went away. They accumulate like sediment.

Knowledge silos. That one engineer who understands the billing service. That one PM who knows the historical context behind a weird product decision. When they're unavailable, work stops. Not because it's technically blocked, but because nobody else has the context to make the call.

Legacy process debt. This is different from technical debt. It's the outdated deployment process that requires manual steps. The testing pipeline that takes 45 minutes because nobody prioritized making it faster. The onboarding doc that hasn't been updated in two years. Not broken enough to fix, but slowing everything down.

Decision latency. No formal gate, just nobody with clear authority to make the call. Or the person who does keeps deferring. The feature is technically unblocked, but the team is waiting for someone to say "yes, build it this way." Estimates assume decisions happen instantly. They never do.

Context switching tax. The estimate assumed focused time. Reality: support rotations, incident responses, Slack threads from other teams, syncs that could have been async. The work takes three days of focused effort, but your engineers get two focused hours per day. The calendar is the friction nobody accounts for.

Misaligned incentives. Team A is measured on shipping features. Team B is measured on system stability. Team A needs Team B to deploy a breaking change. Team B has zero motivation to help. This isn't a technical problem. It's an organizational design problem. And it shows up as a "missed estimate" on Team A's board.

Stop improving estimation. Reduce the drag.

When teams consistently miss delivery targets, the default response is to push for better estimation. More grooming sessions. More detailed breakdowns. More precise story points.

This misses the point entirely.

The estimates are fine. A 5-point story is still a 5-point story. What changed between "estimated" and "delivered" wasn't the complexity of the work. It was the friction the work encountered on its way to production. Making teams better at predicting friction doesn't reduce it. It just makes everyone more accurately pessimistic.

The real lever is reducing the drag. And that's a leadership problem, not an engineering one.

Run a Friction Log

Here's the most useful thing I've done as an EM to make org friction visible.

For one sprint, ask your team to keep a shared doc. Call it a Friction Log. The rules are simple: every time someone is blocked, delayed, or slowed down by something that isn't the code itself, they log it. One line. What happened, how long they waited, which friction source it was.

No analysis during the sprint. Just logging. Keep it low effort.

After two weeks, read it together. What you'll see is a document that's almost impossible to argue with. Not opinions about process. Not complaints. Just a factual record of where time went that had nothing to do with the work your team estimated.

The first time I ran one, the log showed that 40% of the sprint's elapsed time was spent waiting on things outside the team's control. Cross-team reviews, decision latency, a compliance gate that took four days for a one-line config change. The estimates had been accurate. The org had been expensive.

A Friction Log does three things:

It separates estimation from delivery. You can see that the 5-point story really was a 5-point story. The extra two weeks was org friction, not estimation error. Once you can see the gap, you can talk about it.

It gives you data, not complaints. "Our estimates are always off" gets you a shrug. "Here's a log showing we spent 11 days this sprint waiting on cross-team reviews" gets you a conversation. Leaders respond to patterns with numbers.

It picks your battles for you. After one sprint, the top friction source is obvious. You don't have to fix everything. Pick the one that shows up the most and work on reducing it for the next quarter. Maybe it's getting embedded in the platform team's sprint review so your PRs don't sit in a queue. Maybe it's documenting the legacy service so you're not dependent on one person. Small, compounding improvements.

Nobody designed it this way

Nobody designed org friction into your company. It accumulated. One reasonable process at a time. One well-intentioned approval gate at a time. One team boundary at a time. Each decision made sense in isolation. Together, they created an invisible tax on every piece of work your team ships.

Your estimates aren't the problem. Your org is just more expensive than anyone's willing to admit.

The question isn't whether your team can estimate better. It's whether you, as a leader, are willing to name the drag and do something about it. Because the gap between "estimated" and "delivered" isn't a measurement error. It's a leadership opportunity.

Originally published on pixari.dev

The Engineering Manager Role Is Mutating

Raffaele Pizzari — Mon, 06 Apr 2026 07:44:34 +0000

I read Gregor Ojstersek's piece the other day. "Would I Still Go The Engineering Manager Route in 2026?". And it hit me in a strange way. Not because of the answer but because of the question. The fact that someone who's been doing this for years is publicly asking whether he'd do it again says something.

I've been in this role for almost three years. And I'd be lying if I said I hadn't asked myself the same thing.

But here's the thing. I've done this loop before.

Before I was an EM, I was an IC. Before I was an IC, I ran my own web agency for eight years. I was the CEO. I did sales, code, hiring, client management, architecture, marketing. Full ownership, full autonomy. And then I deliberately walked away from that, went back to building as an individual contributor, and worked my way through Lead and Principal before choosing management again.

I chose this role knowing what I was giving up. I'd already tasted the other side. Twice, actually.

That context shapes how I see what's happening to the EM role right now.

The job changed

When I moved into management, the deal was roughly this: you stop writing code full-time, you spend your days on people, process, and delivery. You run 1:1s. You shield the team from organizational noise. You hire, you coach, you make sure things ship. In return, you get a seat at the table and the satisfaction of watching people grow.

That deal still technically exists. But the fine print keeps growing.

Somewhere along the way, the expectations started stacking. I've seen it in my career, I've seen it in job postings, I've heard it from every EM I talk to. Be technical enough to review architecture. Be strategic enough to present to leadership. Be empathetic enough to handle burnout and conflict. Own delivery metrics. Own hiring pipelines. Own the roadmap conversation with product. And increasingly: pick up some coding too.

I don't think anyone designed it this way. It just accumulated. Browse any EM job listing from 2026 and count the responsibilities. Technical leadership, people management, delivery ownership, hiring, strategy, stakeholder alignment. Each one makes sense on its own. But the list keeps getting longer and nothing ever falls off.

I've seen this movie before

When I was running my agency, mobile was going to change everything. We had to rethink our entire business. Some agencies died. We adapted.

When I came back to IC, cloud and microservices were going to change how teams work. Some companies over-rotated, split everything into tiny services, and spent years untangling the mess. The ones who kept their heads did fine.

Now it's AI.

I've watched three cycles where a technology was supposed to make a role obsolete or fundamentally different. And the pattern is always the same: the technology matters, it does change things, but it doesn't change the things people think it will.

Mobile didn't kill web agencies. It made them busier. Cloud didn't eliminate ops. It renamed them. And AI won't replace engineering managers. But it is changing the math around the role in ways that are worth paying attention to.

What AI actually changes

AI doesn't build trust across a team over months. AI doesn't read the room in a planning meeting and realize the real problem isn't the estimate, it's that people don't believe in the project. AI doesn't tell a PM that the deadline is unrealistic and hold the line.

But AI does make small teams more productive. And when small teams are more productive, companies start asking why they need so many managers. The ratio shifts. Where you had one EM for five or six engineers, now it's eight. Ten. Twelve. The scope grew but the support didn't.

That's the actual pressure. Not "AI replaces managers." Just "we need fewer of them, and the ones we keep do more."

Combine that with the IC career track getting better, real Staff and Principal roles with real compensation, and you've got a situation where the best engineers don't need management to advance. The people who want to be EMs used to be the best engineers who also cared about people. Now some of them are choosing Staff instead. I don't blame them.

The player-coach myth

I keep hearing "player-coach" as if it's aspirational. Like we should all want to be the EM who also ships features.

I've been a player-coach. It means you do both jobs badly. You context-switch between a PR review and a difficult conversation about someone's performance. You write code in the gaps between meetings, which means you write code in 25-minute windows, which means you write bad code. Or you stay up late to get the focused time, which means you burn out faster.

The industry uses "player-coach" like it's a compliment. It's usually a budget decision disguised as a philosophy. Someone needed to cut a headcount and decided the EM could absorb the work.

I'm not saying it can't work. In early-stage startups, in small teams, when the scope is tight, sure. But in a 40-person org with multiple squads? If your EM is regularly shipping features, something is wrong with your staffing, not right with your EM.

The hard problems don't change

Here's what I keep coming back to, across all the cycles I've lived through. The technology changes. The hard problems don't.

Getting people aligned on what matters. Making decisions with incomplete information. Knowing when to push and when to protect the team. Helping someone grow when they don't see their own potential yet. Having the conversation everyone's avoiding.

Those problems looked the same when I was running my company in 2015. They look the same now. AI didn't create them and AI won't solve them. They're human problems, and the EM role exists because someone needs to own them.

That's why I'm not worried about the role dying. I've watched enough cycles to know it won't. But it will mutate. It always does. And the EMs who get left behind won't be the ones who ignored AI. They'll be the ones who forgot that the human stuff is the actual job.

It's one title, but it's not one job

I think a lot of the confusion comes from a naming problem. We all call ourselves "Engineering Manager" but we're doing wildly different jobs depending on the company, the stage, and the org.

I've talked to EMs who spend 80% of their time on architecture and code review. I've talked to EMs who haven't opened an IDE in two years and spend their days on coaching, hiring, and cross-team alignment. I've talked to EMs who are basically program managers with a different title, owning delivery timelines and stakeholder updates. All of them have the same title on LinkedIn.

This matters because most of the frustration I hear from EMs isn't really about the role. It's about the mismatch. You took the job expecting to be a people leader and you ended up being a delivery lead. Or you wanted to stay close to the technical decisions and instead you're spending your weeks in stakeholder meetings. The role didn't let you down. The expectations were just never made explicit.

If you're an EM and something feels off, before you question whether you want to be a manager at all, try a simpler question first: which version of this job is your company actually asking you to do? And is that the version you want?

Sometimes the answer is "I'm doing the wrong version of EM at the wrong company." That's a very different problem than "I don't want to be an EM anymore," and it has a very different solution.

If you're hiring an EM or about to become one: have that conversation early. Don't just talk about the team size and the tech stack. Talk about what the job actually looks like on a Tuesday. Where does this EM spend most of their time? What does success look like in six months? The clearer that picture is, the fewer EMs will burn out wondering why the job doesn't feel like what they signed up for.

The feedback loop problem

Something I've noticed talking to other EMs. A lot of us still build things on the side. Side projects, open source, weekend hacks. And when you ask why, the answer is almost never "to stay technical." It's because the feedback loop is different. You write code, you see it work, you feel something. It's immediate.

Management has its own rewards. Watching someone you coached nail a presentation. Seeing a team you built ship something complex without drama. Those moments are real. But they're slow. They happen over months. The feedback loop in management is measured in quarters, not commits. You have to learn to find satisfaction in that pace, and some weeks it's easier than others.

So would I do it again?

Yes. Without hesitation. I already did it twice.

I walked away from running my own company. I went back to being an IC. I had the full picture, the autonomy, the ownership, and I chose to come back to building first and then to management. Not because I had to. Because I'd seen enough of both sides to know which problems I actually wanted to spend my days on.

I love this job. The role is broader and harder than when I started. The industry hasn't settled on what it wants EMs to be. But that ambiguity is part of what makes it interesting. You get to shape it.

If you're an IC thinking about management: go in with your eyes open. The role is worth doing. It's also messier and more ambiguous than it looks from the outside. Talk to EMs. Ask them what their actual week looks like, not their LinkedIn version of it.

And if you're already an EM: the role is changing fast. It always has been. The technology driving the change is new but the pattern isn't. The EMs who'll thrive are the ones who can sit with the ambiguity and shape the role instead of waiting for someone to define it for them. That's always been the interesting part of this job anyway.

Originally published on pixari.dev

I Built a Game That Teaches Git by Making You Type Real Commands

Raffaele Pizzari — Thu, 02 Apr 2026 00:00:39 +0000

I work in IT, and there's one scene I keep witnessing. A developer joins the team, they're sharp, they ship features, they write clean code. And then someone asks them to rebase, and you can see the panic set in.

It's not their fault. Git is taught badly.

Every git tutorial I've ever seen follows the same formula: here's a diagram of branches, here's a table of commands, now go practice on your own repo and try not to destroy anything. It's like learning to drive by reading the car manual. Technically accurate. Practically useless.

I've watched junior developers memorize git add . && git commit -m "fix" && git push like an incantation, terrified to deviate because the one time they tried git rebase they ended up in a state that required a senior engineer and 45 minutes of git reflog to unfurl.

And I've watched senior developers, people with a decade of experience, avoid git bisect entirely because nobody ever showed them what it actually does in a safe environment.

So I built one.

Gitvana

Gitvana is a browser game. You play a monk climbing toward "git enlightenment" at the Monastery of Version Control. There's a Head Monk who assigns you tasks, a judgmental cat, and pixel art that looks like it belongs on a Game Boy.

But underneath the retro charm, there's a real git engine. When you type git init in the terminal, it runs git init. When you type git commit, it creates an actual commit in an actual repository. The repository lives in your browser, powered by isomorphic-git and an in-memory filesystem, but it's real. Every command, every SHA, every ref.

35 levels. 6 acts. 21 git commands. From git init to git bisect. No slides, no diagrams, no hand-holding. Just you and a terminal.

Play it at gitvana.pixari.dev. It's free, it works offline, and it doesn't want your email.

Why a Game

I could have written another tutorial. I could have built a sandbox. But I've been thinking a lot about how people actually learn, and the answer isn't "reading."

People learn by doing things that are slightly too hard, failing, figuring out why, and trying again. That's what games are. They're structured failure environments with feedback loops.

Every level in Gitvana has a target state, a set of conditions that the git repository must satisfy. "There must be exactly 3 commits on main." "The branch feature must be deleted." "The file config.yml must not contain the API key in any commit." The game validates these conditions in real time as you type commands. You see the checklist turn green, one objective at a time.

This isn't gamification bolted onto a tutorial. The game is the learning.

The Journey: 6 Acts

The structure mirrors how a developer actually encounters git:

Act 1: Awakening — The basics. init, add, commit, status, log, diff. You're a new monk. The Head Monk is patient. The cat is skeptical.

Act 2: The Middle Path — Branching, merging, cherry-pick, revert, stash. Things start getting interesting. You begin to understand that git isn't a linear timeline, it's a tree.

Act 3: Rewriting Reality — rebase, amend, squashing commits, purging secrets from history. This is where most developers tap out in real life. In Gitvana, you can't tap out. The monastery doors are locked.

Act 4: The Safety Net — reflog, blame, bisect, disaster recovery. The levels where you learn that git never truly forgets, and that reflog is the "undo" button nobody told you about.

Act 5: Advanced Techniques — Surgical staging, dependency chains, the operations that separate "uses git" from "understands git."

Act 6: Gitvana — The final trial.

Each act introduces new commands gradually, with in-game documentation you can pull up without leaving the terminal.

The Tech

The stack is deliberately minimal. Svelte 5 for the UI, xterm.js for the terminal, isomorphic-git for the git engine, and lightning-fs for the in-memory filesystem. No backend. No database. No accounts. Everything runs in your browser and your progress saves to localStorage.

The interesting engineering problems were all in the details:

Rebase was the hardest command to implement. The real git rebase is a multi-step, stateful operation. It collects commits, replays them one by one, and can pause mid-way for conflict resolution. I had to build a state machine that saves rebase progress to .git/rebase-merge/, handles --continue and --abort, and writes proper conflict markers when files clash.

Bisect maintains its own state files in .git/, just like real git. It performs an actual binary search across commits to find where a bug was introduced. In one level, you have to find which commit broke a test by using git bisect start, marking commits as good or bad, and letting the algorithm narrow it down.

The blame algorithm walks the entire commit history, builds a content-at-commit map, and attributes each line to the oldest commit where it appeared unchanged. It's not efficient. It doesn't need to be, these repos are tiny. But it's correct.

The level validator checks 12 types of conditions in real time: file existence, file content, branch existence, HEAD position, commit count, commit message patterns, merge commits, conflict state, staging area state, and tag existence. Every keystroke can potentially satisfy an objective, and the UI updates instantly.

Sound effects are procedurally generated with the Web Audio API. No audio files. Just oscillators, frequency envelopes, and square waves. Every commit gets a satisfying chiptune beep. Every merge conflict gets an ominous buzz.

What I Learned Building It

Building an educational game taught me more about git than 15 years of using it.

I had to read the git internals documentation to implement commands correctly. I discovered that git stash is essentially syntactic sugar over a specific commit-and-reset workflow. I learned that the reflog is just a flat file of HEAD movements. I finally understood, at the implementation level, why a detached HEAD happens and what it actually means in terms of refs.

There's a difference between using a tool and understanding it deeply enough to rebuild it. This project forced the second.

The Pixel Art Problem

I can't draw. At all. My artistic ability peaked at stick figures in 1993. But I wanted Gitvana to have a specific aesthetic: 16-bit monastery vibes, cherry blossoms, monks in robes, a cat that judges your commits.

I used PixelLab to generate the sprites. I'd describe what I wanted: "pixel art monk in grey robes, standing, 64x64, side view, retro game style" and iterate until it felt right. The landing page monastery, the mountain progression map, the four monk tiers (grey, brown, blue, golden) were all generated this way.

It's not hand-crafted pixel art. But it has soul. And it's consistent, which matters more than perfection when you're a solo developer trying to ship something.

Why It's Free

Because I built it for fun. That's the honest answer.

I had a problem: I wanted to understand git at the implementation level, not just the "copy this command from Stack Overflow" level. Building a game that teaches it forced me to actually learn it. Selfish motivation, great side effect.

And maybe other people have the same problem. Maybe there's a developer out there who's been using git for five years and still gets nervous when someone says "rebase." If Gitvana helps them, great. If not, I still had a blast building it.

There's no paywall, no signup, no "premium" tier. The source code is on GitHub. It's MIT licensed. Fork it, improve it, translate it, add levels.

Try It

gitvana.pixari.dev

35 levels. Real terminal. Real git. Zero setup.

Start at Act 1. Get to Gitvana. The cat is waiting.

Originally published on pixari.dev

Why Your Team's Docs Are a Strategic Asset (Not an Afterthought)

Raffaele Pizzari — Wed, 01 Apr 2026 22:34:43 +0000

Good documentation is more than just a chore; it's a strategic asset that can transform how your engineering team operates.

Far too often, documentation is viewed as an afterthought, something to be done only when absolutely necessary, or worse, not at all.

But what if we reframed our perspective?

The Hidden Power of Good Documentation

Think of clear, concise documentation not as a task, but as an act of professional kindness.

Kindness to your future self: We've all been there, staring at old code or a system we designed months ago, wondering about a specific decision or implementation detail. Good documentation acts as a reliable memory, saving you hours of head-scratching and reverse-engineering your own work.
Kindness to your teammates: Onboarding new team members can be a time-intensive process. Comprehensive documentation allows them to get up to speed faster, understand existing systems, and contribute effectively without constantly interrupting others for explanations. It empowers them to find answers independently, fostering a more autonomous and efficient team.

Beyond the Basics: Why Documentation is a High-Leverage Activity

When documentation is prioritized and well-executed, it significantly reduces friction within a team. It clarifies processes, defines responsibilities, and provides a single source of truth for critical information. This, in turn, increases individual and team autonomy. Engineers can make informed decisions and solve problems without constant oversight, leading to faster development cycles and fewer roadblocks.

Ultimately, robust documentation forms the bedrock of a maintainable system. It ensures that knowledge isn't siloed in individual minds but is instead shared and accessible, making systems more resilient and easier to evolve. In the grand scheme of engineering activities, creating good documentation is one of the highest-leverage tasks you can perform, yielding disproportionate returns in team efficiency, system stability, and overall project success.

Making Documentation an Asset, Not an Afterthought

So, how can you shift your team's mindset and practice to make documentation an asset? It starts with recognizing its value and integrating it into your workflow, rather than relegating it to an optional, last-minute item.

What are your team's biggest struggles when it comes to documentation, and what strategies have you found most effective in overcoming them?

Originally published on pixari.dev

Why Empathy is a Hard Skill

Raffaele Pizzari — Wed, 01 Apr 2026 22:34:13 +0000

The modern workplace is full of buzzwords, and few are as overused as "empathy." We hear it in every leadership seminar and read about it in every management book. But what does it truly mean to lead with empathy, and how does it translate from a lofty concept into a practical, day-to-day skill.

For many years, I believed that leadership was about competence and results. My focus was on the numbers, the deadlines, and the outputs. I challenged my teams directly, but I often missed the "caring personally" part of the equation. It felt soft, almost like a distraction from the real work. What I eventually learned, often the hard way, is that empathy isn't a distraction, it’s a prerequisite for durable, high-performing teams.

The Problem with Overly Direct Feedback

Many of us were raised on the idea that direct, sometimes harsh, feedback is the only way to drive performance. While challenging people directly is crucial for growth, when it’s delivered without a foundation of empathy, it often lands as criticism. This creates a defensive environment where people shut down, stop taking risks, and fear making mistakes.

This is where the principles of Kim Scott’s "Radical Candor" became a powerful compass for me. The idea is simple: care personally and challenge directly. The two parts are not independent; they are a symbiotic relationship. You can't have one without the other and expect to build a team that thrives. The "caring personally" part is the empathy. It's the engine that makes the "challenging directly" part effective.

Empathy isn't Weakness, It's Leverage

Leading with empathy isn't about being everyone's friend or avoiding tough conversations. It's about taking the time to truly see and hear the people on your team. It means understanding their professional and personal aspirations, recognizing their struggles, and genuinely celebrating their wins. It’s about creating an environment where they feel safe enough to be vulnerable.

When you invest in that foundation of psychological safety, challenging feedback becomes a gift, not a threat. Your team knows that your feedback comes from a place of support for their growth, not a place of judgment. This is the ultimate form of leverage. You can demand excellence and push boundaries because your people trust that you are pushing them for their own benefit.

Practical Ways to Apply Empathy as a Leader

So, how do you make empathy a tangible part of your leadership toolkit? It starts with small, consistent actions:

Listen Actively: Put away your phone and give your full attention. Ask open-ended questions and listen to understand, not just to respond.
Show Vulnerability: Acknowledge your own mistakes. It shows your team that imperfection is normal and creates a safe space for them to do the same.
Recognize Effort, Not Just Results: Celebrate the hard work and resilience, especially when a project doesn't go as planned. This builds trust and encourages risk-taking.
Remember the Person: Ask about their weekend, their family, or their hobbies. These small moments can build a powerful personal connection.

Empathy is not a soft skill; it is a hard, pragmatic skill that directly impacts a team’s performance. It’s the difference between managing a group of individuals and leading a unified, high-performing team.

Originally published on pixari.dev

When the hard part was the point

Raffaele Pizzari — Wed, 01 Apr 2026 22:33:42 +0000

I still remember the weight of the book.

It was 2003. I was building a text search engine in Perl. I was trying to write a recursive function to traverse a directory tree without blowing up the server’s memory.

I didn't have Copilot. I didn't have ChatGPT. I didn't even have StackOverflow open, it didn't exist. I just had a heavy, physical Perl manual with a cracked spine, an open space with many loud colleagues and the hum of the computer fans.

I spent days on that function. I remember the frustration. I remember the panic of staring at a cursor that wouldn't move. But mostly, I remember the texture of the moment the logic finally clicked. It was a physical sensation, a headache dissolving into pure clarity.

For the last 20 years, I have defined my professional worth by my ability to endure that friction. I was a watchmaker, and I took an immense amount of pride in the fact that the gears were incredibly small, the manual was hard to read, and my hands were the only ones steady enough to place them.

And now, I am grieving.

The Robbery

Last weekend, I sat down to work on a personal side project. This wasn't for work; this was for me. I hit a roadblock with a particularly nasty piece of logic involving data synchronization.

A few years ago, this would have been the best part of my Saturday night. It would have been a ritual: a fresh pot of tea, a blank notebook, and three hours of deep work until I cracked the code.

This time, almost out of muscle memory, I pasted the error into a prompt window.

I didn't even get to take a sip of my tea.

Four seconds. That’s how long it took. The code appeared. It handled the edge cases. It was cleaner than what I would have written. I pasted it in. It worked perfectly.

I didn't feel efficient. I felt robbed.

I had robbed myself of the flow state. I had robbed myself of the "Aha!" moment. It was like taking a helicopter to the summit of Everest. Yes, the view is the same. But the person standing at the top isn't the person who climbed the mountain. They haven't been changed by the ascent.

The Identity Crisis

We talk about AI velocity. We talk about "10x engineers." But we aren't talking about the silence that comes after the code is written.

For many of us, engineering wasn't just a trade; it was an identity built on suffering. We were the magicians who knew the secret spells. We were the ones willing to read the documentation at 2 AM.

When the "hard parts" become trivial, when the struggle is removed, it forces us to ask a terrifying question:

If I am not the one struggling, who am I?

If my value isn't in my ability to grind through the logic, and my value isn't in my encyclopedic knowledge of the Perl manual, then what have I been doing for the last 2 decades? Was I just a slow, biological text-generator waiting to be optimized?

The Wisdom of the Scar

But perhaps I am asking the wrong question. Because there is a fundamental difference between an LLM and a Senior Engineer, and it isn't intelligence. It’s trauma.

An AI has never been woken up at 3 AM by a critical production alert. An AI has never felt the cold sweat of realizing a migration script just dropped the wrong table in production. An AI has never had to sit in a post-mortem meeting and explain to a CEO why the site was down for four hours.

That terror? That is where wisdom comes from.

The "friction" we are mourning wasn't just annoying; it was educational. Every time we struggled, we were building a map of the minefield in our heads.

The AI is an eternal optimist. It assumes the happy path will work. It assumes the API will respond. It assumes the data is clean. It has infinite knowledge, but zero scar tissue.

And in our line of work, the scars are the only things that tell you where the ice is too thin to walk.

Where the Friction Lives Now

So, how do we navigate this? If the "writing" is gone, where do we put our obsession?

I’ve realized that we don't have to abandon our standards; we have to elevate them. We need to take that restless energy that used to go into syntax and pour it into verification and architecture.

Become the Editor, Not the Writer: The AI is an eager, hallucinations-prone engineer. Your new struggle is not creating the code, but having the taste to look at 50 lines of generated logic and spot the subtle architectural flaw that will haunt you in six months. The "friction" is now in the review.
Protect Your "Gym" Time: I have made a new rule for myself. Every day I turn the AI "off" for ~50% of my coding time. I force myself to write code by hand. Not because it’s efficient, it isn’t, but because my brain needs the gym. We lift weights not to move iron, but to keep our muscles strong. We must code manually to keep our intuition sharp.
From Photorealism to Impressionism: Photography didn't kill painting. It forced painters to stop trying to be photorealistic. When the camera arrived, painters realized: “The machine can capture the light better than I can. So I must capture the feeling.”

We are at that same juncture. The era of the "Photorealistic Coder", the one who takes pride in memorizing syntax, is over. The era of the Impressionist Engineer is beginning.

Our value is no longer in how we build the wall. Our value is in knowing where to put the window so the light hits the room just right.

The "Good" Struggle

If you are reading this and feeling a twinge of sadness, I want you to know it’s okay.

It’s okay to miss the blinking cursor. It’s okay to miss the frustration of the physical manual. It’s okay to miss the era where the barrier to entry was high, because that height made us feel safe.

We can accept the new tools. We can use the helicopter when the destination is all that matters. But every once in a while, for the sake of our souls, we should still climb the mountain on foot.

I suspect I'm not the only one feeling this phantom limb.

Originally published on pixari.dev

Using AI in the Software Development Lifecycle (Without Slowing Shipping)

Raffaele Pizzari — Wed, 01 Apr 2026 22:33:11 +0000

AI is everywhere in the software development lifecycle: code completion, test generation, docs, and even design. The promise is faster, better output. The risk is typing faster but shipping slower—more generated code to review, more wrong abstractions, and more time debugging AI output. Here’s how to use AI in the software development lifecycle in ways that actually speed you up instead of slowing you down.

Where AI Helps in the SDLC

Scaffolding and boilerplate.

Generating CRUD, config, tests stubs, and repetitive code from a clear spec or prompt is where AI shines. You stay in control of design; AI fills in the tedious parts. Think “build the scaffolding, not the whole house.”

Documentation and comments.

Turning code into docs, or keeping comments in sync with behavior, is a good fit. So is generating runbooks or API descriptions from existing code—as long as someone reviews for accuracy.

Tests and validation.

Generating unit tests, edge cases, or example data can improve coverage quickly. The key is running the tests and fixing failures; don’t trust generated tests without review.

Exploration and learning.

Asking “how does X work in this codebase?” or “what’s the pattern for Y?” can speed onboarding and investigation. Treat answers as a starting point, not gospel.

Refactoring and small, mechanical changes.

Renaming, formatting, or applying a pattern across many files can be suggested or partially done by AI. Again, review and tests are essential.

Where AI Tends to Slow You Down

Big, greenfield features from a single prompt.

AI can produce a lot of code that looks plausible but is wrong, over-engineered, or doesn’t fit your system. You spend more time fixing and aligning than if you’d written a smaller, targeted slice yourself.

Critical paths and subtle logic.

Security, correctness, and performance need human judgment. Use AI to suggest or draft, then verify carefully.

When context is missing.

AI doesn’t know your product decisions, your constraints, or your team’s conventions. The more you provide (specs, examples, ADRs), the better the output—and the more you rely on “just generate it,” the more rework you get.

Practices That Keep Shipping Fast

1. Invest in context AI can use.

Good docs, clear APIs, and up-to-date specs improve AI output and reduce back-and-forth. Treat documentation as the “context window” for both humans and tools.

2. Prefer small, verifiable steps.

Use AI for small units of work (a function, a test, a doc section) that you can review and test immediately. Avoid “generate the whole feature” unless you’re willing to treat it as a draft to heavily edit.

3. Tighten the feedback loop.

Strong test coverage and fast CI mean you catch AI mistakes quickly. Without that, you risk merging broken or brittle code.

4. Set team norms.

Decide what’s acceptable to generate (e.g. tests, boilerplate, comments) and what always needs a human design (e.g. security, APIs, data models). Review generated code like any other code.

5. Measure impact.

Track cycle time, bug rate, and rework. If “AI-assisted” work takes longer or introduces more incidents, adjust where and how you use AI.

Using AI in the Software Development Lifecycle: Summary

Use AI for: scaffolding, boilerplate, docs, test generation, exploration, mechanical refactors.
Be cautious with: large features from one prompt, security/correctness-critical code, and anything where context is vague.
Keep shipping: small steps, strong tests, clear context, and team norms so AI speeds you up instead of burying you in rework.

AI in the SDLC is most valuable when it handles the repetitive, well-defined work and leaves you in control of design and quality. Use it there, and you can ship faster without slowing down.

Originally published on pixari.dev

The Year I Stopped Apologizing for the Chaos

Raffaele Pizzari — Wed, 01 Apr 2026 22:32:40 +0000

Let’s look at the data, because that’s usually where I feel safe.

My oldest is three years old.

My twins turned one just three months ago.

For the last 15 months, I have been attempting to function as a human being while outnumbered by toddlers. I work from home as an engineering manager, a role I am incredibly grateful for, but one that requires a brain that isn’t constantly running on fumes.

If you looked at my calendar this year, you saw neat blocks of meetings and deep work.

If you looked inside my room, you saw a father muting his mic to gently negotiate with a crying toddler, wiping oatmeal off his shirt five minutes before a call, and functioning on a sleep schedule that simply doesn’t add up.

It has been the toughest year of my life.

I love my children more than I thought possible. They are my world. But love doesn’t replace sleep, and deep affection doesn’t pause the backlog.

It is possible to be incredibly grateful for your family and completely broken by the logistics of raising it at the same time.

The Weight We Carry

We need to talk about the guilt. The specific, heavy kind that sits on your chest at 2 AM.

I am lucky. I work for a company that is incredibly empathetic. They support families. They understand flexibility. I am not fighting a toxic employer. I am fighting an internal narrative that tells me I should be able to do it all perfectly.

But let’s be clear: that narrative didn’t appear out of thin air. It was installed by a culture that equates human value with constant output. Even in a supportive environment, the societal pressure remains.

There are days when I close my laptop and feel I didn’t give enough to my team. Then I step away from my desk and feel I didn’t give enough to my kids.

We are constantly told, implicitly or explicitly, that if we just organized our time better, woke up earlier, or had more discipline, we could balance it all.

That is a lie.

We are living through a time where we are expected to work like we don’t have children, and parent like we don’t have jobs. That isn’t a puzzle you can solve if you just try harder. It is simply impossible.

Permission to Be Human

If you are reading this and feeling that same shame, I want to tell you something I wish someone had told me six months ago: You are not wrong.

You are not broken. You are not “bad at this.”

We have been taught that vulnerability is a weakness, that as professionals, and especially as men, we need to present a facade of calm competence. We hide the chaos. We apologize when “life” interrupts the background blur. We treat our exhaustion like a shameful secret.

But the exhaustion isn’t a sign of failure. It is the only logical response to the situation.

The shame you feel? That doesn’t belong to you. That belongs to a culture that demands the impossible and then blames you when you can’t deliver.

We need to stop hiding the cracks in the armor. We need to stop pretending that we are untouched by the chaos. Real strength isn’t about carrying the weight without stumbling; it’s about admitting that the weight is too heavy to carry alone. It is about saying, “I am struggling,” and realizing that this admission doesn’t make you less of a leader,

It makes you human.

The Privilege of Vulnerability

I just argued that we should stop hiding the cracks in our armor. But I need to be honest about why it is safe for me to drop my shield.

I am a white man with a supportive partner, a stable salary, and a company that treats me like a human being. I have every safety net money and social status can buy.

This mountain of privilege doesn’t just buy me safety; it buys me the permission to be human.

When I write about my chaos, I get applauded for my “authenticity.” When I admit to being overwhelmed, I am seen as a “relatable leader.” I can wear my vulnerability like a badge of honor because my competence is rarely questioned.

But I know that for many, especially women and mothers, showing those same cracks isn’t a badge of honor. It’s a professional liability.

Women have been carrying this load (and often a much heavier one) for generations. Yet, when they show the strain, society doesn’t offer them the same “permission slip” it hands to me. It offers judgment. It perceives their exhaustion not as a systemic failure, but as a lack of commitment.

So while I am proud to share my struggle, I am acutely aware that the ability to do so without fear of professional penalty is, in itself, the ultimate privilege.

To the men reading this: We possess the “political capital” to change this narrative, and we have a duty to spend it. We need to be the ones to break the facade. When we say, “I can’t make that 5 PM meeting, I have childcare duties,” we create a blast radius of safety for everyone else who is terrified to ask for what they need.

We have to stop pretending everything is fine just because we are scraping by.

You Are Doing Enough

If you are just surviving right now, you are doing enough. The work will always be there. The deadlines can move. But you, and your family, are the only version that exists.

This season of life is relentless, but it is also finite. Don’t measure your worth by your productivity during a crisis. Measure it by your ability to be kind to yourself when the world demands you be a machine.

We need to stop hiding the scars and start supporting the people. We need to build a culture where “I am tired” is a valid status update, and where asking for help is recognized as an act of courage, not a confession of weakness.

Resilience isn’t about never breaking; it’s about knowing that you shouldn’t have to carry the weight alone.

I am still navigating this myself. I don’t have a roadmap for how to be the perfect parent in this chaos. I am also actively trying to be a better ally to listen to the experiences I don’t share and to speak up when silence would be easier. I’m just trying to draw the map as I go. But I know that navigating it alone is the hardest way to travel.

If this resonated with you, I’d love to hear your story. Whether you want to vent about the impossible schedule, share a small win, or just tell me how you’re keeping the lights on, my inbox is open. We can’t fix the whole system today, but we can start by making sure no one has to debug this mess alone.

Originally published on pixari.dev

The Paradox of AI-Acceleration: Why We Are Typing Faster but Shipping Slower

Raffaele Pizzari — Wed, 01 Apr 2026 22:32:09 +0000

We are deep in the deployment phase of Generative AI.

According to the 2025 Google DORA report, (https://survey.stackoverflow.co/2025/). The hype cycle is officially over. This is now non-negotiable baseline tooling.

The initial promise was exponential efficiency: AI would handle the heavy lifting, freeing us for high-value engineering.

But if you look at actual telemetry from the field, not vendor marketing brochures, but hard data from mature organizations, the dashboard is flashing red.

We are witnessing a profound Paradox of Acceleration. Developers report feeling in the flow, with perceived productivity boosts up to (https://github.blog/news-insights/research/research-quantifying-github-copilots-impact-in-the-enterprise-with-accenture/). Yet, objective telemetry indicates that cycle times, the time from first commit to actual production deployment, (https://devops.com/study-finds-no-devops-productivity-gains-from-generative-ai/).

The Paradox of Accelation in AI-Assisted [Development](/using-ai-in-the-software-development-lifecycle-without-slowing-shipping/)

As engineering leaders, we must stop managing by the "vibe" of instant generation and start managing by the physics of your delivery lifecycle. The law of gravity applies to software: Code is Mass.

AI tools allow your team to generate mass at an industrial scale. But unless you have exponentially increased your structural integrity, your automated testing coverage, your review bandwidth, your observability, you are simply building a heavier tower on the same cracking foundation.

Gravity doesn't care about your roadmap or your quarterly goals. If the load exceeds the capacity, the collapse is not a possibility, it is a mathematical certainty.

The "Vibe Coding" Trap: Shifting the Bottleneck

There is a massive disconnect between the feeling of speed and the reality of engineering outcomes.

Early studies on "greenfield" tasks (https://survey.stackoverflow.co/2025/). This created a dopamine feedback loop. Developers feel productive because the agonizing pause of syntax recall is gone. But professional engineering is rarely greenfield. It is mostly "brownfield", navigating complex, existing dependency trees.

The "Vibe Coding" Trap: Generation vs. Verification

When we look at data for real-world maintenance tasks, the narrative flips. A 2025 study found AI-equipped developers took 1 9% longer to complete complex modification tasks compared to control groups.

Why? Because we shifted the bottleneck.

Old Bottleneck: Typing and syntax recall (Generation).
New Bottleneck: Reading, verifying, and debugging alien logic (Verification).

AI is confident, but frequently wrong. Debugging code you didn't write, which lacks coherent human intent, is exponentially harder than writing it yourself. We are trading cheap typing time for expensive debugging time.

Expectation vs. Reality

Let’s look at the profit & loss of AI adoption. When we compare vendor promises against enterprise telemetry, the deficit becomes clear.

Metric	The Sales Pitch (Vendor/Survey Data)	The Site Reality (Forensic/Telemetry Data)	The Structural Cost
Velocity	+55% Faster ((https://github.blog/2022-09-07-research-quantifying-github-copilots-impact-on-developer-productivity-and-happiness/))	-19% Slower on complex maintenance tasks	Latency Spike: Code sits in review/QA longer due to complexity.
Quality	"More time for deep work"	+41% Bug Rate (https://www.google.com/search?q=https://uplevelteam.com/generative-ai-coding-research-study/)	Rework Loop: Speed in typing is lost to fixing bugs in production.
Maintenance	"Clean, efficient code"	Doubled Code Churn & Collapsed Refactoring (<10%)	Technical Inflation: We are building "Write-Only" legacy systems.
Security	"Secure by design"	55% Pass Rate (https://www.google.com/search?q=https://www.veracode.com/state-of-software-security)	Risk Injection: Automating the introduction of XSS/SQLi vulnerabilities.

Table 1: The divergence between perceived value and engineering outcomes (2024-2025 Data).

Structural Integrity is Collapsing (The Rise of AI Debt)

If we analyze the code itself, the picture gets uglier. We are rapidly accumulating a new toxic asset class: AI Debt.

(https://www.google.com/search?q=https://www.gitclear.com/coding_on_copilot_data_quality_impact_research) on 211 million lines of code reveals that while volume is up, structural health is crashing.

Code Churn has Doubled: Lines of code reverted within two weeks of authorship have doubled against pre-AI baselines. We are generating massive amounts of "throwaway" code that doesn't survive first contact with reality.
Refactoring has Collapsed: The rate of refactored code plummeted from 25% in 2021 to under 10% in 2024. AI models predict the next token based on patterns; they are biased toward repeating existing mistakes rather than abstracting them.
Security Vulnerabilities are Baked In: We are automating the injection of flaws. Recent analysis shows extremely high failure rates for basic issues: 86% failure on XSS and (https://www.google.com/search?q=https://www.veracode.com/state-of-software-security).

We are building bloated, repetitive, insecure systems at record speed.

This isn't an aesthetic issue; it is financial leverage working against your future velocity.

The "Mirror and Multiplier" Effect

Is AI a net negative? No. It is a power tool. Its impact depends entirely on the discipline of the operator.

The critical insight from the (https://cloud.google.com/devops/state-of-devops). AI is not magic pixie dust that fixes broken engineering cultures. It is an amplifier.

The Mirror (Dysfunction): If your organization has chaotic processes, weak testing cultures, and high tolerance for debt, AI will mirror that dysfunction. It helps you generate spaghetti code faster.
The Multiplier (Excellence): If you have strong "wiring", robust CI/CD, high-coverage automated testing, and rigorous standards, AI acts as an accelerator. You have the systemic capacity to catch the AI's mistakes instantly.

The Mirror and Multiplier Effect: Organizational Impact of AI

You cannot buy a tool to bypass the hard work of building a mature engineering culture.

Real-world Case Studies:

Theory is useless without field data. When we look at real-world deployments in 2024–2025, the data confirms the "Mirror Effect": the outcome is determined not by the AI model you buy, but by the organizational wiring you plug it into.

Success stories are not about magic, they are about rigorous structural preparation. Failures are almost always failures of governance.

The WINS: Structural Capacity and Targeted Strikes

Mercado Libre

With 9,000+ developers, they reported a 50% reduction in coding time. How? They didn't just hand out licenses and hope for the best. Their success was predicated on a pre-existing, standardized microservices architecture and strong platform engineering capabilities.

They had the structural capacity to absorb the increased velocity safely. They built the high-speed rail network before buying the bullet train.

Duolingo

Instead of trying to automate complex feature creation, they focused AI on pure toil: regression testing workflows. The result was a 70% reduction in manual testing time, turning hours-long processes into minutes.

This is tactical brilliance. They didn't accelerate code generation (which increases risk), they accelerated verification (which decreases risk). They used AI to tighten the feedback loop, improving overall system stability.

Pinterest didn't aim for speed; they aimed for safety. They executed a measured rollout with internal "Safety" checks and built a custom internal platform to govern AI usage before scaling.

They treated AI like an unproven junior engineer. They built guardrails first. They recognized that without governance, speed is just velocity towards a cliff.

The FAILURES: Abdication of Responsibility

The Replit & Air Canada Effect

The industry has seen predictable failures where human-led processes broke down. Replit highlighted instances where unsupervised AI generation led to "negative productivity." Air Canada faced legal liability when its chatbot hallucinated a policy that the company was forced to honor.

These are not AI failures; they are management failures. "Blind trust" in probabilistic tooling is professional negligence. If you abdicate your responsibility to verify outputs, you deserve the resulting chaos.

Syntax is Commodity, Structure is Leverage

We are exiting the era where syntax was the constraint. Writing code is now a commodity, abundant, cheap, and infinite.

In an economy of infinite syntax, structural judgment is the only scarcity.

The "10x Developer" of the AI era is not the one who generates the most code. It is the one with the discipline to reject the most code. It is the one who understands that every line accepted into the repository is a permanent liability that must be defended against entropy.

The Stabilization Plan

If your team is using AI, you are in production. To prevent the collapse predicted by the data, you must implement a rigorous engineering protocol.

Phase 1: Containment

Treat AI Code as Untrusted User Input: Stop treating Copilot suggestions as "peer code." Treat them with the same hostility you treat an external API payload. Implement an "Air Gap" Policy: No AI-generated code merges to the main branch without passing a dedicated SAST.
Invert Your Metrics Dashboard: Deprecate "Velocity" and "Commit Frequency" as primary KPIs immediately. They are being gamed by inflation.
- Primary Metric: Change Failure Rate. If this rises, AI usage gets throttled.
- Secondary Metric: Code Longevity. Measure how much AI-generated code survives past the 2-week mark. If churn is high, you aren't building features, you're prototyping in production.

Phase 2: Reinforcement

Automated "Refusal to Merge": You cannot scale code generation without scaling automated rejection.
- Property-Based Testing: Unit tests are no longer enough (AI can write passing unit tests for broken code). Implement property-based testing (fuzzing) to bombard the AI’s logic with edge cases it didn't anticipate.
- The "Context Check": Mandate that every PR description includes a "Why" section written by the human, explaining the architectural decision. If the developer cannot explain the intent independent of the syntax, the PR is rejected.
Debt Repayment Quotas: To combat the collapse in refactoring (down to <10%), enforce a "Boy Scout Rule". For every feature PR generated with AI, the developer must include a corresponding refactor or cleanup of an existing module. Tie this to mergeability.

Phase 3: Calibration

The "Senior-to-Junior" Review Ratio: A Senior Engineer can no longer review the same amount of code. The cognitive load of verifying "hallucinated logic" is higher than reviewing human logic.
- Action: Reduce the review load on Seniors by 20% to account for the increased density of AI code. Do not expect them to review faster just because the code was written faster.
Mandatory "Analog Weeks" for Juniors: To prevent the "Knowledge Collapse," institute training periods where Junior engineers must execute tasks without AI assistance. They must prove they understand the memory model and the SQL execution plan before they are allowed to automate it. You cannot automate what you do not understand.

You are not managing a software team anymore; you are managing a nuclear power plant.

The reaction (code generation) is self-sustaining and powerful, but without heavy lead shielding (testing/review) and control rods (governance), it will melt down.

Conclusion

We have officially exited the "Artisan Era" of software development, where code was hand-crafted and scarce. We have entered the Industrial Era, where code is mass-produced and abundant.

In this new reality, the primary danger to your organization is no longer a lack of speed, it is a lack of friction.

Generative AI has removed the friction of writing code, but that friction served a purpose: it gave us time to think. Without it, we are flooding our repositories with "presumed competence", logic that looks correct but has not earned its place in the system.

The engineering teams that survive this transition will not be the ones who generate the most features. They will be the ones who build the best filtration systems.

The mandate is clear:

Stop celebrating volume. A large codebase is just a large surface area for bugs.
Start rewarding skepticism. The most valuable engineer is no longer the fastest typist; it is the one who refuses to merge a pull request because the logic feels "hollow."
Shift from Creation to Curation. Your job is no longer to write the code; your job is to certify that the code is safe to run.

The hype is done, now we have to manage the cleanup.

Stop building faster, start building things that don't fall down.

Originally published on pixari.dev

The Abundance Trap: Why We Are Renting the Future

Raffaele Pizzari — Wed, 01 Apr 2026 22:31:38 +0000

I am a daily practitioner of AI. I build with it, I rely on it, and I am optimistic about its potential to remove drudgery from our work.

But while I am an enthusiast for the technology, I am deeply skeptical of the narrative.

We are told that AI abolishes scarcity. Big Tech sells a vision where intelligence becomes "too cheap to meter", lifting humanity into a post-scarcity utopia.

But if you audit the actual architecture of this economy, you realize that AI does not abolish scarcity. It reorganizes it.

The Anaesthesia of Cheap Content

We are currently witnessing a massive divergence.

• The Output is Free: The marginal cost of generating text, images, and code has collapsed. The world is flooded with synthetic media that looks like "value."

• The Input is Priceless: The infrastructure required to create that value, advanced fabrication, high-bandwidth memory, energy contracts, and specialized talent, is becoming aggressively scarce.

This is the Abundance Trap. The flood of cheap content acts as a political and economic anesthesia. It distracts us with the illusion of "magic" while the ownership class locks down the physics of the system.

We are confusing the faucet with the reservoir.

The New Choke Points

This structure is not a democracy; it is a high-tech caste system disguised as a utility.

In this new stack, power doesn't come from having the best idea; it comes from having the reserved capacity.

Hyperscalers are currently locking in multi-year energy and compute contracts, effectively leaving the rest of the market, startups, researchers, and entire nations in the Global South, bidding for leftovers.

The class division is mechanical:

• The Landlords: Those who own the "physics" (Data Centers, Weights, Energy).

• The Tenants: Those who rent the API endpoints.

If you are just fine-tuning a model on someone else’s infrastructure, you don't have leverage. You have a subscription.

The Atrophy of Human Agency

My deepest worry isn't just about who captures the profit. It is about what this structure does to us as builders.

I talk to engineers every day who feel a strange mix of relief and emptiness. When you solve a complex problem with a single prompt, you feel the rush of velocity, but you lose the texture of the struggle.

This "Rentier Architecture" creates a psychological dependency.

When we build on top of closed, proprietary APIs, we are technically "shipping," but we are losing the Right to Tinker.

We are becoming operators of a machine we are forbidden to understand.

• The Owner (Big Tech) learns from every interaction, deepening their understanding of the world.

• The Tenant (Us) gets the output, but our understanding of the underlying mechanics atrophies.

We are at risk of raising a generation of "Senior Prompt Engineers" who have never looked inside the black box. If we don't demand access to the weights, not just to use them, but to study them, we aren't just losing economic leverage.

We are losing the intellectual dignity of our craft.

We must fight for open systems not just to keep prices low, but to keep our curiosity alive. We need to ensure that the future of intelligence is something we can take apart, fix, and learn from, not just something we subscribe to.

Beyond the "Social Media" Error

We have seen this movie before, but the stakes are higher now.

In the 2010s, we delegated the "Public Square" to private algorithms optimized for engagement. The result was a decade of polarization and a complete loss of control over our information diet.

But AI is more systemic. It doesn't just intermediate communication; it intermediates decision-making. It allocates resources, writes code, and filters reality.

If we allow the governance model of Social Media (shareholder responsibility) to govern Artificial Intelligence, we are setting ourselves up for a catastrophic failure of public trust.

You cannot run the operating system of society on a "move fast and break things" license.

Governance at the Scale of Power

Power this immense cannot be left to self-regulate.

We need to stop treating AI like consumer software and start treating it like nuclear energy or climate infrastructure.

The risks sit at the intersection of security, economics, and fundamental rights.

I am not suggesting we nationalize the code, but we need binding constraints on the entities that build these high-capability systems.

We need oversight on the scale of the United Nations.

• Public Utility Frameworks: We must treat foundational compute access like an essential facility. It cannot be rationed solely by price.

• Independent Audits: We need agencies with the clearance to inspect the "black box", checking for safety and bias before deployment, not apologizing for it after.

• Sovereign Resilience: Nations and civil society need "public options", open infrastructure that ensures research and innovation aren't locked behind a corporate paywall.

Conclusion

If we don't intervene structurally, the default outcome is not a broadly shared future. It is a hierarchy built on a substrate of "free" intelligence, where the benefits accrue strictly to those who own the choke points.

We need to regulate the access before the cement sets. True abundance isn't just about having cheap tokens; it's about having a seat at the table where the weights are set.

Originally published on pixari.dev

Technical Debt: When to Pay It Down vs When to Live With It

Raffaele Pizzari — Wed, 01 Apr 2026 22:31:07 +0000

Technical debt is one of those phrases that gets thrown around whenever code is messy, tests are missing, or a system is hard to change. The default response is often “we need to pay it down.” But not all technical debt needs to be repaid—and treating it that way can burn time and slow delivery without real benefit.

Here’s a practical way to decide: when to pay down technical debt, when to contain it, and when to leave it alone.

What Counts as Technical Debt?

Technical debt is the implied cost of shortcuts: we ship faster today in exchange for more effort or risk later. It shows up as:

Legacy code that’s hard to read or change
Missing or flaky tests that make refactors risky
Outdated dependencies or deprecated APIs
Inconsistent patterns across the codebase
Documentation gaps that force people to reverse-engineer behavior

Some of this is intentional and reasonable; some is accidental. What matters is how you classify and act on it.

A Simple Framework: Impact vs Cost

Before scheduling a “debt sprint,” ask two questions:

1. What is the impact of leaving this debt in place?

Does it block features, cause outages, slow onboarding, or increase bug rate? Or does it mainly annoy engineers who have to work in that area?

2. What is the cost of paying it down?

How much time and risk? Will the refactor touch many call sites? Do we have tests to protect behavior? Is the area stable or changing every sprint?

High impact, reasonable cost → Plan to pay it down. This is the debt that hurts delivery or stability; fixing it usually pays off.
High impact, high cost → Contain first. Add tests, document boundaries, isolate the area so it doesn’t spread. Then chip away or replace in stages.
Low impact, low cost → Fix when you’re already in the area. No big initiative needed.
Low impact, high cost → Leave it. Document it, add a comment or ADR so the next person knows why it’s there, and move on. Spending months “cleaning” code that rarely changes is a poor use of engineering time.

When to Pay Down Technical Debt

Prioritize paying down debt when:

It blocks roadmap work or makes every change in that area slow and risky.
It causes production issues or makes incidents hard to diagnose and fix.
It slows hiring or onboarding because the system is incomprehensible without tribal knowledge.
The cost of change is about to go up (e.g. a dependency is end-of-life, or the team is about to grow and touch this code a lot).

In those cases, allocate time explicitly. Call it “stability,” “foundation,” or “debt paydown”—but get it on the plan and protect it from being dropped when deadlines loom.

When to Live With It (and Document It)

Some debt is in low-traffic, stable areas. Nobody is extending that code; the main risk is someone refactoring it “while they’re there” and breaking something.

For that kind of debt:

Document it. A short ADR or comment: “This is legacy; we’re not refactoring it unless we have a product reason to touch it.”
Contain it. Avoid spreading the same patterns into new code. Use clear boundaries (APIs, modules) so the mess doesn’t leak.
Don’t promise to fix it “someday.” “Someday” rarely comes and creates guilt. Be explicit: “We’re not fixing this now; here’s why.”

That’s not laziness—it’s prioritization. Engineering time is finite; spending it on low-impact cleanup means not spending it on features or high-impact debt.

How to Explain This to Product and Stakeholders

Non-engineers often hear “technical debt” and think “engineers want to rewrite everything.” Frame it in outcomes:

“This debt is slowing feature X and causing incidents; paying it down will reduce risk and speed up the next quarter.”
“This other debt is in code we rarely touch; we’re documenting it and not touching it unless we have a product reason.”

Tie paydown to delivery and stability, not to “clean code” in the abstract. That makes the tradeoff clear and builds trust when you do ask for time to fix the stuff that actually matters.

Technical debt is a tradeoff, not a sin. Use impact and cost to decide when to pay it down, when to contain it, and when to leave it alone—and you’ll ship more and stress less.

Originally published on pixari.dev

Remote and Hybrid Engineering Teams: What Actually Works

Raffaele Pizzari — Wed, 01 Apr 2026 22:30:36 +0000

Remote and hybrid work are here to stay for many engineering teams. The challenge isn’t whether to allow them—it’s how to make them work: stay aligned, collaborate effectively, and ship without burning people out. Here’s what actually works for remote and hybrid engineering teams, from communication and rituals to documentation and trust.

Default to Async, Use Sync When It Pays Off

Async (docs, comments, Slack, email) lets people work in their own time zones and focus without constant interruption. Sync (calls, pairing) is better for alignment, complex design, and relationship-building.

Write things down. Design decisions, meeting notes, and “why we did X” should live in docs and tickets so everyone can catch up without a meeting.
Reserve sync for alignment and collaboration. Use calls for kickoffs, design reviews, retros, and hard conversations—not for status that could be a short written update.
Set expectations. e.g. “We answer Slack within 4 hours in the workday” or “Design docs get a first pass within 24h.” Predictability reduces anxiety and ping-pong.

Rituals That Work Remote and Hybrid

Standups: Short and written or short and on camera. Focus on blockers and priorities, not long stories. Keep them at a time that works for all time zones or rotate.
Planning and refinement: Do them in a shared window with a clear agenda and a doc. Record or take notes so people who couldn’t attend can follow.
Retros: Dedicate time to how the team works. In hybrid, give remote folks equal airtime; use breakout rooms or async “post your thoughts before we discuss” so everyone contributes.
1:1s: Non-negotiable. They’re the main channel for trust and feedback. Keep them consistent and avoid cancelling.

Documentation as the Shared Brain

When people aren’t in the same room, documentation carries context. Invest in:

Onboarding: Where to find things, who owns what, how we work (tools, cadence, norms).
Architecture and ADRs: Why we chose this design; what’s in and out of scope.
Runbooks and ops: How we deploy, how we respond to incidents, who to call.

Keep docs close to the code and update them when things change. Outdated docs destroy trust in all docs.

Inclusion in Hybrid Setups

In hybrid, it’s easy for the “room” to dominate. One remote, all remote: if one person is on video, everyone joins from their own device so nobody is on a screen in the corner. Same for whiteboards: use a shared digital space (Figma, Miro, etc.) so remote participants can see and edit.

Rotate meeting times when you have multiple time zones so the same people aren’t always on late or early calls.

Trust and Outcomes Over Presence

Measure and reward outcomes and collaboration, not “online” time or number of messages. Trust people to deliver; use clear goals, milestones, and demos so progress is visible. Over-surveillance kills trust and doesn’t improve quality.

What Actually Works: A Short Checklist

Default to async; use sync for alignment and complex collaboration.
Write down decisions, context, and process so people can work without constant meetings.
Keep rituals short, predictable, and inclusive (notes, recording, equal voice for remote).
Treat docs as the shared brain; keep them up to date.
In hybrid, “one remote, all remote” and shared digital artifacts.
Judge by outcomes and teamwork, not by presence or activity.

Remote and hybrid engineering teams can ship and stay healthy when you build around async, clear rituals, and documentation—and when you make inclusion and trust explicit. Focus on what actually works, and iterate with the team.

Originally published on pixari.dev