A two-axis model for understanding LLM strengths and weaknesses (medium.com)

An engineer mapped LLM behavior onto a simple two‑axis model — openness (many valid answers vs a single correct one) and context‑specificity (general knowledge vs deep domain expertise) — to explain why interactions with LLMs can feel magical one moment and maddening the next. Low‑context/high‑open problems (the “Brainstormer”) like architectural brainstorming or profiling analysis are LLM sweet spots; low‑context/low‑open tasks (the “Encyclopedia”) like algorithms, boilerplate, common bug fixes (e.g., preferring onMouseDown over onClick to avoid onBlur ordering) and semantic code search are also reliable. High‑context problems split: when open‑ended they can yield useful pattern analysis (e.g., personality/interaction analysis), but when precision and deep integration matter (the “Curse”) — complex UI styling, cross‑file refactors, or changes that depend on implicit contracts and full project state — models typically fail. The model matters because it gives practical guidance: use LLMs for exploration, discovery, drafting plans and surfacing unknowns, but not as a drop‑in for precise, multi‑file engineering tasks that require a persistent, holistic mental model of a codebase. Technically, strengths come from broad training data and pattern matching/semantic retrieval, while weaknesses stem from lacking persistent state, implicit project knowledge, and the ability to safely reason about interdependent side effects.