How a Staff Engineer Actually Uses AI: Beyond the Hype

As a staff engineer, I've found real value in large language models (LLMs), but only when applied strategically. Here's how I leverage AI tools in my daily work, focusing on practical benefits rather than buzzwords.

Copilot: Smart Autocomplete, Not a Coder

I use GitHub Copilot for code completion, but primarily for boilerplate. It's great at filling in function arguments and types. For business logic in my areas of expertise (like Ruby on Rails), I rarely accept AI-generated code. Copilot is an enhanced autocomplete tool, not a replacement for domain knowledge.

Tactical Assist in Unfamiliar Territory

When working outside my core expertise, say, tweaking a Golang service or C library, I lean more on Copilot. I'll often use Copilot chat to check if my code is idiomatic:

// My C code snippet
Copilot: Is this idiomatic C?

This lets me operate at a baseline level across languages, but it's crucial to have a subject matter expert review these changes. It's a tool for quick tactical work, not a substitute for deep understanding.

Accelerating Research with Throwaway Code

For non-production, one-off tasks, I'm much more liberal with LLM usage. Recently, I used AI to write scripts for API data retrieval, classification, and regex approximation, all for a local research project. This approach can speed up such tasks by 2-4 times compared to writing everything manually.

On-Demand Tutor for New Domains

The most valuable application I've found is using LLMs as a learning aid. When exploring new areas (like Unity game development), I engage in a Q&A process with ChatGPT-4o. The ability to ask follow-ups, seek clarification on concept relationships, and verify my understanding is invaluable.

I often write summaries of what I've learned and ask the LLM to review them, pointing out misunderstandings. This interactive learning process has been remarkably effective, and I've yet to encounter significant hallucinations in well-established topics.

Last-Resort Debugging

While I don't rely heavily on LLMs for debugging, I occasionally use them as a Hail Mary. If I'm truly stuck, I'll share the relevant code and error message with Copilot chat. It's a low-effort attempt that sometimes catches subtle issues I've overlooked.

Proofreading with a Grain of Salt

For technical documents like ADRs or internal posts, I sometimes use LLMs for a final review. They're good at catching typos and occasionally highlight logical inconsistencies. However, I limit this to a single round of feedback and always ignore stylistic suggestions.

What I Don't Use LLMs For

It's crucial to note where I don't apply LLMs:

• Writing entire pull requests in my areas of expertise
• Drafting ADRs or other critical technical communications
• Conducting research in large, complex codebases

The Bottom Line: Augmentation, Not Replacement

LLMs are powerful tools when used judiciously. They excel at augmenting human capabilities in specific contexts, code completion, quick prototyping, learning assistance, and proofreading. However, they don't replace the need for deep technical expertise, critical thinking, or domain knowledge.

The key to effective LLM use lies in understanding their strengths and limitations. By applying them strategically to enhance productivity and learning, rather than as a wholesale replacement for human skills, we can harness their potential while mitigating risks. As the technology evolves, so too will our methods of integration, but the core principle of thoughtful, targeted application remains crucial.