LLMs for Developers: What's Actually Useful After the Hype

The Hype Hangover Is Real

After the initial wave of "AI will replace developers" think-pieces and the subsequent "actually it's useless" backlash, most working developers have settled somewhere in the middle: LLMs are genuinely useful tools that require skill to use well, and they're particularly good at specific things that aren't always obvious at first.

Here's what two years of daily use in a PHP/Drupal workflow has taught me.

The Mental Model That Changed Everything

The most useful reframe: LLMs are a search engine for code knowledge, not a code generator.

When I use Claude or GPT-4 well, I'm not asking it to write code for me. I'm asking it to surface relevant knowledge — APIs I don't know, patterns I haven't encountered, edge cases I haven't considered. Then I write the actual code myself, informed by what I learned.

When I use LLMs badly, I'm asking them to generate large blocks of code and pasting them in without really understanding them. This produces bugs I can't diagnose and technical debt I don't notice until later.

What Actually Works Well

API Discovery

Drupal has thousands of hooks, services, and plugin types. Nobody memorises all of them. Asking "what's the Drupal 10 way to alter entity queries programmatically?" gets me to the right hook or service in 30 seconds versus 5 minutes of documentation archaeology.

Code Review

Pasting a custom module into Claude and asking "are there any security issues here?" or "what edge cases am I missing?" surfaces problems I'd otherwise catch in production. It's particularly good at spotting:

• Missing access checks
• Unsanitised user input
• N+1 query patterns
• Incorrect cache tag declarations

Writing Tests

Writing PHPUnit tests for Drupal modules is tedious. LLMs handle the scaffolding well — generating the test class structure, mock setups, and data providers — leaving me to fill in the actual assertions.

Explaining Unfamiliar Code

When I inherit a codebase with unusual patterns, asking an LLM to explain a specific section is faster than reading documentation and often more contextual.

What Doesn't Work

Long-Context Generation

Asking an LLM to write an entire Drupal module from scratch produces something plausible-looking that usually has subtle bugs in the Drupal-specific parts — incorrect hook signatures, wrong service container usage, outdated API calls. The longer the output, the more likely it is to introduce errors.

Anything With a Knowledge Cutoff Problem

LLMs have training cutoffs. Drupal 10 and 11 APIs, particularly newer features like Recipes and the AI module, are poorly represented in training data. Always verify AI-generated Drupal code against the actual drupal.org documentation.

Architecture Decisions

LLMs will confidently suggest architectural patterns for your specific business problem without understanding your constraints. Use them to generate options, not to make decisions.

The Practical Workflow

My current workflow:

1. For new features: sketch the approach myself, then ask the LLM to critique it and suggest alternatives I haven't considered
2. For unfamiliar APIs: ask the LLM for the right hook/service/plugin type, then verify against drupal.org docs
3. For debugging: paste the error + relevant code, ask for hypotheses — it's usually right on the first or second suggestion
4. For tests: generate the scaffold, write the assertions manually

The throughput improvement is real. Not because the AI writes code for me, but because it eliminates the lookup-and-context-switch overhead that breaks flow state.