Navigating LLMs as Developers: A Framework for Responsible Use
Large Language Models have been positioned as powerful tools for developers. And they are nothing more than tools. But like any tool in our arsenal, they come with their own set of risks that need to be understood and managed carefully.
The Double-Edged Sword
The risks posed by LLMs to developers are real and worth examining. First, there’s the risk of cheating ourselves out of thought. When we lean too heavily on these models, we might be bypassing the critical thinking process that makes us better engineers. The concern isn’t that tools are bad, but that over-reliance on any tool can create dependencies that weaken the underlying skills we need when the tool isn’t available or fails us.
This connects to what I call the “brain pointer” problem. Before Google, people knew to look in an almanac for general information, factual lookups, and reference data. But after Google proliferated, people started replacing almanacs as their go-to source for general knowledge with Google searches. Similarly, we risk replacing our internal knowledge of programming patterns, API signatures, and problem-solving approaches with LLM queries.
There’s also a productivity paradox worth considering. LLMs can generate solutions that appear correct but contain subtle bugs or inefficiencies that require significant debugging effort to identify and resolve. The time spent reviewing, testing, and fixing these near-miss solutions can easily exceed the time it would have taken to write the code from scratch with full understanding of the requirements and constraints.
But there’s a deeper concern beyond just time efficiency: the cost to personal development from not figuring out answers ourselves first. Think about the consequences for new developers who leverage LLMs for solutions without first attempting to solve and analyze problems themselves. They might get working code faster, but they’re missing the crucial learning that comes from struggling through problems, making mistakes, and understanding why certain approaches work or fail. This experiential learning is what builds the intuition and pattern recognition that separates senior developers from junior ones.
The damage to our critical thinking abilities could be subtle but significant. When LLMs provide solutions that look reasonable on the surface, we might skip the deeper analysis that would normally catch edge cases or architectural problems. These limitations become particularly apparent when tackling novel programming challenges, as demonstrated in recent Advent of Code studies, where LLMs fail “catastrophically” on unfamiliar problems while working well only for known cases. The pattern suggests that LLMs excel at reproducing familiar solutions but struggle when genuine creativity or deep problem-solving is required.
The Real Benefits
Nonetheless, the benefits can be substantial when LLMs are applied to the right problems. The true enabling power of LLMs for code assistance lies in reducing the activation energy of new tasks enough that they are tackled (and finished) when they otherwise would have been left on the pile of future projects indefinitely. They excel at handling boilerplate code, exploring unfamiliar (yet well documneted) APIs, and tackling those mundane tasks that consume time but don’t require deep thinking.
In my experience, LLM effectiveness varies dramatically based on communication skills and problem selection. I’ve observed that developers who craft thoughtful prompts and choose appropriate use cases see genuine productivity gains, while those who treat LLMs as magic solutions often struggle with disappointing results. My thinking on this has been shaped by observations about the risks of AI-generated code and the hidden productivity costs that aren’t immediately apparent when first adopting these tools. This reinforces my belief that LLMs are tools that amplify existing skills rather than replace them.
A Framework for Accountability
To navigate these tensions, I hold myself accountable to what I call the three T’s of LLM use:
1. Training
Staying current on the latest LLM capabilities and limitations is essential. This includes understanding new developments in embeddings, benchmarks, tooling, information retrieval, etc.. The landscape changes rapidly, and what was impossible six months ago might be commonplace today. But equally important is understanding where these tools consistently fail.
2. Transparency
I commit to clearly stating when LLMs have been used in any work I produce. This isn’t about shame or apology, but rather intellectual honesty. When I submit a pull request, write documentation, or present analysis, I disclose LLM involvement upfront. This transparency helps colleagues understand the work’s provenance and make informed decisions about necessary review rigour.
3. Traceability
When LLMs have been used in producing work, I make my prompts available for review. This creates a paper trail that allows others to understand not just what was generated, but how it was generated. It also forces me to be more thoughtful about my prompting, knowing that others might read it.
Beyond Individual Practice
These principles could easily be adapted for corporate environments. For example, an organizational approach might include the following.
Employees could be reuired to complete training on how to use a controlled interface to existing LLM services and understand their limitations. Too many people are using these tools without understanding their failure modes or appropriate use cases. The training should emphasize not just how to use these tools, but when not to use them. A controlled interface ensures that, for example, sensitive data doesn’t leak to external providers while still providing access to LLM capabilities.
Corporate transparency policies could require acknowledgment whenever LLMs might have been used in any work product. For example when drafting reports, presentations, emails , or code commits. This creates organizational awareness of LLM usage patterns and helps identify where additional oversight might be needed.
Traceability at the corporate level means preserving chat logs and making them available as appendices or upon request for any work that involved LLM interaction. This creates accountability and allows for post-hoc analysis of decision-making processes.
The Stakes
Without frameworks like these, we risk falling susceptible to the cognitive risks outlined above. I believe we risk becoming overly dependent on tools that we don’t fully understand, and we risk producing work that appears solid but lacks the deep thinking that comes from genuine engagement with problems. My goal is to use them as the tools they are: powerful, useful, but requiring careful handling.
The future of software development will likely involve LLMs in some capacity. Our responsibility as developers is to ensure that involvement enhances rather than diminishes our capabilities. The framework I’ve outlined isn’t perfect, but it represents the best approach I can articulate for a world where content on the internet is no longer guaranteed to be attributable to original human thought. It’s a starting point for maintaining the intellectual rigor that makes good software possible while leveraging the genuine benefits these tools provide in our increasingly AI-augmented landscape.