I stopped using LLMs to get answers and started using them to ask better questions. That shift changed how fast I can pick up complex topics, and it is the whole point of this article.
Last year I had to get functional with Istio and Kiali fast, on a hospital microservices program where the client wanted service mesh observability before their next audit window. I'd touched service mesh concepts before, but never had to actually configure mTLS policies or debug a sidecar injection failure at 11pm. My old approach would've been: open six browser tabs, read the official docs, skim three blog posts of varying quality, maybe find a video that's already half outdated. That process used to take me a week to get comfortable with something new. Now it takes two or three days, and honestly, the quality of my understanding is better, not worse. That surprised me at first. I expected LLMs to give me a shallower understanding — a kind of "looks right but doesn't hold up under pressure" knowledge. It's the opposite, if you use them right. Used wrong, though, you end up with confident nonsense in your head. So let me walk through what actually works for me, because I've burned time on the wrong approach too. The mistake I made early on When ChatGPT first got good, I treated it like a faster Google. I'd ask "explain Kafka consumer groups" and get a clean, well-organized answer, and I'd move on feeling like I understood it. I didn't. I understood the explanation, which is a different thing entirely. The tell was always the same: I'd go to apply the concept in actual code and hit a wall. Something about partition rebalancing wouldn't click, or I'd misunderstand how offsets commit under enable.auto.commit=false . Turns out reading a good explanation and being able to reason about edge cases are not the same skill. Not even close. So the first real change I made was this: I stopped accepting the first answer. I started treating the model like a sparring partner instead of an encyclopedia. Asking for the wrong answer on purpose This is the trick that changed things for me the most, and it came from a weird place. Years ago, debugging a Debezium connector issue on a FinTech integration, a senior architect I worked with had this habit of asking "okay, what's the naive way to do this, and why is it wrong?" before ever discussing the right approach. It stuck with me. Now I do that with LLMs constantly. Instead of asking "how does optimistic locking work in JPA," I ask something like: "Show me a JPA entity update that looks correct but actually has a race condition, then explain exactly where it breaks under concurrent writes." That single shift does more for retention than a dozen clean explanations. Why? Because I'm not just absorbing a fact, I'm building an internal alarm bell. Next time I see that pattern in a code review, something fires before I even consciously reason about it. Here's an example from when I was refreshing my understanding of @Version -based optimistic locking in Spring Boot: @Entity public class Account { @Id private Long id; @Version private Long version; private BigDecimal balance; public void withdraw(BigDecimal amount) { // Looks fine. It isn't, if you're not catching // OptimisticLockException upstream and retrying. this.balance = this.balance.subtract(amount); } } I had the model walk me through exactly what happens when two threads load the same version, both compute a new balance, and both try to commit. Watching that failure mode play out step by step, instead of just reading "optimistic locking uses a version column to detect conflicts," is what actually made it stick. Making it explain things at the wrong level, then the right one Something I do a lot now: ask for the explanation twice, at two completely different altitudes, and compare them. First pass, I'll ask something almost condescendingly simple, like "explain this to me like I've never touched a database." Second pass, I ask for the version aimed at someone who already knows relational databases cold and just needs the specific nuance. The gap between those two answers usually contains the actual insight I was missing. I did this with Kafka's exactly-once semantics a while back. The beginner explanation was basically "messages won't be duplicated or lost." Fine, but useless for actually building anything. The expert-level pass got into idempotent producers, transactional IDs, and how the read_committed isolation level on the consumer side changes what you actually see. That second layer is where the real work happens, and I wouldn't have known to ask the right follow-up question if I hadn't seen the oversimplified version first and felt unsatisfied by it. Treating the model as a Socratic partner, not an oracle I stole this from teaching. I've mentored a handful of backend engineers over the years, and the ones who learn fastest are the ones I make explain their own reasoning back to me, not the ones I just hand answers to. So now, when I'm learning something dense, I flip the script and make the LLM quiz me instead of the other way around. Something like: "I'm learning Kubernetes network policies. Ask me five questions of increasing difficulty about how they interact with namespaces and DNS resolution. Don't give me the answers until I attempt each one." This is uncomfortable in a good way. It's the difference between reading about how a lock works and actually trying to write the code and watching it deadlock in front of you. I'd guess maybe 70% of what actually sticks from my learning sessions now comes from this quiz-back approach rather than pure explanation. That's a rough number, not something I've rigorously measured, but it feels about right based on how often I catch myself getting a "trick question" wrong and realizing I had a gap. Where I actually draw the line I don't use LLMs to learn everything the same way, and I think a lot of people mess this up by treating all learning as the same activity. Syntax and API surface stuff : I'll just ask directly and move on. No Socratic games needed for "what's the method signature for Flux.zip in Reactor." That's lookup, not learning. Architectural tradeoffs : this is where I slow way down and demand the model argue both sides. If I'm weighing Kafka versus Kinesis versus SNS/SQS for an event-driven integration, I want the model to actually defend each option before I pick one, not just list pros and cons in bullets that all sound equally convincing. Anything I'll be accountable for in production : I never trust the explanation alone. I build a small throwaway reproduction. Every time. No exceptions, because I've been burned before by an explanation that sounded airtight and turned out to have a subtle wrong assumption baked in. Historical or "why does this exist" context : LLMs are genuinely great here, better than most blog posts, because they can synthesize the evolution of a technology without you having to piece it together from five sources with conflicting timelines. One thing I'm careful about: I always ask for the failure mode, not just the happy path. "When does this break" is a more useful question than "how does this work" nine times out of ten. Where this connects to building ITJobOpportunities This whole approach reshaped how I think about the resume improvement and Job Fit features on ITJobOpportunities, and not in the way you'd expect. When we were building the resume improvement pipeline, I kept catching myself falling into the same trap I described earlier: asking the model for the "right" way to structure a prompt for extracting skills from resume text, getting a clean answer, and assuming it would generalize. It didn't. Real resumes are a mess. People format dates inconsistently, list skills in a paragraph instead of a bullet list, use acronyms that mean different things across industries. The clean textbook prompt fell apart against actual resumes pulled from candidates on the platform. So I started applying the "show me where this breaks" habit to my own prompt engineering. Instead of asking an LLM "write me a prompt to extract skills...