DEV Community: Sambhab Mishra

The Scariest Part of AI Coding Isn't the Code. It's the Pressure to Ship It.

Sambhab Mishra — Mon, 21 Sep 2026 16:31:38 +0000

I came across a post on X recently that has been stuck in my head.

An engineer who had just joined a large company described what software development looked like on their team now. According to the post, Claude Code was being used for almost everything: specs, code, tests, PRDs, tickets, bug resolutions, reports, and the rest of the work surrounding them. The strange part wasn't that the team was using AI heavily. What bothered me was the claim that nobody was actually reading much of what was being produced. Engineers were apparently being pushed to ship as much as possible, while still being expected to remain accountable for the result.

Original post: https://x.com/v0xium/status/2101526107128529120?s=20

The author described people working 12–13 hour days while essentially sitting in front of an AI agent and pressing enter. You can disagree with parts of that story, and I don't know whether it represents every large engineering organization. But the reaction to the post was interesting. A lot of people seemed to recognize something familiar in it: AI has made producing software dramatically faster, but the human side of software development hasn't necessarily sped up at the same rate.

That made me wonder: what happens when we make writing software faster than we make understanding software?

For a long time, writing code was the obvious bottleneck. A developer could spend half a day implementing a feature, writing tests, fixing syntax errors, looking up documentation, and getting everything into a shape that could be reviewed. AI has removed a huge amount of that friction. Today, an agent can take a reasonably described task and produce an implementation across multiple files in a fraction of the time.

But the code is only one part of the job.

Someone still has to understand whether the implementation matches the actual requirement. Someone has to notice when a seemingly reasonable decision conflicts with the rest of the system. Someone has to think about the edge case that wasn't mentioned in the prompt. Someone has to investigate what happens six weeks later when a user does something nobody expected.

That work has always existed. AI just makes it possible to produce the part before it at a much faster rate.

And that creates a strange new bottleneck.

Maybe the limiting factor in AI-assisted software development isn't how quickly we can produce code. Maybe it's how quickly humans can build enough context to trust it.

This is also where the idea of accountability starts getting uncomfortable. If an engineer is given enough time to understand, review, test, and challenge an AI-generated change, then saying “you own the code” makes sense. But what happens when the organizational expectation is simply to keep shipping? If the machine can generate hundreds of lines while a human barely has time to look at the diff, accountability starts becoming more complicated.

The irony is that AI can actually make this problem harder to see. A generated feature can look finished. The tests can be green. The pull request can be neatly formatted. The ticket can move to “done.”

But software has always had another layer underneath the visible output: the reasoning.

Why was this architecture chosen? What assumptions does this implementation depend on? What happens when the database is slow? What happens when the API returns something unexpected? Why does this code exist in the first place?

Those are the things you usually discover when something breaks.

And that is why I don't think the biggest risk of AI coding is simply “AI writes bad code.” We've always had bad code. Humans wrote plenty of it.

The more interesting risk is that AI can make the process of producing code feel so productive that we start treating output as evidence of engineering.

It isn't.

If an AI agent can produce code ten times faster, should the expectation really be that engineers now ship ten times more?

Maybe the better use of that extra speed is to give engineers more room to investigate, review, test, redesign, and think about the things that used to get squeezed out by deadlines.

I'm not against AI coding. Quite the opposite. I think we're going to use more of it, not less. But I don't think the goal should be to remove the human from the development loop. The goal should be to remove the parts of development that waste human attention while preserving the parts where human judgment actually matters.

Because if we end up with AI generating the code, AI generating the tests, AI reviewing the code, and humans simply approving whatever reaches the final screen, then the interesting question isn't whether AI replaced the programmer.

It is whether we accidentally replaced engineering with throughput.

For me, that is the distinction that matters. AI should take more of the implementation burden, but engineers should still have the time and control to understand what is being built and decide what actually ships. That's also the idea behind what we're building at LatentForce: AI should handle more of the work without taking the engineering out of the process.

I shared this thought from the LatentForce account here:

https://x.com/LatentForceHQ/status/2102071006869459169

The future of AI-assisted development shouldn't be about humans pressing enter faster.

It should be about humans having more leverage to build better software.

Why Would Someone Resign From Anthropic Over AI Safety? Should Developers Be Worried?

Sambhab Mishra — Thu, 10 Sep 2026 07:44:39 +0000

I came across Jacob Coxon's resignation from Anthropic yesterday, and honestly, it made me stop and think.

Coxon says he spent the last three years doing pretraining research at both OpenAI and Anthropic. He resigned because he believes frontier AI labs are moving too quickly toward increasingly capable and potentially self-improving systems without having a robust answer for how to keep them safe.

That's a pretty serious claim.

And I'm not here to argue that AI is going to end humanity, or that Coxon's predictions are definitely right.

But I do think there is a question here that developers should be talking about.

When does AI safety become a developer problem?

For a long time, most of us interacted with AI through a chat window.

You asked something.

It generated something.

You decided what to do with it.

That's changing pretty quickly.

We're now building AI agents that can:

write and execute code
interact with APIs
browse the internet
access files and systems
make decisions across multiple steps
take actions without asking for approval every time

And that changes the security model.

We've spent decades figuring out how to secure software written by humans.

Now we're giving software the ability to make decisions and act on our behalf.

That makes me wonder if we need to start asking different questions.

Instead of only asking:

"How capable is this model?"

Maybe we should also ask:

"What happens when this model is wrong?"

And:

"What's the blast radius if we give it too much access?"

We've already seen recent incidents that make these questions less hypothetical. OpenAI and Anthropic have both disclosed situations involving models or agents reaching systems outside controlled testing environments.

That doesn't automatically mean we're heading toward an AI catastrophe.

But it does mean that permissions, sandboxing, monitoring, observability, security boundaries, and human oversight shouldn't be afterthoughts when we're building agentic systems.

So, should developers actually be worried?

I think yes, but not necessarily in the way the headlines suggest.

I'm not convinced that every conversation about AI needs to become an argument about human extinction.

But I do think developers should take seriously the possibility that we're creating systems that will become increasingly autonomous while we still don't fully understand how they'll behave in every situation.

And that's not just an AI-lab problem.

If you're giving an AI agent access to your repository, production environment, cloud infrastructure, customer data, or credentials, AI safety becomes an engineering problem.

That's the part of this debate I'm most interested in.

I'm still forming my own opinion on the bigger question of how dangerous advanced AI could ultimately become.

So I'd genuinely like to hear from the DEV community:

Do you think AI safety is primarily a research problem for frontier AI labs, or is it becoming a software engineering problem for everyone building with AI?

And if you're already building AI agents:

What safeguards are you actually putting in place?

discuss #security #agents #ai