The other 11% took the most thought: pricing, product taste, killing an idea I'd argued myself into, and the paperwork. AI contributed nothing there, on purpose.

That's the pattern I keep seeing, in my own builds and in every SDLC playbook I read this autumn. The work didn't disappear. It moved upstream, into product craft.

When building is cheap, a vague idea gets built anyway. Fast. So the scarce skills change:
→ framing a problem well enough to know what not to build
→ writing a spec an agent can execute without guessing
→ judging output faster than it arrives
→ measuring outcomes instead of counting output

This is why I think the product lifecycle, not the software lifecycle, becomes the real constraint. Product people who mostly coordinated will feel it first. Those who can grill an idea, write the spec and judge the result will have more leverage than ever.

Fewer hands on the keyboard. A much higher bar for craft.

Part 3 of 3.

Which product skill are you investing in for the next two years?

The whole series, open source:
Part 1, four SDLC playbooks compared: https://github.com/jintomjose/ai-native-sdlc-playbooks
Part 2, my mini software factory: https://github.com/jintomjose/mini-software-factory

P.S. The chart is illustrative, drawn from my own builds, not a study.

That came from my habit-tracker app, built mostly by a coding agent. But the agent was only one station. What made it work was the loop around it. At AI Engineer Paris last month, people kept calling that loop a software factory.

Mine is small: one person, nine stations.

An idea gets grilled before it becomes an intent file. Then a spec, then a plan I approve before any code is written. The agent builds with a CLAUDE.md that remembers its past mistakes, and with hooks that block what must never happen. A separate agent verifies the work, another reviews it, and I approve. Incidents become the next intent.

The line I heard most in Paris: "Everyone has agents. Nobody has orchestration."

The factory is the orchestration.

I've open-sourced my setup as a template you can drop into a repo: skills, hooks, subagents, the templates and one worked example.

One honest caveat: 3 days against 6 sprints is calendar time against a plan, not a lab experiment. The method is open too.

Part 2 of 3.

Where does work pile up in your delivery chain now that code is fast?

The template: https://github.com/jintomjose/mini-software-factory
How I measure delivery against the plan: https://github.com/jintomjose/agentic-benchmarks
Part 1, the research behind it: https://github.com/jintomjose/ai-native-sdlc-playbooks
My Paris notes: https://github.com/jintomjose/AI-Engineer-Paris-2026

I read them side by side.

They agree on more than I expected. Writing code is no longer the bottleneck. Review is. And the quality of the context you give an agent matters more than which model you pick.

Where they split is more useful. Should the source of truth live in the repo or in a platform graph? One standard agent tool, or many? Hard blocking guardrails, or alerts that keep experiments alive?

Those are three decisions every organisation will have to make on purpose.

What surprised me most: none of the four publishes a methodology behind its numbers. Shopify's engineering head has even said publicly that its 20% productivity figure was his own rough estimate.

So I put my notes, the full comparison and a 16-point self-assessment in an open repo. The short version is a 9-page carousel.

Part 1 of 3. Next: what a software factory looks like when you build one yourself.

Which of the three decisions would be hardest where you work?

Originally a carousel on LinkedIn — see the original, or download the PDF.

The research, open for anyone to use:
📊 Scrollable visual: https://jintomjose.github.io/ai-native-sdlc-playbooks/
📚 Repo with full notes and the self-assessment: https://github.com/jintomjose/ai-native-sdlc-playbooks

Original sources:
Anthropic: https://claude.com/blog/the-ai-native-sdlc-playbook
Atlassian: https://www.atlassian.com/blog/ai-at-work/ai-sdlc-transformation-playbook
Google Cloud: https://cloud.google.com/use-cases/ai-sdlc
Shopify (Bessemer): https://www.bvp.com/atlas/inside-shopifys-ai-first-engineering-playbook

My own reading, not my employer's view.

I spent two days at AI Engineer Paris, hosted by Mistral, in rooms full of people who build with AI every day. I left with fewer answers than I expected, but with one idea that kept coming back in almost every talk:

AI agents are becoming our users, our buyers and our workforce.

If that is true, we have to design for them, feed them great context, and govern them. Everything I heard falls into four shifts.

1. Customer: agents are the new users

Chart shown in the Stripe talk at AI Engineer Paris

We already design for three personas: the user (UX), the customer (CX) and the developer (DevX). Paris added a fourth: Agent Experience (AX).

One line stuck with me: most billing documents are now read by AI agents, not humans. If machines are your main readers, your content, your APIs and your docs need to be written for them.

And agents are not just reading. They are starting to buy things. They are beginning to initiate payments. The rules for an agent-payments economy have not been written yet. That is an open field.

2. Build: agents are only as good as their context

Three lessons came up again and again:

• Context is everything. An agent is only as good as the context it gets. Guardrailed environments keep it on track.
• Great data is critical. Without it, AI slop grows, and slop is rising everywhere.
• Specialists beat generalists. One agent for every speciality does not work. Build specialised agents per domain on a common core.

One main-stage slide was titled "A slop grenade fight". The line that went with it summed up where many teams are:

Everyone has agents. Nobody has orchestration.

3. Control: agent sprawl is real

If I had to name the hottest topic in Paris, it was agent observability.

Companies are building so many agents that many no longer know what those agents are doing, or where. The answer people kept coming back to was simple to say and hard to do: track every agent and all of its work, and run agents inside environments with guardrails.

We spent the last decade learning to observe our software. Now we have to learn to observe our workforce of agents.

4. Market: models converge, pricing moves to outcomes

• Models converge. Frontier models ship similar tools within days of each other. And sovereign AI is a real option, not just a slogan.
• Everyone builds infra. Software factories are rising, and big players are swallowing smaller ones. People called it "Pac-Man".
• Credits are the new currency. Pricing is moving from consumption, to workflow, to outcome.

Slide: Stripe, AI monetization workshop, AI Engineer Paris

The Stripe workshop made this concrete with three ways to price AI:

• Consumption-based: bill for technical resources (per token, per API call, per compute time).
• Workflow-based: bill for completed tasks (per image generated, per document summarised).
• Outcome-based: bill for business results (per candidate hired, per qualified lead).

Their tip: translate value into credits. Bundle features into a currency and let users buy what matters most.

We have been here before

Computers took about a decade to show up in productivity numbers. The unlock did not come from the machines. It came from software, skills, processes and organisational capital catching up.

My take: AI will follow the same arc. The technology is ahead. The organisations are not, yet.

The takeaway

The model is becoming a commodity. The advantage is context, data and discipline.

That is what I am taking home from Paris.

Which of these four shifts do you see showing up first where you work?

I write about agentic coding, AI-native ways of working and the speed of learning. Follow along if that is your thing.

The carousel version is on LinkedIn.

A strategy team from a bank, in a hall full of engineers, researchers and builders. That used to feel like the wrong room. Not anymore.

Great to talk with Matt Pocock (AI Hero) about knowledge spaces and ontology, and briefly about his /grill-me skill, which I use more than almost any other.

I'm leaving with lots of learnings. Sharing them next week.

Most teams treat prioritisation like a meeting.

They schedule it, run a scoring exercise, produce a ranked list — and then don't revisit it until something breaks. The backlog grows. The roadmap drifts. By the time the next prioritisation session happens, half the context has changed and nobody quite remembers why item 7 ever made the top 10.

In product-led growth, this is expensive. Every misaligned bet doesn't just waste a sprint — it slows activation, stalls retention, and delays revenue. In PLG, the product is the growth engine. A bad priority call isn't a planning problem. It's a business problem.

The real issue isn't the framework. It's the frequency.

01 · Outcomes over output

Ask what changes, not what ships.

Output is a proxy. What the team actually gets paid for is the behaviour or metric that changes as a result — an activation rate that moves, a drop in customer effort, an expansion trigger that fires. Shipping is the means. The outcome is the point.

Before ranking anything on your backlog, name the outcome each item is meant to move. Activation. Retention. Expansion. Operational efficiency. If an item can't name its outcome clearly, it goes to the bottom — no exceptions, no "we'll figure it out in planning."

This one discipline alone changes how backlog conversations happen. Suddenly the debate isn't about what's technically feasible or which stakeholder asked first. It's about which outcome matters most right now — and whether this item actually moves it.

02 · Cut ruthlessly

Fewer bets, made on purpose.

A roadmap with forty items is a roadmap with no priorities.

When everything is a priority, nothing is. The team spreads across too many threads, context-switches constantly, and delivers everything slowly rather than the right things fast. In PLG especially, where the feedback loop between product and growth is tight, diffused effort is the enemy.

Cutting isn't failure. Cutting is the decision.

The hardest part isn't identifying what to cut — most teams know what's low-value if they're honest. The hard part is saying no visibly and early, before work has started and sunk costs accumulate. A quiet no just becomes a slow yes. And a slow yes is the most expensive form of prioritisation.

Protect your team's capacity for the bets that actually matter. The discipline to say fewer things means you can say them fully.

03 · Make it a habit

Build the muscle, not the moment.

A framework used once is a slide. Used every cycle, it's a habit.

This is the part most teams skip. They run a prioritisation session, feel good about the outcome, and then let the ranked list gather dust until the next quarterly planning cycle — by which point the market has shifted, customer data has accumulated, and the "top priority" from three months ago is no longer the right call.

The fix isn't a better framework. It's a fixed cadence.

Revisit priorities on a rhythm — not only when a crisis forces the conversation. Make the criteria visible enough that the team can apply them without you in the room. When prioritisation is a shared habit rather than a leader's decision, the organisation gets faster and more aligned at the same time.

That's the goal: a team that doesn't need a meeting to know what matters most.

The leadership line

Here's what I keep coming back to after facilitating sessions like this:

Prioritisation is not a skill you learn once and apply. It's a habit you build deliberately — in how you run planning, in how you push back on stakeholders, in how you create space for the team to make good calls independently.

The three lenses — outcome over output, ruthless cutting, fixed cadence — aren't a checklist. They're a posture. Applied consistently, they change how a product team thinks, not just what it builds next.

Every yes is a no to something else, including the growth lever you didn't fund. Make your yes count.

I facilitated a live breakout session on this at a Product Management community event, with product owners, leads, and tech leads working through a five-item backlog ranking exercise against these three lenses. The conversation in the room confirmed what I've seen repeatedly: most teams know what the right priorities are. They just need the discipline — and the habit — to act on them consistently.

What's the one item on your current backlog that everyone privately knows shouldn't be there?

And for most of that career, there was always a missing piece — we could collect it, store it, model it. But turning it into something useful, quickly, for real people? That always felt one step away.

GenAI changed that equation.

Here's my timeline:

→ 2022 — ChatGPT hits. Everyone's talking about it.
→ 2024 — Agentic AI becomes the new buzzword.
→ 2025 — I hear the term "vibe coding" for the first time.

The reaction in most rooms: smirks. Skepticism. That's not real engineering.

My reaction: this is my way back in.

I haven't written production code in years. My role doesn't allow it. But I used to from C++ on a Pentium 4 to ETL pipelines until 7 years back. That feeling never left.

Andrej Karpathy's framing of vibe coding gave me permission to play again.

I started with Base44 around summer 2025. No grand plan. Just curiosity and my oldest habit: obsessing over productivity. I wanted to build a simple habit tracker — something to keep my top 3 goals visible every day.

What came out was Momentum.

Rough at first. Then better. I used it through the entire build process. I still use it now.
👉 https://lnkd.in/ev8aHEHM

Back in summer 2025 I didn't even know Claude existed. (Yes, living under a rock.)

But that small build unlocked something bigger. What I understood — slowly, then all at once — is that software is entering a genuinely new era. Not hype. A structural shift in who gets to build, and how fast.

That energy from writing my first loop in C++? It's back. Louder than before.

This is the first post in a series on what I've been building, learning, and where I think this is all heading.

If you're a product person, a data person, or someone who used to build things and stopped —

This one's for you.