Category Archives: Tech Musings

Don’t Stop Using AI (less of an argument and more of a plea)

Featured

Posted on by
Reply

A writer recently published an op-ed. It’s less of an argument and more of a plea. He asks that you never use AI to help you write.

Never let AI write for you – whether it’s school assignments, emails to colleagues or friends, an opening hook. Avoid doing any of this because you might actually learn to write better than the AI can. Writing with AI is problematic because it weakens us mentally, he argues. And as it becomes more pervasive, AI damages not only our individual capacity to create, but also our collective ability to explain, to innovate.

Well, I also get frustrated when I read “AI Slop.” But there is a huge difference between that and refusing to use AI altogether.

Do you use a calculator to do math? Personally, I rarely do. I have strong math skills and can calculate quickly in my head, so I’ve never really needed one. Does that mean you shouldn’t use a calculator because it “mentally weakens” you? Of course not. If a calculator complements your abilities and helps you move forward to complete your task, then go ahead and use it with confidence.


I’ve always envied people who can paint with a brush and bring their imagination to paper. The same goes for gifted musicians. People are born with a specific set of skills, and they can only develop them up to a certain point. That’s just reality – not everyone will become a talented writer, even if they take writing workshops and read constantly.

Some people struggle to draft an email. Some write messages that aren’t clear enough. Some don’t know how to finish a thought, while others thrive if you just give them a rough draft to polish. All these people can, and should, use AI. Just like the calculator, it helps them bridge a gap where they are less skilled.


Will relying on AI prevent them from ever developing that skill? Maybe. But let’s be honest: we all have weaknesses, and most of them don’t magically improve over time. Historically, we just avoided them. Can’t write? I just won’t write. Can’t paint or play an instrument? I’ll express myself another way.

But today, AI can help you – help you write, assuming you have an idea and the ability to edit and refine the text until it truly represents you. Help you create images, visuals you could never draw myself, but could clearly see in your mind’s eye. And music? I enjoy using AI to bring to life the sounds I hear in my head but lack the technical skill to produce.


So here is my statement, which is also less of an argument and more of a plea:
Don’t let AI do your job for you. If you let it do the thinking, writing, and editing while all you do is copy-paste, then don’t. But absolutely use it as a tool—as a force multiplier, as an engine. Use it especially where it can help you overcome fear, push past your limitations, beat your weaknesses, and become better at what you do.

* This post was written with the help of AI

The 10x Trap

Featured

Posted on by
Reply

A post written by Meenakshi Tripathy reminded me of an old Meta motto: you shouldn’t confuse speed with progress.

Personally I’m less concerned about PMs writing code to production. Because PMs should, and will, focus on orchestration. I worry about Engineers writing 10x more code, because, well, they can. And are also, in 2026, expected to.

We’ve all seen the demos. An agent spins up a plan, touches 15 files, and hands you a completed feature in 45 seconds. It feels like 10x. But in a high-scale environment 10x speed without 10x rigor is just 10x gap.

“Speed is the form of ecstasy the technical revolution has bestowed on man. As opposed to a motorcyclist, the runner is always present in his body, forever required to think about his blisters, his exhaustion; when he runs he feels his weight, his age, more conscious than ever of himself and of his time of life. This all changes when man delegates the faculty of speed to a machine: from then on, his own body is outside the process, and he gives over to a speed that is noncorporeal, nonmaterial, pure speed, speed itself, ecstasy speed.”
– Milan Kundera, Slowness.

As we move from “Copilots” to “Agents” we are hitting a friction point where our traditional safeguards are buckling. Here is where the real challenge lives IMHO:

1. The “Diff Review” Fatigue
When a human writes a 20-file diff, they can explain every line. When an agent does it, the human reviewer (and the author!) often defaults to “vibe checking”. If the logic looks sound and the tests pass, we ship. But “looks sound” is how subtle architectural drift happens. We risk becoming “Code Janitors”, only cleaning up the obvious mess while missing the underlying rot.

2. Testing vs. Verification
Agents are great at writing tests that pass. They are less great at knowing if they are testing the right thing. At our scale, “it works” isn’t the bar; “it doesn’t break a downstream dependency three layers away” is. Agents often optimize for the local task but lack the global context of our massive infra.

3. The Experimentation Blindspot
In a culture driven by A/B testing and stats, agents often miss the “why”. They can implement a feature, but can they reason about the long-term impact on a specific metric or the edge cases of a complex rollout? We risk shipping features that are technically correct but strategically hollow.

4. The Standard is the Ceiling
A “high standard” isn’t a checklist; it’s a culture of craftsmanship. If we outsource the thinking to agents, we lose the “why” behind our best practices. The risk isn’t just bad code – it’s the atrophy of engineering intuition.

5. Speed Breeds Silos
When an engineer’s output becomes “agent-accelerated”, a dangerous velocity gap opens up between the code and the rest of the team:
i. Engineer-to-Engineer Silos: If I can prompt a complex refactor in an hour, my teammates – who are still managing their own workloads – no longer have the bandwidth to truly understand my changes. We stop being a cohesive team and start becoming a collection of “solo-operators” who happen to share a repository.
ii. The XFN Black Box: Product Managers, Designers and Data Scientists rely on the “friction” of the development process to provide input. When the time from Idea to Diff shrinks to near zero, we bypass the critical “Wait, should we even do this?” conversations.
iii. Technical Isolation: In the rush to ship, we stop documenting the why. If an agent generates the solution, the engineer might not fully internalize the tradeoffs, making it nearly impossible to explain the technical debt to a PM or a successor six months down the line.

We aren’t just moving faster; we’re moving away from each other. High velocity without high communication turns “collaboration” into “notification”.

So what is the path forward? I think we should use the time saved by agents to focus on these principles:
1. Review for Intent: Don’t just check if the code runs; check if the agent understood the system.
2. Deliberate Friction: Over-communicate with XFN. 10x coding requires 10x alignment.
3. The “Janitor” Rule: If you wouldn’t have written it that way yourself, don’t let the agent ship it.

Speed is a vanity metric. In the race to increase speed, rigor and impact, we should stay present and conscious. Because quality and collaboration are what keeps us going in this long-distance race.