Ganesh on builders, agent engineers, and proof of work

In the last year, Ganesh Baskaran’s 250-person product and technology team at Arrivia has been through three or four reorgs. The old specialist titles are gone. You’re an agent engineer inside a vertical (security, say, or a conversion funnel), and you own the problem end to end instead of passing pieces of it to twenty other teams.

That reorganization is the consequence of a view Ganesh has held since the early days of AWS, when he joined as an engineer in a Seattle office with three BD people and five on support. The second Provn Talent Scout webinar was an hour spent explaining the view, and what it means for someone trying to get hired in 2026.

“AI is just a tool in your toolbox. If you’re not using it today, you’re going to fall behind more.”

The toolbox

Ganesh had a front-row seat for the cloud migration. He watched companies and engineers on both sides of the question. Fifteen years later, history settled it.

“That transition is going to happen over the next 5 to 10 years with AI. It’s just going to completely change the way we work and the way we build software.”

On his team, it already has. But there’s a caveat that matters.

“Don’t use AI for the sake of using it. Agent solutions are not really good today at the creative, ambiguous parts of the work. Where the ambiguity is resolved and there is a clear plan, you delegate to the agent.”

The builders he values catch when AI creates what he calls “a sexy, more complicated solution” that isn’t necessary. They push back and simplify. Fluency in AI is not the same as deference to it.

What a builder is

The clearest thing Ganesh said about what a builder is came out when he talked about his garden.

“I built raised beds for my garden. I didn’t go ask somebody to do the design for me, somebody to cut the wood, somebody to put everything together, somebody to fill the soil. I figured out how to do it end to end and put it out there and started growing vegetables.”

Apply that in software and you have his working definition. A builder takes something ambiguous (a problem statement, a customer pain) and gets it to a working V1 with proof. They make high-judgment, high-velocity decisions at each step. If they’re wrong, they admit it, and they keep iterating. In his framing, an agent engineer is just a builder doing this in software with AI tools. The two words are close to interchangeable.

What distinguishes them is the stage. A builder takes V0 to V1, resolving ambiguity and proving the hypothesis. An agent engineer scales that V1 for production, hardening the pipelines and putting proper logging and monitoring in place. In a traditional org, the scaling used to take fifty people. On his team, it’s one person with an agent.

How you prove you’re one

Résumés are largely written by AI now. So are cover letters. That puts Ganesh in a position a lot of hiring managers are in right now, which is not knowing who is real.

His answer is a concept he borrowed from the blockchain world. Proof of work.

“You can either pick a problem you solved yourself, or take a problem statement from us and go solve it. Come and demo it. We don’t expect it to be perfect. We don’t expect you to spend weeks on it. We want to see if you can use the right tools and solve the problem in a good way.”

The demo runs an hour or ninety minutes. What his team is listening for, on their side, is specific.

An agent that works the night shift

Ganesh told one story that captures what an agent engineer actually does. One of his engineers was watching a familiar production pattern: code ships, errors spike, conversion and bookings drop with them. Instead of writing a stricter quality gate, she wrote an agent. It runs overnight, detects anomalies against historical trends, correlates error spikes with conversion drops, traces the bad code, and opens a PR with the fix.

“When she wakes up in the morning, she has a bunch of PRs she can review and say, okay, check, check, check, not check. And then that gets pushed into production.”

One person, overnight, with an agent. That used to take an on-call rotation.

Curious and resilient

Toward the end of the hour, Niki asked Ganesh to finish a sentence. The engineer I’d hire tomorrow is someone who…

“Curious and resilient.”

Twelve minutes later, Forrest Corbett, who runs product experience at Arrivia, used the same two words when asked what he looks for in a designer. It’s the working language of how Arrivia thinks about hiring.

What makes those two words specific rather than generic is what Ganesh packs into them. Curious, for him, means two things that reinforce each other. The first is the mindset that AI today is better than AI last week, so if something didn’t work for you a week ago you try it again and don’t hold it against the tools. The second is the habit of questioning the model, asking why it solved a problem one way and not another, and pushing back when its solution is more complicated than it needs to be.

Resilient is what sits underneath all of that. The builders who thrive on his team keep updating their workflows as the models improve, and they can ship a bad first attempt one week and a better second the next without getting cynical about it.

His parting words were short.

“Technology is evolving faster than you think. Something that didn’t work last week may work this week. Don’t give up.”