DEV Community: Filipe

The Biggest AI Change in Software Delivery Isn’t in the Code

Filipe — Tue, 13 Oct 2026 13:24:00 +0000

Your delivery chain can compress from months to days. Not by generating code faster, but by changing what happens before the coding starts.

The chain
- We need a new checkout flow by Q3.
- Talk to the PM.
- PM needs a spec.
- That's the BA.
- BA needs screens first.
- That's UX.
- UX is mid-sprint.
v- So… Q3?_

Weeks later: engineering grooming. Sometimes months.

The chain existed because translating a fuzzy business idea into something an engineer could build is genuinely hard. Each handoff was a translation. Each translation takes time.

What has changed isn't the need to translate. It's who does it, and how fast.

From months to an afternoon

Your PM can now build a working prototype directly from a strategic idea. Not wireframes. Not a spec document. A working prototype, in hours, using tools like Claude Design.

Users validate the idea before a line of code is written.

Gone: the BA translation layer, the UX handoff, the approval loops. One person with the right tool can now do in an afternoon what the chain took weeks to produce. Your engineers receive something real to look at, to question, to build from.

The demo loop

That prototype goes to a pod of two or three engineers, not a grooming session. The PM walks each pod through it. Edge cases surface. Decisions land in real time.

A ticket follows. No user story - just what came out of that conversation: the edge cases, the decisions, the constraints.

What about everything that doesn't get said in that meeting?

Daily demos close the gap. The pod accepts the ticket won't be fully fleshed out from the start. Every day, they show running code (built since the day before) back to the PM. Feedback comes in. The work adjusts.

The org change nobody plans for

Your PM needs to be a different kind of person now. Not a spec writer or a backlog manager. Someone who can hold a product vision, prototype it in hours, and run a daily feedback loop with your engineers.

The old requirements chain didn't just slow delivery. It distributed accountability so thinly that nobody felt the full weight of a bad decision. The BA owned the spec. UX owned the screens. Engineering owned the build. When something shipped wrong, the gap between those handoffs was always where the blame landed - and where the learning was lost.

When your PM and the pod share a prototype, a daily demo, and a ticket that came out of a real conversation, something shifts. They are accountable for the same outcome. The gap disappears, because there is nowhere left to hand the problem off to.

The engineering manager's job shifts with it. Breaking the team into pods means fewer coordination meetings and fewer half-formed tickets. What appears in their place is harder to manufacture: engineers accountable for understanding what they are building, not just executing what someone else has written. That is a better job. Not easier. Better.

The experiment on my team

I've been running this model with a large team for the past several months. The daily demo cadence is still finding its rhythm. Some engineers rose to the accountability immediately; others are still waiting for someone else to do the discovery for them. That gap is now visible in a way it never was when tickets arrived pre-written.

Pod composition has proved messier than expected. When priorities are clear, the pods hold their shape. When they aren't, we add people, split pods, or run smaller groups than planned. The structure is more fluid than the model suggests.

What none of that messiness has changed is the result. The end-to-end journey from idea to production has compressed from months to days. Not by hiring faster engineers or buying better tooling. By changing what happens before the coding starts.

Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.

TechLeadConf 2026 · GenAI London 2026

Your AI Productivity Number Is Right. So Is Your Team’s.

Filipe — Tue, 06 Oct 2026 13:07:00 +0000

Ask your engineers how much AI has improved their productivity. You'll hear somewhere between fifty and a hundred percent. Transformative. Game-changing. Then ask yourself whether you could stand up in front of your leadership and say the same thing with confidence.

Most engineering managers can't - not yet. The gains feel real, but they're hard to pin down. And that gap between what your team experiences and what you can actually defend is more useful than it might seem.

That gap isn't a measurement failure. It's the most useful signal you have.

The measurement problem

The gains your engineers are reporting aren't exaggeration. They're just measuring the wrong thing.

Ask where AI has actually helped and you'll hear the same answer across most teams: automation tests and boilerplate code. The mechanical layer - the work that needs doing but rarely needs thinking. If a test suite that used to take an hour now takes ten minutes, that's an 83% reduction on that task. That's real.

But it's only half the picture.

Where the saved time actually goes

Laura Tacho at DX puts the industry average at 3.75 hours saved per developer per week. Take that on face value. The question isn't whether the time is being saved. It's where it goes.

The time reclaimed from the mechanical layer doesn't convert directly into new features.

AI-generated code creates its own overhead. PRs arrive faster, which means review pressure arrives faster too - and reviewing code you didn't write, at higher volume, is its own drain on your engineers' attention. Generated output varies in quality. Security and maintainability issues that an experienced engineer would have caught while writing don't always surface until someone else is reviewing.

Meanwhile, the work itself doesn't hold still. A ticket is a snapshot - a fixed description of a feature the Product Manager wrote before anything was built. Once she can see intermediate output, her understanding shifts, and so does the scope, and the time to build the feature increases.

That isn't dysfunction; it's how good product thinking works. The work that exits a sprint rarely resembles the work that entered it.

What to measure - and what to fix

Your delivery metrics give you something defensible for leadership - a number you can stand behind when someone asks what AI is actually delivering. Survey data gives you the signal from inside the work, and the frame to make sense of the gap between the two.

To close that gap, you need to invest in the engineering harnesses that make AI-generated code production-worthy without consuming the time AI just freed up. That means reducing the review burden from agent-generated PRs (better tooling, clearer standards, automated quality gates, and early detection of architecture drift). It means ensuring generated code is maintainable, secure, and consistent with your architecture before it reaches a human reviewer.

Your engineers reporting 50–100% aren't describing where you are. They're describing where you could get to, once the engineering discipline around AI catches up with the adoption of it.

And when you get there, you might find speed wasn't the real prize. Working code earlier means product thinking catches up, requirements shift, and you deliver the right thing. Your delivery metrics won't show that - but your business will feel it. That's the gap worth closing.

Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.

TechLeadConf 2026 · GenAI London 2026

Your Team’s AI Spend Is a Black Box — Even to You

Filipe — Tue, 29 Sep 2026 13:03:00 +0000

“I ran out of tokens.”

“Me too. Can we get more?”

“Sure,” says the business. “Where did they go?”

Silence. Shrugs. Someone mumbles something about refactoring.

That exchange is happening in engineering orgs everywhere right now. You’re under pressure to control the bill, not just explain it — and you can’t control what you can’t see.

We know the total bill. We don’t know which feature it paid for.

That’s not a tooling gap. It’s a visibility gap. And it’s costing you two things at once: a straight answer on return for the spend, and any way to weigh cost against value at all.

Cost and value, side by side

Cost attribution means tagging assistant usage to the piece of work it went into. Not a team. Not a month. A feature, a ticket, one line in a backlog.

It’s the half of the equation nobody has. A rough number exists for engineering time (e.g., person-days x daily $), but it’s never included what the assistant itself cost. What most teams have instead is a dashboard showing total tokens per person, maybe per team, refreshed monthly — useful for a finance conversation about the subscription, useless for putting a cost next to any one feature’s value.

That’s not an oversight. No assistant vendor has much incentive to make their own token spend easy to scrutinise.

Once you have cost attribution, you can finally put the two halves next to each other: this feature cost this much, and here’s what we believed it was worth. Sometimes they’ll agree. Sometimes the gap will be the most useful thing in the room.

From spend to a conversation with product

Here’s where the same data becomes your leverage in the conversation with product.

Two tickets, same sprint. PROJ-118 burned 400,000 tokens and shipped a feature two enterprise customers had asked for by name. PROJ-204 burned 2.6 million (six times the spend) fixing a papercut nobody had complained about.

Without attribution, both look identical in the backlog: five story points each, both “done.” With attribution, they’re not the same at all — one delivered named value cheaply, the other cost six times as much for a fix nobody asked for.

That’s the evidence you bring into the prioritisation conversation yourself: proof this sprint’s “quick win” has a track record of being anything but.

The good news: all of this is already sitting on your engineers’ machines, waiting to be read.

Where the data already lives

A Claude Code session isn’t just recorded somewhere — the session is the transcript. It writes itself to disk as it goes, a plain JSONL file sitting locally on the engineer’s machine: every prompt, every tool call, every token count. Nobody has to switch it on. It’s already happening.

The assistant also fires events at named moments in a session’s life — SessionStart when a session opens, SessionEnd when it closes, and others besides, though those two are all this needs. A hook is what you register to catch one: nothing more exotic than a line in a config file pointing an event at a script of your choosing.

on SessionStart  → run reminder_script
on SessionEnd    → run export_script

That’s the whole mechanism. No agent to install, no proxy to sit in front of the assistant, no changes to how engineers work. You’re reading a file that already exists, at two moments that already happen.

Building it: three pieces, one afternoon

With that in mind, the shape of this is simpler than it sounds. What follows is pseudo-code, meant to build intuition for how the three pieces fit together. If you’d rather start from real code, see the reference repo on GitHub.

1. A feature ID reminder, at SessionStart. Ask for the feature ID the session relates to, and check again a few prompts later if it never showed up:

on session_start:
ask("which ticket is this session for?")
on each prompt:
if prompt_count in [2, 5, 10, 20] and no ticket_id seen yet:
ask_again()

2. An export, at SessionEnd. When the engineer exits Claude Code, it runs whatever script settings.json points it to, passing that script the session's details. Your script's only job is to copy that transcript somewhere durable, off the engineer's machine, without making them wait for it:

on session_end(session_info):
    transcript = session_info.transcript_path
    spawn_background(copy transcript → database)
    return immediately

3. A batch job, run on a schedule. Step 2 only ever pushed raw transcripts into durable storage — nothing has parsed them yet. This job walks every transcript sitting there unprocessed, and turns each one into a single row of metrics in a separate table:

for each raw session not yet in the metrics table:
    tokens = sum_by_type(session.events)
    feature_id = find_ticket_reference(session.raw_text)
    cost = weighted(tokens, session.model)
    duration = session.end_time - session.start_time
    write_row(feature_id, tokens, cost, model, duration)

Token types aren’t priced the same, and neither are models, so weighted() needs both:

weighted(tokens, model):
    ratio = (tokens.input       * 1.0)
          + (tokens.output      * 5.0)
          + (tokens.cache_read  * 0.1)
          + (tokens.cache_write * 1.25)
    return ratio * input_price_per_token(model)

The 1.0 / 5.0 / 0.1 / 1.25 figures come from Claude’s own published per-token rates, normalised against input. That ratio holds roughly steady across the model family. What doesn’t hold is the absolute price — Opus costs several times more per token than Haiku, which is exactly what input_price_per_token(model) corrects for.

What you get, three weeks in
The first few weeks won’t tell you much. Give it time, and patterns surface: which tickets run expensive, which kinds of work quietly cost more than they should.

None of it decides whether a feature was worth building — that call still belongs to you. What changes is that you now have a real number in hand instead of a shrug, to put next to whatever value story the PM was already telling.

The question was never whether you’re spending a lot on tokens. It’s whether you’re spending them on the right things.

Filipe Albero Pomar is an engineering manager and speaker based in London. He writes about AI adoption, engineering leadership, and software delivery. Find him at alpomar.dev.

TechLeadConf 2026 · GenAI London 2026