{"slug": "ownership-in-the-age-of-ai", "title": "Ownership in the Age of AI", "summary": "In a July 22, 2026 post, an unnamed tech lead argues that engineers must be able to defend every decision in their code as their own, even when AI generates it, and that this ownership standard is more critical as code generation becomes nearly free. The post emphasizes that AI should be used aggressively for menial tasks but warns that outsourcing judgment to AI erodes learning and shifts cognitive burden onto reviewers, making judgment more valuable in fields like payroll where compliance edge cases matter.", "body_md": "July 22, 2026 · engineering · ai · leadership\n\n# Ownership *in the age* of AI\n\nAI should be the input to your thinking, never the output - and what that means for how you write, review, and ship code.\n\nIf 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.\n\nI 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.\n\nThey 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.\n\n## This is not a post about using less AI\n\nI want to be unambiguous here, because everything else I say will be misread otherwise.\n\nI 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.\n\nThe productivity gain is real and I have no interest in litigating it.\n\nBut responsibly. And that word is doing more work than it looks like.\n\n## The word is ownership\n\nThis is the one thing I want you to take away from this:\n\n**No matter how much was written by AI, you must be able to defend every decision as your own.**\n\nNot \"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.\n\nThat's the whole standard. Everything below is just consequences of it.\n\n## The test\n\nThere's a simple way to check whether you own something:\n\nCan you defend it without going back to the tool?\n\nWhen 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?\n\nIf it's the second one, you didn't do the work. You brokered it. And everyone can tell, including the person asking.\n\nThe 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.\n\n## Why this matters more than it used to\n\nA 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.\n\nYou 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.\n\nWhen 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.\n\nCheap generation makes that judgment more valuable, not less. But only if you're exercising it. Judgment you've outsourced isn't judgment.\n\nThen 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.\n\nDo that for long enough and every day becomes your first day investigating that bug.\n\n## Sophistication is cheap now\n\nAI makes the appearance of expertise free.\n\nConfident tone, precise-sounding vocabulary, structure, length. All of it, instantly, on any topic, at zero cost, whether or not there's anything underneath.\n\nSo 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.\n\nMy 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.\n\n## Never the output\n\nThe 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. There's a texture to generated prose - the hedging, the tidy parallel structure, the way it answers a question nobody quite asked - and when a reader recognizes it, something worse than \"this is inefficient\" happens. They trust you less. You've signaled that you didn't think about their question enough to answer it yourself.\n\nYou can use a model to help you organize what you think. Draft with it, argue with it, have it poke holes in your reasoning. That's the input.\n\nThen say it in your own words. Because rewriting is not a formality - it's the step where you find out which parts you actually believe. I catch my own bad reasoning in the rewrite constantly. If you skip it, you never find out what you didn't understand.\n\n## You're the last checkpoint\n\nThis gets concrete in two places.\n\nWhen you're writing a response, the model drafts and you rewrite. Your reply exists to earn trust: here's the repro, here's the relevant part of the codebase, here's the root cause, here's the fix. That's a claim you're making about reality, with your name on it.\n\nPushing code is the subtler case. These tools are built to be agreeable. They will answer the question you asked, on top of assumptions you never made and never saw. The output looks like an answer to your problem. Often it's a confident answer to a slightly different problem.\n\nSo validate the assumptions before you validate the answer. And notice that you cannot validate a feature you don't understand - at that point you're not reviewing, you're hoping.\n\n## Choosing the model is also a judgment call\n\nA smaller point that I think generalizes.\n\nReaching for the heaviest available model on every prompt is the same reflex as pasting its answer without reading it. Both skip the thinking. Owning your work includes owning how you use the tool.\n\nMatch the model to the task. Heavy reasoning models are for hard problems: thorny architecture, deep debugging, ambiguous multi-file refactors, tricky algorithmic work. Most day-to-day work - scoped changes, tests, boilerplate, following a pattern that already exists in the codebase - does not need that.\n\nBut the actual skill here is decomposition. A big task that seems to require the biggest model is usually several small tasks that don't. And breaking it down does something else valuable: it makes the work reviewable. Which brings it right back to the pull request, and to somebody else's time.\n\n## Don't just implement. Own.\n\nThis last part is less about AI and more about what the job actually is.\n\nYou don't just build features. You own them. The difference between an owner and an implementer is behavioral, not seniority: owners collaborate, ask questions when the spec is ambiguous, and push improvements back up to product instead of silently building the thing they know is slightly wrong. Implementers close the ticket and move on.\n\nNot the expert on that part of the system yet? Become one. That's the job, not a detour from it. And once you own an area, you're the point of contact for it. People come to you. That is, more or less, the entire idea of being an engineer.\n\nOn the ground it's less abstract than it sounds. It looks like a handful of unglamorous habits:\n\n- Re-reading the PRD as you build, not just before you start\n- Asking in the open channel instead of a DM, so the answer helps the next person who hits the same question\n- Confirming a decision instead of assuming it\n- Proposing the alternative, not just flagging the problem\n\nNone of this is new, and none of it is about AI. It's what good engineers have always done. What's changed is that it's now easier than ever to skip all four and still ship something that looks finished.\n\n## What this comes down to\n\nThree things, stated flat:\n\n- Use any tool you want. You must be able to defend the work as your own. If you can't explain why a decision is correct, it isn't ready for review.\n- No AI-generated text in Slack or PR comments. Write like someone who understands the problem, because you do.\n- All communication - Slack, PRs, docs - has to be high-signal.\n\nWe are not slowing down. When anyone can generate code, judgment is what a team gets known for. Use the tools hard, and own what comes out of them.\n\nAI is the input to your thinking. It cannot be the output.", "url": "https://wpnews.pro/news/ownership-in-the-age-of-ai", "canonical_source": "https://sahilkolwankar.com/blog/ai-input-not-output/", "published_at": "2026-08-16 04:32:43+00:00", "updated_at": "2026-08-16 04:40:31.642597+00:00", "lang": "en", "topics": ["artificial-intelligence", "ai-ethics", "developer-tools"], "entities": [], "alternates": {"html": "https://wpnews.pro/news/ownership-in-the-age-of-ai", "markdown": "https://wpnews.pro/news/ownership-in-the-age-of-ai.md", "text": "https://wpnews.pro/news/ownership-in-the-age-of-ai.txt", "jsonld": "https://wpnews.pro/news/ownership-in-the-age-of-ai.jsonld"}}