Chat is a bad UI pattern for development tools

Natural language vs programming precision

• Many argue natural language is inherently ambiguous; once you must be “careful” and exhaustive, you’ve effectively created a programming/specification language, not everyday speech.
• Others counter that plain English can fully specify complex systems, but only when used in a formal, constrained way (formal specs, legal contracts)—again blurring into a DSL.
• Several comments note that most people cannot naturally write such precise specs; “technical English” is effectively a specialized language requiring expertise.
• This leads to predictions of new, higher-level programming DSLs or subsets of English tailored for AI (“structured prompting,” Gherkin-like behavior specs, pseudo-code that the model turns into code).

Strengths and weaknesses of chat for development

• Critiques: chat is linear, ephemeral, hard to search, and bad as a source of truth; context gets polluted; you must re-explain intent; it’s like building software inside a Slack thread.
• Supporters: for many, chat feels like pair programming or rubber-ducking—excellent for brainstorming, clarifying ideas, doing small refactors, generating boilerplate/tests, and one-off scripts.
• Several note that chat excels at “fuzzy generation” (e.g., image prompts, UI sketches, high-level design), but is poor for precise, large-scale system evolution.
• Some go further: chat (and even Slack/Discord) is a poor UI for any long-lived collaborative artifact compared with documents, tickets, and versioned files.

Documents, specs, and structured interfaces

• Strong thread arguing that software is really built from documents: PRDs, specs, tickets, architecture docs. Using those as primary AI input is seen as more scalable than ad-hoc chat logs.
• People describe workflows where requirements docs, checklists, .cursorrules, architecture.md, or “scratchpads” drive the model; chat then becomes local commentary around these artifacts.
• Others propose declarative pseudo-code or DSL-like specs that AI translates to implementation, with chat only for incremental updates (“make this gradient red,” “add a name field”).

Tooling and alternative UIs

• Experiences with Cursor, Zed, Windsurf, Aider, cline, Continue, etc.:
  • Inline diffs, per-hunk approval, and tight git integration reduce the “black box” fear.
  • Automatically gathering relevant code context works sometimes but can be flaky.
  • Many find autocomplete (“super-completion”) more valuable than chat itself.
• Suggested UI directions: visual sketch-to-code (e.g., tldraw-style), multimodal UIs, block markers in code (named regions the AI edits), hierarchical/threaded chats, voice-driven coding, spec-driven agents, and IDE overlays that feel more like HUDs than chat windows.

Limits of current LLMs

• Complaints that models rarely ask clarifying questions and often confidently produce wrong or context-mismatched code, especially in niche or complex domains.
• Verification often takes as long as (or longer than) just writing the code, especially for developers who “think by coding.”
• Context-window limits, non-determinism, and chat-history pollution are recurring pain points; some tools respond by aggressively pruning context or isolating tasks.

Broader UI and control perspectives

• Several commenters stress that computers should be tools directly operated by users, not semi-autonomous agents you “negotiate” with; chat feels like pleading with “Mr. Computer.”
• Others see chat as just one layer: great for ephemeral dialogue around more durable artifacts (code, docs, diagrams), not a replacement for them.
• Overall sense: chat is useful but fundamentally incomplete; the “next phase” will likely combine structured specs, richer UIs, and more explicit workflows on top of LLMs, with chat as an auxiliary channel rather than the core interface.