Automation speeds your work, but does it quietly dull your judgment?Been thinking about this a lot lately after reading a few posts here about people noticing their skills slipping after leaning too hard on AI tools. There's a real tension between using automation to move faster and actually staying sharp enough to catch when something goes wrong. Like, automated data cleaning and dashboarding is genuinely useful, but if you're never doing, that work yourself anymore, you lose the instinct for spotting weird distributions or dodgy groupbys. There was a piece from MIT SMR recently that made a decent point that augmentation tends to win over straight replacement in the, long run, partly because the humans who stay engaged are the ones who can actually intervene when the model quietly does something dumb. And with agentic AI workflows becoming more of a baseline expectation in 2026, that intervention skill matters even, more since these pipelines are longer, more autonomous, and way harder to audit when something quietly goes sideways. The part that gets me is the deskilling risk nobody really talks about honestly. It's easy to frame everything as augmentation when really the junior work just disappears and, the oversight expectation quietly shifts to people who are also spending less time in the weeds. The ethical question isn't just about job numbers, it's about whether the people left are, actually equipped to catch failures in automated pipelines or whether we're just hoping they are. Curious if others have noticed their own instincts getting duller after relying on AI tools for, a while, or whether you've found ways to keep that hands-on feel even in mostly automated workflows.
submitted by /u/taisferour
[link] [comments]
When product managers ship code, the org chart becomes a suggestion.Last week, one of our product managers (PMs) built and shipped a feature. Not spec'd it. Not filed a ticket for it. Built it, tested it, and shipped it to production. In a day.
A few days earlier, our designer noticed that the visual appearance of our IDE plugins had drifted from the design system. In the old world, that meant screenshots, a JIRA ticket, a conversation to explain the intent, and a sprint slot. Instead, he opened an agent, adjusted the layout himself, experimented, iterated, and tuned in real time, then pushed the fix. The person with the strongest design intuition fixed the design directly. No translation layer required.
None of this is new in theory. Vibe coding opened the gates of software creation to millions. That was aspiration. When I shared the data on how our engineers doubled throughput, shifted from coding to validation, brought design upfront for rapid experimentation, it was still an engineering story. What changed is that the theory became practice. Here's how it actually played out.
The bottleneck moved
When we went AI-first in 2025, implementation cost collapsed. Agents took over scaffolding, tests, and the repetitive glue code that used to eat half the sprint. Cycle times dropped from weeks to days, from days to hours. Engineers started thinking less in files and functions and more in architecture, constraints, and execution plans.
But once engineering capacity stopped being the bottleneck, we noticed something: Decision velocity was. All the coordination mechanisms we'd built to protect engineering time (specs, tickets, handoffs, backlog grooming) were now the slowest part of the system. We were optimizing for a constraint that no longer existed.
What happens when building is cheaper than coordination
We started asking a different question: What would it look like if the people closest to the intent could ship the software directly?
PMs already think in specifications. Designers already define structure, layout, and behavior. They don't think in syntax. They think in outcomes. When the cost of turning intent into working software dropped far enough, these roles didn't need to "learn to code." The cost of implementation simply fell to their level.
I asked one of our PMs, Dmitry, to describe what changed from his perspective. He told me: "While agents are generating tasks in Zenflow, there's a few minutes of idle time. Just dead air. I wanted to build a small game, something to interact with while you wait."
If you've ever run a product team, you know this kind of idea. It doesn't move a KPI. It's impossible to justify in a prioritization meeting. It gets deferred forever. But it adds personality. It makes the product feel like someone cared about the small details. These are exactly the things that get optimized out of every backlog grooming session, and exactly the things users remember.
He built it in a day.
In the past, that idea would have died in a prioritization spreadsheet. Not because it was bad, but because the cost of implementation made it irrational to pursue. When that cost drops to near zero, the calculus changes completely.
Shipping became cheaper than explaining
As more people started building directly, entire layers of process quietly vanished. Fewer tickets. Fewer handoffs. Fewer "can you explain what you mean by..." conversations. Fewer lost-in-translation moments.
For a meaningful class of tasks, it became faster to just build the thing than to describe what you wanted and wait for someone else to build it. Think about that for a second. Every modern software organization is structured around the assumption that implementation is the expensive part. When that assumption breaks, the org has to change with it.
Our designer fixing the plugin UI is a perfect example. The old workflow (screenshot the problem, file a ticket, explain the gap between intent and implementation, wait for a sprint slot, review the result, request adjustments) existed entirely to protect engineering bandwidth. When the person with the design intuition can act on it directly, that whole stack disappears. Not because we eliminated process for its own sake, but because the process was solving a problem that no longer existed.
The compounding effect
Here's what surprised me most: It compounds.
When PMs build their own ideas, their specifications get sharper, because they now understand what the agent needs to execute well. Sharper specs produce better agent output. Better output means fewer iteration cycles. We're seeing velocity compound week over week, not just because the models improved, but because the people using them got closer to the work.
Dmitry put it well: The feedback loop between intent and outcome went from weeks to minutes. When you can see the result of your specification immediately, you learn what precision the system needs, and you start providing it instinctively.
There's a second-order effect that's harder to measure but impossible to miss: Ownership. People stop waiting. They stop filing tickets for things they could just fix. "Builder" stopped being a job title. It became the default behavior.
What this means for the industry
A lot of the "everyone can code" narrative last year was theoretical, or focused on solo founders and tiny teams. What we experienced is different. We have ~50 engineers working in a complex brownfield codebase: Multiple surfaces and programming languages, enterprise integrations, the full weight of a real production system.
I don't think we're unique. I think we're early. And with each new generation of models, the gap between who can build and who can't is closing faster than most organizations realize. Every software company is about to discover that their PMs and designers are sitting on unrealized building capacity, blocked not by skill, but by the cost of implementation. As that cost continues to fall, the organizational implications are profound.
We started with an intent to accelerate software engineering. What we're becoming is something different: A company where everyone ships.
Andrew Filev is founder and CEO of Zencoder.