I'll be honest. A year ago, if you told me I'd be having full conversations with an AI while building features at work, I would have laughed. Not b...
For further actions, you may consider blocking this person and/or reporting abuse
The subscription leak story is the one that sticks. Not because the fix was complex, but because the failure was invisible. No errors, no crashes, just gradual decay that looked like normal performance variance until it wasn't.
That's the debugging gap AI fills best and the one we talk about least. Not the "fix this error message" cases but the ones where you can't even articulate what's wrong yet. Describing the architecture to an external reasoner forces you to externalize the mental model, and often the act of describing is where you spot the seam.
One limitation I'd add: AI reasons about the snapshot you give it. It can't notice that this is the third time in six months your team has had a subscription leak at a service boundary. That pattern recognition across time is still entirely on you.
Thanks for elaborating in a good way mate...
The "rubber duck that talks back" framing is spot on. We use a similar mental model at Othex — AI as a thinking partner rather than a code generator. The shift changes everything about how you prompt and what you actually get out of the interaction.
The failure modes you describe (architecture, judgment calls) are real. Where we draw the line: AI can suggest patterns, but the decision of which pattern fits this context stays with the human. That contextual judgment is exactly what's hard to automate — it requires understanding the whole system, the team, the constraints.
One thing we've noticed: AI is great at "what are the tradeoffs here" questions but often terrible at "which tradeoff matters most for our specific situation." The second question requires knowing things that aren't in the codebase.
True
Honest take, and rare to see someone actually define the limits instead of just hyping the wins. The part about not outsourcing architectural decisions resonated I've seen codebases where you can tell which files were "AI-shaped" vs. ones written with real project context in mind. The gap is usually in how edge cases are handled and how well the code fits the surrounding patterns. That 10-20% you mention is exactly where engineering judgment lives.
Yeah, thats true
The "rubber duck that talks back" framing is perfect. That's exactly how I use AI — not to write my apps for me, but to think through problems out loud with something that can actually respond.
As someone who builds iOS apps entirely with AI assistance (no CS background), the debugging partner role has been the biggest game-changer. SwiftUI's error messages are notoriously unhelpful, and having AI reason about the interaction between view hierarchies and state management has saved me countless hours.
One thing I'd add to the "where I stop" list: domain-specific product decisions. AI can scaffold a pregnancy tracking app in minutes, but it has no idea what information an expecting parent actually needs at week 28 vs. week 36. That judgment comes from talking to real users — and no amount of prompting replaces that.
Yeah
This is true. When I first discovered ChatGPT, I noticed I progressed faster in learning web development. Not by making it do the code but by being a coding partner that have the answers every "why" questions I have about a certain code. This answer is typically not what you can get from a simple Google search.
Thats true