Jeba Prince
← Writing
2 min readAI, Engineering, Architecture

Don't Outsource Thinking to an LLM

An LLM can't own your system's architecture — only you can. LLMs are excellent executors, not architects. Think first, decide the design explicitly, and use the model to execute, explore, and explain.

LLMs are powerful. They can write code fast, refactor functions, generate tests, explain concepts, and unblock you when you're stuck. Used well, they multiply productivity. Used blindly, they create technical chaos.

The core problem is this:

An LLM cannot own your system's architecture — only you can.

LLMs are excellent executors, not architects

If you already understand:

  • your domain,
  • your constraints,
  • your scalability and reliability needs,
  • your long-term roadmap,

…then an LLM is a strong co-pilot. It accelerates implementation and helps you explore options.

But if you don't have a clear mental model of your application, the LLM will happily generate something — and that something often becomes technical slop:

  • inconsistent patterns,
  • mixed paradigms,
  • unclear boundaries,
  • accidental complexity,
  • code that "works" but has no direction.

At that point, you don't understand where your application is heading — and neither does anyone else.

Architecture is a thinking job — don't hand it off

Architecture is about:

  • trade-offs,
  • constraints,
  • future impact,
  • intentional boundaries.

LLMs don't feel the pain of production incidents, scaling limits, or maintenance cost. You do.

If you're unsure about the right architecture:

  • spin up a separate planning / research thread,
  • ask the LLM to compare approaches, not decide for you,
  • validate against your real constraints (team size, skills, infra, timelines).

Use the LLM to learn and challenge your thinking, not replace it. You stay in control. You make the call.

YOU · THE ARCHITECTThink firstDecide architectureMake the callyour thinking leadsLLM · THE EXECUTORExecuteExploreExplainLLMs are tools, not brains — let one lead and slop accumulates.
You lead, the LLM follows. You own the thinking — domain, constraints, architecture, the call — and the model executes, explores, and explains. Flip it and slop accumulates.

Keep your development thread focused

In your actual development thread:

  • keep the context tight,
  • guide the LLM with your decisions,
  • enforce the architecture you've chosen.

Your thinking should lead. The LLM should follow.

If you let the LLM drive unchecked, it will:

  • drift across patterns,
  • introduce unnecessary abstractions,
  • optimize locally while breaking the global design.

That's how technical slop accumulates.

The rule of thumb

  1. Think first.
  2. Decide architecture explicitly.
  3. Use LLMs to execute, explore, and explain — not to lead.
LLMs are tools, not brains. If you outsource thinking, you lose control.