I’m seeing a weird split with AI copilots: they can make a rough answer feel polished enough that people trust it before they’ve really checked it. That feels less like a speed thing and more like a confidence thing, which is a bit more unsettling.
Has anyone else noticed that in code review or estimation conversations?
The polished vibe is exactly what makes it dangerous in review, because it looks intentional even when it’s just confidently average. I’ve started watching for a specific smell: AI-y code tends to come with a neat little explanation and clean naming, but the tests (or edge cases) are weirdly thin or missing, like it never actually ran in anyone’s head. In estimation it’s worse because it’ll happily hand you a plausible breakdown that feels project-manager-ready, and suddenly you’re debating the formatting instead of whether the assumptions are real. I’m not sure how to fix that culturally beyond forcing one person to play “show me the failure mode” on any Copilot-assisted chunk before it gets merged.
Yes, I have heard it before. The most significant shift isn’t AI’s speed of providing answers, but its ability to do so with a fluency that can plausibly make answers more believable than they actually are.
I’ve already seen lines of code generated by AI that are clean, convention-driven, even with sound comments, but which still have subtle logic bugs or have overlooked edge cases. It’s well written and reviewers are tempted to skim rather than check the behavior.
This is true of estimation conversations as well. While an AI can create a realistic work breakdown and timeframe, if the assumptions are incorrect, the final look may leave everyone feeling like they have their work all wrapped up.
In my opinion the most effective way to think about using AI is that it can be a very good first draft, but not an authoritative answer. This can facilitate brainstorming and documentation, but the team is still ultimately responsible for the reasons and assumptions.
:: Copyright KIRUPA 2024 //--