Past the AI Hype Cycle: Practical LLM Use-Cases for Engineers

Nate Jones opens with a question most people in tech can relate to: are you riding the AI hype cycle, oscillating between "this changes everything" and "all the jobs are gone"? His answer is to skip the oscillation and focus on concrete use-cases. He highlights two blog posts by engineers named Nicholas and Eric that describe, with unusual clarity, exactly where LLMs fit into a real engineering workflow.

The through-line is that LLMs are not magic. They are a tool with specific strengths, and the people getting the most value from them are the ones who treat them that way. Jones, who describes himself as a reasonably technical product person, noticed that the engineering use-cases these bloggers describe are not fundamentally different from how a non-technical person uses an LLM. The same principles apply. The tool just shows up in different contexts.

He walks through three examples. The first is code diffing. A standard diff tool can show you which lines changed. An LLM goes further: it can explain what the code is doing and why the change matters. That is especially useful in large projects where keeping context in your head across many files is the real bottleneck. The same logic applies to comparing documents. If you have two related docs and want to understand how they diverge without reading both end-to-end, an LLM handles that well.

The second example is the blank page problem. Jones draws the parallel to writing: people already use LLMs to get past the empty screen when drafting a LinkedIn post or a resume. The blog posts he references make the same argument for code. If you are stuck and staring at an empty file, the LLM can give you a starting point. Jones adds a caveat worth noting: on the writing side, he thinks a human voice is essential for the final pass. In a world where everyone finishes with an LLM, the person who closes with their own voice stands out.

The third example is the most ambitious. The bloggers discuss zero-shotting or one-shotting an entire app build. Not a large or complex app, but trusting the LLM to ask clarifying questions and work through the build process iteratively. Jones tried this himself in Claude earlier in the week. His observation: part of getting a bigger result from tools like Claude or ChatGPT is letting the model ask you questions rather than front-loading every detail in one prompt. Let it surface its own uncertainty.

Jones closes with a broader point about LLMs and discovery. These tools do not come with an instruction manual the way software did in the 1990s, where you could read a menu and understand every feature. LLMs are generative. Their capabilities are latent, and we are still mapping the boundaries. He points to Apple's leaked system prompt as evidence: Apple is talking to LLMs the same way everyone else is, with the same trial-and-error prompting style. Nobody has it fully figured out.

Key Takeaways

• Code diffing with context. LLMs do not just show what changed in code. They explain what the change does and why it matters, which is a meaningful upgrade for navigating large codebases.
• The blank page problem applies to code too. The same reason people use LLMs to start a blog post or resume works for getting unstuck on an empty source file.
• Let the model ask questions. Bigger results come from trusting the LLM to surface uncertainty and ask for clarification, rather than trying to specify everything upfront.
• LLMs are not magic, and nobody has the manual. Even Apple is prompting LLMs with the same trial-and-error approach as everyone else. The practical move is to try specific use-cases and learn what works.