Ownership in the age of AI - Sahil Kolwankar

July 22, 2026 · engineering · ai · leadership

Ownership in the age of AI

AI should be the input to your thinking, never the output - and what that means for how you write, review, and ship code.

If the contents of this post seem obvious to you, then you're already on the right track. Most of what follows isn't news - it's a description of judgment good engineers already exercise, just with sharper stakes now that generating code is nearly free.

I recently became a tech lead. The first real conversation I had with my team was about AI, and it wasn't the conversation they expected.

They expected a policy. Some guardrails, a list of approved tools, maybe a warning. What I actually wanted to talk about was one word, and it took me most of the meeting to get to it.

This is not a post about using less AI

I want to be unambiguous here, because everything else I say will be misread otherwise.

I want us using AI more. Aggressively. For every menial task in the job - the boilerplate, the test scaffolding, the migration you've written four times before, the regex you'll never memorize. If you're hand-writing something a model could have drafted in five seconds, you're not being principled, you're being slow.

The productivity gain is real and I have no interest in litigating it.

But responsibly. And that word is doing more work than it looks like.

The word is ownership

This is the one thing I want you to take away from this:

No matter how much was written by AI, you must be able to defend every decision as your own.

Not "you wrote it." Not "you understand roughly what it does." You can defend it. Someone can push on any line of it and you have an answer, because you thought about it.

That's the whole standard. Everything below is just consequences of it.

The test

There's a simple way to check whether you own something:

Can you defend it without going back to the tool?

When someone questions your pull request, what happens next? Do you answer, because you already thought this through? Or do you paste their question into the model, read what comes back, and paste that at them?

If it's the second one, you didn't do the work. You brokered it. And everyone can tell, including the person asking.

The uncomfortable part is that this test is easy to fail quietly. Nobody catches you. The PR merges. It only surfaces later, when the thing breaks and you're the one who's supposed to know why.

Why this matters more than it used to

A pull request is a request for someone else's time. This is the one people underrate. Shipping code you don't understand doesn't remove the thinking that code needed - it moves that thinking onto your reviewer, and it arrives amplified, because now they have to reconstruct context you already had and threw away.

You didn't save the team an hour. You spent someone else's hour, at a worse exchange rate. Sometimes the whole thing nets out slower.

When code gets cheap, judgment gets expensive. I work in payroll: tax, payments, onboarding, compliance. Customers do not pay us to produce code - code is now close to free. They pay us for knowing that a particular withholding edge case exists, that a particular payment can't be reversed after a particular hour, that a particular "small" schema change breaks a downstream report someone files with a government.

Cheap generation makes that judgment more valuable, not less. But only if you're exercising it. Judgment you've outsourced isn't judgment.

Then there's the learning trap, and it's the one that worries me most. If the tool fixes your bug and you never investigated it, then the next time it breaks, you are back at zero. No memory of the failure mode. No instinct about where to look. You didn't build the thing engineers build over a career: a mental model of a system that misbehaves in specific, learnable ways.

Do that for long enough and every day becomes your first day investigating that bug.

Sophistication is cheap now

AI makes the appearance of expertise free.

Confident tone, precise-sounding vocabulary, structure, length. All of it, instantly, on any topic, at zero cost, whether or not there's anything underneath.

So the signals we used to read as competence have stopped being reliable. A PR title that claims a great deal over a diff that does very little. A design doc that turns out to be the PRD retyped in engineering vocabulary, restating the problem in a more expensive font.

My rule of thumb now: impressive-sounding work that its author can't explain in plain language is a red flag, not a strength. If someone can't drop the register and tell me what it does in ordinary words, that usually means the sophistication was purchased rather than earned.

Never the output

The part people push back on most: don't post AI-generated text in Slack, in PR comments, or in docs. The AI is often right - that was never the issue. The issue is that readers clock it....