There's a sentence I've heard three times this month from senior devs, always said with the tone of someone confessing a sin: "I honestly don't know anymore if I wrote this or just approved it." Nobody wants to admit it publicly, but that's what's happening in thousands of repositories right now. Welcome to vibe & verify, the new professional standard where the AI writes and the human stamps it — and where nobody's quite sure if that makes us more productive or just more liable for mistakes we never really understood in the first place. Let's be blunt about what's actually at stake here. For decades the core skill of a programmer was writing code. That's what got tested in interviews, that's what got taught in universities, that's what separated the junior from the senior. Suddenly that hierarchy is flipping and almost nobody stopped to argue whether that's a good thing. The valuable skill now isn't writing a function from scratch, it's looking at five hundred lines generated in seconds and deciding, with some confidence, whether the thing actually holds up. And you can already feel the discomfort there: people who spent years mastering the writing side feel the rug pulled out from under them, while people who just arrived think they finally found a legitimate shortcut. The question nobody wants to answer clearly is who's at fault when something breaks. Take a boring, almost mundane example: a dev uses AI to generate a pagination function, the code looks clean, it passes whatever tests exist, it gets approved in a PR fairly quickly because the reviewer is also in a hurry and also trusts the tool a bit too much. Three weeks later someone finds out the function has an edge case that duplicates records once the offset crosses a certain threshold, something that only shows up with real data volume. Who failed there? The model that generated the code without flagging the limitation, the dev who didn't test the extreme case, the reviewer who signed off without running the scenario, or the company culture that decided a fast review counts as a sufficient one? In my experience the answer most companies give, in practice, is "nobody," and that probably should bother more people than it does. We've kind of seen this movie before, in a way. Stack Overflow also raised a whole generation of programmers who knew how to copy and paste answers without fully understanding the why, and the world didn't end. Low-code frameworks promised the same kind of shortcut and survived decades without any apocalypse. Cheap outsourcing also produced code that nobody on the team truly understood and products still shipped, more or less. So maybe the panic around vibe coding is just the same moral cycle recycled with a nicer name. But there's a difference worth admitting: none of those earlier tools generated complete, coherent, plausible code at the speed of a paragraph per second, with a fluency convincing enough to fool even experienced people. Copying from Stack Overflow forced some friction, some reading of context, some adapting. AI removes almost all of that friction, and it's exactly that missing friction that makes shallow review so tempting. And here's the most uncomfortable part of all: there are bugs that a vibe-mode review simply won't catch, because the code looks right. No syntax errors, reasonable naming conventions, follows conventions decently well. The problem sits in an implicit assumption the model made that no human questioned because there was no obvious reason to be suspicious. I've seen this in authentication code where the token validation looked solid but silently ignored an expiration edge case across a different time zone, something only a specific manual test would reveal. A reviewer who's genuinely verifying, not just eyeballing the general vibe of the code, would have to mentally run that scenario or write it as a test. That takes time. And time is exactly the resource companies are trying to cut by adopting this workflow. Because let's not kid ourselves about the incentives here. Companies love this model because, on paper, it seems to cut cost and speed up delivery — fewer hours writing, faster reviews, sprints closing sooner. Except the people actually carrying the weight of the uncertainty are the senior devs, the ones signing off on pull requests knowing, deep down, they can't guarantee with the same confidence as before that the thing is correct. There's a misalignment of interests here that almost nobody discusses openly in meetings: the company wants speed, the reviewer wants safety, and the compromise usually reached is a review that pretends to be rigorous but in practice is a skim with a "looks good" at the end. Maybe the more honest question to ask isn't whether this is right or wrong, but whether we're building the right skills for this reality at all. Verifying AI-generated code well isn't the same skill as writing code from scratch, and treating them as equivalent is exactly where the real danger lives. Verifying well requires deeply understanding the problem domain, requires knowing what questions to ask of code you didn't write, requires a trained paranoia about where models tend to fail — things like concurrency, data edge cases, implicit assumptions about valid input. This isn't some minor skill picked up casually through osmosis while vibe coding. It's arguably harder than writing, except nobody's teaching it yet as its own discipline. I'll go out on a limb with a prediction that I know will annoy some people: within two or three years, "I can rigorously verify AI-generated code" will carry more weight in a technical interview than "I can implement an algorithm from scratch." Not because writing stops mattering, but because it'll become increasingly rare for anyone to write anything substantial without AI support, while the ability to catch the subtle mistakes it makes will stay scarce and poorly taught. And if that's right, companies that keep hiring and promoting based purely on who "writes beautifully" are going to fall further out of step with the actual work their seniors do every day. Curious whether you agree, or whether you think this is just another overreaction to a tool that, at the end of the day, still demands exactly the same care it always did.