Three principles for sustainable AI adoption: a guide for engineering leaders

You’re rolling out LLM-powered tools like Claude Code and OpenAI Codex. Maybe you’ve dealt with procurement, built a plan, run some trials, created some working groups. Or maybe you’re figuring out where to start. Some engineers are excited and others are nervous. You’re reflecting and thinking about what next steps to take.

This article presents a humanistic and pragmatic lens to apply to existing and upcoming AI efforts, aimed at creating a sustainable advantage for your organization. We discuss three principles:

• Create psychological safety around AI to drive better outcomes
• Invest in engineering fundamentals to benefit both humans and agents over the long term
• Experiment and iterate on LLM and agent patterns

These principles focus on the idea that engineering is not here just to “deliver value.” Our role as leaders is to create a sustainable organization that can continue to deliver value over time. We do this by anchoring in our people, our systems, and iterating.

Create psychological safety #

In 2026, society is deeply skeptical about AI, even as leaders can be surprised and blindsided by this perspective. Younger employees and women especially have mixed feelings about AI and they probably won’t express this in the surveys you or your HR team run. While the framing of bringing in LLMs is usually to drive more impact more efficiently, many companies have been attributing layoffs to AI, leaving many employees feeling uncertain about the future.

We know that psychological safety improves emotional commitment and discretionary effort. Our first principle: create psychological safety around AI across your team.

Here’s a potential path to take:

1. Discuss concerns around AI with your leadership team. How do your company values guide your handling of LLM tools in the context of these concerns?
2. Conduct some open listening tours: whether 1:1 or team-by-team, create opportunities to hear and acknowledge the concerns.
3. Share a message that aligns company goals with individual goals.

A great way to open a conversation with your leadership team and peers is to have a reading group or discussion series on the concerns and tradeoffs around AI.

There are notable concerns about the ethical, environmental and societal impacts, highlighted by Emily Bender and Timnit Gebru in their stochastic parrots paper, explored in more depth by Karen Hao in her book Empire of AI. Some employees will have concerns about the world that AI executives are trying to create and how that may impact society over time. Some impacts are perhaps overstated, but there are many hard questions with no easy answers.

From a cultural perspective, LLMs change the experience of workers and the nature of work: a February 2026 HBR study argued that AI intensifies work; tech thought leaders know that the role of software engineers specifically will change, as writing code itself can increasingly be handled by agents. This requires that engineers spend (even more) time on design and validation, which is a new skill and may have its own form of mental strain and stress. Even Steve Yegge, who lives at the bleeding edge of agentic coding has argued to take a more balanced approach to avoid burn out.

After your leadership and employee listening tour, you can craft a message about how to create a shared future where you, your team and your customers will all benefit from agentic tools. Bring in your company values as appropriate.

I would recommend that you frame LLMs as a tool to help advance the company’s long term mission. Recognize the prevalence of LLMs and the opportunity to learn together as both careers and the company evolve. This framing aligns leadership and individual contributors to use LLMs as part of a shared future. Notably this avoids a mandate (“everyone must use ChatGPT and max their tokens!”). Mandates result in resistance; shared learning will bring people together.

Invest in engineering fundamentals #

Having acknowledged the potential risks of LLMs and agents, and re-committed to the growth and success of our team, let’s consider what will make them effective. Contemporary models are exceptionally good at predicting the next token to generate code, but that code is not guaranteed to work, be maintainable, or be scalable. It likely contains subtle bugs and vulnerabilities. Fortunately, this is a problem that affects human engineers as well, and what’s good for humans is good for the robots.

Our second principle is to invest in engineering fundamentals to uplevel the effectiveness of human and LLM powered code.

I’ve worked with engineering organizations who rushed to adopt LLM tools and then hit problems: slow builds, unexpected production issues, no consistent documentation.

Modern engineering fundamentals exist to help engineers build correct, maintainable, secure, performant code and to operate it safely for customers. Here are some questions to consider:

• How fast can you go from a blank machine to an environment that can be used to develop your product? If your new hire setup guide is a Notion page with 30 steps, you won’t be able to have an agent fix a bug in the cloud on its own.
• How effectively do you use automated tools to catch mistakes? Configure linters and other static analysis tools to detect common bad patterns; customize your tools with domain specific rulesets that capture best practices unique to your code. These are fast and guaranteed ways to ensure basic levels of correctness. Security scanners and dependency checkers can monitor to ensure that you are using approved libraries and not using versions with vulnerabilities.
• How fast is your build? The more time your developers (and robots) spend waiting for the build to finish, the slower your learning and iteration.
• How good is your process and architectural documentation? Every organization has its quirks and best practices — from how to use company-specific tools, to policies that must be followed for compliance. In many companies, this learning is acquired through experience and locked away in the minds of tenured engineers, yet both humans and models need this knowledge to make decisions that conform to and advance architectural goals. These days we call this “harness engineering” or “context engineering”.
• How quickly, confidently and automatically can you validate your releases? If you need a 1-week turnaround by an offshore QA team, having AI write more code faster will make you go slower, not faster. But if you have good unit, integration and end-to-end test coverage that runs in a continuous integration system, you will know that your system is working with every commit.
• How well does your observability stack help you detect and resolve issues? Do you have metrics and alerts for key systems or do your customers tell you when the site is down? AI is great for looking for patterns in monitoring data… if you have it.

The smallest incremental movement in these areas improves life for human developers, even if you never adopt a single AI tool. Engineers will start shipping smaller changes which are inherently lower risk. With deterministic and reproducible protections against large classes of errors, you will feel more confident exploring the capabilities of AI tools.

Experiment and iterate #

The space of agentic coding is changing quickly. With new models coming out every few months, new features coming to harnesses every week, and new ways of using them trending on social media, the 18-month agile transformation playbook no longer works.

Yet, learning takes time. You have to scaffold yourself and your team into using these tools effectively, within the context of your organization. Just as buying a chainsaw doesn’t mean you know how to cut down trees or carve an ice sculpture, paying $20/month to Anthropic won’t make an engineer into agentic coders.

Many well-known and respected developers are finding that LLM tools allow them to operate and experiment more than they could before, and many advise cautiously iterating and learning. Some examples include Simon Willison (Python Software Foundation member, Django co-creator), Salvatore Sanfilippo (the author of Redis), Mitchell Hashimoto (co-founder of HashiCorp), and Martin Fowler (a signatory of the original agile manifesto). Each details how they engaged with LLM tools and moved from skeptics to adopters. It wasn’t a straight step from zero to one-shotting entire apps.

Thus, as you invest in engineering fundamentals, it is important for everyone in the team to play with tools. At one company I worked with, leadership explicitly allocated time for engineers to be “learning” to alleviate some of the pressure on just delivering.

In particular, engineers need to learn the edges of these tools. There are definitely risks — when connected to real systems and given unfettered access, agents have been known to delete directories or drop production databases. Worse, there is a structural security issue in all LLMs called the “lethal trifecta” where LLMs today cannot distinguish between trusted and untrusted content. This can result in attacks where inputs from the internet can cause your agents to take harmful actions.

Clear guidelines are essential (especially if you work in a regulated environment such as under HIPAA or PCI). Engineers work on laptops that often have the ability to connect into production environments. Access to external integrations (MCPs) and tools (e.g., skills) can be a significant attack vector. Sandboxing tools offer protection but can take days or weeks of tuning to work properly in your environment. An approach I’ve seen work is to start with policy guidelines and training as a foundation and with technical enforcement added over time.

If you are at the very start of your journey, I would ensure that engineers supervise the agents instead of aiming immediately for an unattended software factory. A great way to start is to go with non-production code tasks:

• Write documentation
• Debug a stack trace or try to find a cause of a bug
• Review an existing PR
• Write a script to automate creating a report or dashboard

These all exercise an agent’s ability to read code and take meaningful action but in a controlled way, where engineers can begin to get comfortable with the tool and learn how it behaves.

The important thing to do is to experiment and share the results of what works and what does not. The least efficient mode will be to have every person learn on their own in a silo. Learnings amplify and scale if they are shared, so put in place some regular way to connect people with one another. For example, a shared chat channel to share wins and learnings (failures), a weekly round-table, or pair-programming sessions can all work. Tools like claude-code-transcripts help you share real conversations and see what works. Chances are that you have some people who are enthusiastic about these tools in your org and have been playing around with it in their spare time. Make this a leadership development opportunity for them.

Next steps #

There are many other guides out there about adopting AI in your organization. Here are some that I found helpful:

• Will Larson, a VP of Engineering, summarizes an early approach at Imprint.
• Pete Hodgson, a consultant, guides towards a middle path between the skeptics and the true believers.

A few words on budget and ROI may be helpful. I suspect that arguing for budget to spend on LLM tools is no longer the uphill battle it was 3 or 4 years ago. If initial budget is a challenge, it costs as much to cater lunch one time for a team of 30 (up to $1000 in the US) as it does to get them all on a basic LLM plan for a month. You don’t need to lock in to long-term contracts until you’re more comfortable.

Of course, costs can add up, so work to find a reasonable budget for “engineering tools” that can be inclusive of things like version control (GitHub seats), IDEs (Visual Studio, JetBrains) or observability tools (DataDog, Honeycomb, etc). No one needs to justify purchasing Microsoft Word to replace using Notepad; LLM tools are starting to fall into a similar bucket.

The “return” is a harder question. We know that it is extremely hard to measure and describe engineering productivity even in the absence of LLM tools. We have seen many fall back on 1980s-style metrics like lines of code written or PRs merged, but writing 10% more code is not the right way to think about the productivity of engineers. It’s definitely worthwhile to consider metrics in your engineering organization, but treat measurement as its own project, separate from procuring tools.

Ultimately, it’s not important to have been an early adopter. Success comes to organizations guided by thoughtful leadership and that brought their people along. The hard part is having the right conversations with your team, mapping your fundamentals investments, and setting up the feedback loops that let the organization learn together. If you’re working through any of this — or stuck on a piece of it —  get in touch.