Skip to main content

Let’s talk

Pini Shvartsman
Author
Pini Shvartsman
I lead AI transformation for a global SaaS platform — an entire engineering org adapting to a world where AI performs much of the execution and humans stay accountable for the outcome. I build the systems that investigate bugs, write and review code, validate changes, and automate operations. Before that: employee #5 — built the CI/CD, the infrastructure, the offshore team, all of it. I write the production-grounded takes most AI coverage is too polite to publish.
Table of Contents

I lead AI transformation for a global SaaS platform — autonomous systems that investigate bugs, write and review code, and run operational workflows, with humans owning the outcome. I write about it here, in the field notes.

The writing goes one way. This page is the other direction.

Most of what I know I learned by getting it wrong first: in production, with real engineers, on a real roadmap. If you’re somewhere in the middle of the same transition, I’d rather compare notes than watch you rediscover it the expensive way.

What people usually want to talk about
#

  • Review gates and governance that survive AI speed. What actually holds when agents open forty PRs a week, and what quietly stops being read.
  • Growing senior engineers when agents write the first 80%. The apprenticeship path everyone assumed was permanent, and what has to replace it.
  • Putting agents on the org chart. Roles, KPIs, owners, escalation paths — the boring structure that turns a pilot into infrastructure.
  • Velocity versus quality in AI-heavy teams. Which metrics stop meaning anything the moment agents are in the loop, and what you watch instead.
  • Where adoption stalls after the pilot. It’s almost never the tooling. It’s usually review, trust, or ownership.
  • Shipping with three humans and a fleet of agents. What that actually takes, and which architectural calls are expensive to reverse later.
  • The uncomfortable ones. What didn’t work, what we rolled back, what I’d do differently.

If yours isn’t on that list, it probably still belongs here.

How these usually go
#

A call. Sometimes one, sometimes a running conversation over a few months. You bring the thing you’re stuck on. I ask hard questions, push back on assumptions, and tell you where I’ve already made the mistake you’re about to make. I don’t show up with a deck.

Sometimes it stays a conversation. Sometimes a team wants to go deeper — a workshop, an honest look at how review works today, a session with the leadership group. We figure that out if it comes up.

Who ends up here
#

Engineering leaders at growing SaaS companies and B2B platforms. Founders building AI-first from zero. People running twenty-plus engineers through this transition, or trying to ship like twenty with three and an agent fleet.

Serious operators with real constraints. Not people looking for prompt tips.

I keep it to a few conversations at a time, because I still have a day job and these deserve actual attention.

Talks and sessions
#

I also come speak — to teams, to leadership groups, to internal AMAs, at conferences.

Companies bring in someone from outside to tell their engineers what’s really happening in the threat landscape. I do the same for AI in engineering: an unvarnished look at what it actually does, and where it’s quietly breaking, inside production engineering orgs. Remote or in person.

Reach me
#

LinkedIn is fastest. Or [email protected].

Tell me what you’re working on, what you’ve tried, and what isn’t holding. That’s enough to start.