AI is changing how software gets built, but its biggest effect on engineering leadership may not be the amount of code developers can produce. It may be how quickly teams can understand unfamiliar systems, solve problems that previously required specialized expertise, and reduce the operational risks that slow down delivery.

For engineering leaders, this creates an interesting shift. The traditional expectation is that as responsibilities grow, time spent writing code should shrink. Managing people, aligning priorities, making decisions, and supporting the team become more important than contributing directly to implementation. That principle still holds, particularly when leading larger teams. But AI is changing the balance by making it easier for leaders to contribute technically without spending days getting back up to speed.

The opportunity is not to replace management with coding or expect leaders to become full-time developers again. It is to use AI to close the distance between understanding a problem and doing something useful about it. A leader who can investigate a technical issue, build a small internal tool, or understand an unfamiliar part of the system can make better decisions while staying connected to the team's daily challenges.

That shift also raises important questions. If AI makes onboarding faster, does that change how much organizations should worry about specialized knowledge? If new technologies become easier to understand, should engineering teams be more willing to adopt them? And if AI can explain a system's behavior, what does that mean for documentation and technical ownership?

The answers are still developing, but one principle is becoming clearer: AI creates the most value when it strengthens engineering judgment, shortens the path to understanding, and helps teams build systems that are easier to operate and maintain.

As an engineering leader, it is easy to become increasingly removed from implementation. Meetings, hiring, performance conversations, planning, and cross-team coordination can consume the working day. Over time, even leaders with strong technical backgrounds may find it difficult to investigate a problem directly because they no longer have enough uninterrupted time to understand the relevant code.

AI coding agents change that equation. A leader can ask an agent to explain an unfamiliar component, trace a dependency, propose an implementation, or help build a small internal tool. The leader still needs to understand the problem and evaluate the result, but the amount of time required to get started can be substantially lower.

Consider a team that releases a feature with a serious defect. The team needs to disable the feature quickly, but its deployment process lacks a convenient feature-flagging mechanism. Without that capability, reversing the change may require additional code changes or a redeployment, increasing the time during which customers remain exposed to the problem.

An engineering leader could delegate the task, purchase a third-party solution, or investigate the problem directly with AI assistance. One practical option is to use an AI coding agent to build a simple feature-flagging tool that fits the team's existing architecture and workflow. Rather than introducing another dashboard and login, the tool can run from the command line and include documentation that both developers and AI tools can understand.

The important outcome is not the quantity of code written. It is that the team gains a practical capability that improves deployment safety and can be used for critical releases.

This illustrates where hands-on leadership can be especially valuable. Leaders often encounter problems that are too small to justify a major project but important enough to create recurring friction or operational risk. A lightweight internal tool, a missing automation step, or a clearer development workflow may deliver more immediate value than another round of planning.

There is a limit, however. If leaders start solving every technical problem themselves, they can become bottlenecks and take ownership away from the people doing the work. Hands-on contributions should strengthen the team's capabilities, not create another dependency on the leader.

Tip: Look for small, high-impact engineering problems that repeatedly slow the team down or increase operational risk. Use AI to investigate and prototype a solution, then involve the engineers who will maintain it. The goal is to leave the team with a better tool or process, not a system only the leader understands.

Joining a new engineering team often means learning much more than a programming language. A developer needs to understand how the application is structured, where important business rules live, how services communicate, which conventions the team follows, and why certain decisions were made.

Even experienced developers can spend days searching for the right files, reading unfamiliar code, and waiting for someone with the relevant context to become available. Documentation helps, but it can become outdated as the system evolves. The result is that onboarding depends heavily on the availability of people who already understand the codebase.

AI coding assistants can reduce some of this friction by helping developers explore a system interactively. Instead of relying only on existing documentation, a developer can ask an AI tool to explain how a request moves through the application, identify where a particular behavior is implemented, or compare possible approaches to a change.

The same assistance can help someone investigate a specialized topic outside their deepest area of expertise. For example, a developer who understands application logic but has limited experience with PostgreSQL performance can use AI to explore query plans, investigate indexing options, and understand potential database bottlenecks. The explanations can make the investigation more accessible, although the developer still needs to verify the recommendations against actual system behavior and measurements.

This also creates an opportunity to improve documentation organically. Rather than treating documentation as a separate project that is postponed whenever delivery pressure rises, teams can improve README files, architecture notes, and AI-specific instruction files as part of their normal development work.

Clear documentation helps human developers find relevant code and understand the system's conventions. Well-maintained instruction files can also give AI coding tools important context about how the repository should be explored, tested, and modified.

The benefit extends beyond newly hired employees. An engineer moving to another team, investigating an unfamiliar service, or returning to a system after several months can use the same approach to rebuild context more quickly.

However, faster access to explanations is not the same as guaranteed understanding. AI can produce a plausible description that misses an important dependency or misinterprets a business rule. Documentation can also be incomplete or incorrect. Teams still need reliable tests, code review, and clear technical ownership to confirm that the explanation matches reality.

Tip: Improve documentation where developers and AI tools actually need it: repository entry points, setup instructions, architectural boundaries, testing procedures, and common troubleshooting steps. Ask AI to help identify gaps, but verify the resulting documentation against the code and the team's established practices.

Engineering teams have long debated when to introduce a new programming language, framework, database, or service architecture. Every additional technology can solve a particular problem, but it also introduces learning requirements, operational responsibilities, and maintenance costs.

For example, breaking a monolithic application into microservices can allow teams to deploy components independently and establish clearer service boundaries. Yet it can also introduce network failures, distributed tracing requirements, service-to-service authentication, additional deployment pipelines, and more complicated testing. A system that was relatively easy to understand in one codebase can become harder to operate when its responsibilities are distributed across many services.

AI changes part of this calculation by making unfamiliar technologies easier to investigate and learn. Developers can use AI to explain APIs, generate examples, compare architectural options, and understand code in languages they have not used extensively. That reduces some of the initial learning burden and can make a team less dependent on having a specialist for every technology it encounters.

Consequently, an engineering leader may have fewer reasons to reject a new technology simply because the team has limited prior experience with it. If a new service or language solves a genuine business or technical problem, AI-assisted onboarding may make the transition more manageable.

But easier learning does not eliminate the long-term costs of complexity. A developer might use AI to create a working service in an unfamiliar framework, yet the organization still has to deploy it securely, monitor its performance, respond to failures, update dependencies, and maintain it years later. Generating an implementation is only one part of operating a reliable system.

The right question is therefore not whether AI makes a technology easier to use. It is whether the technology's benefits justify the additional responsibilities it introduces.

A new service might be worthwhile when independent scaling, isolation, or deployment flexibility provides measurable value. It may be unnecessary when the same result can be achieved by improving a well-structured existing application. AI can help teams evaluate these choices, but it cannot make the trade-offs disappear.

Tip: When evaluating a new technology, separate the initial implementation cost from the long-term operating cost. Consider deployment, monitoring, security, testing, incident response, and future maintenance alongside the benefits. Let AI reduce the learning barrier, but require a clear reason for adding architectural complexity.

A familiar engineering risk occurs when only one or two people deeply understand a critical system. This is often called the bus factor: the number of key people who would need to become unavailable before a project or system faces serious disruption. The term describes a continuity risk, not a prediction that anyone will actually be harmed.

When knowledge is concentrated in a small number of people, routine work can become unexpectedly difficult. A deployment may depend on one engineer who remembers an undocumented configuration. A production issue may require someone who understands a complicated interaction between services. A team may hesitate to change a legacy component because nobody else feels confident about its behavior.

AI can help reduce this dependency by making it easier for other developers to investigate the code directly. An engineer can ask an AI assistant to trace a function's callers, explain a data flow, locate relevant tests, or summarize how a component behaves under different conditions. This makes some previously specialized knowledge easier to access.

There is an important distinction here: AI can help more people understand the system, but it does not automatically transfer the experience and judgment of the person who built it.

The original engineer may know why a seemingly unnecessary workaround exists, which production failure led to a particular design decision, or which external dependency behaves unpredictably under load. Some of that context may not be visible in the code. An AI tool that examines the repository may therefore produce a technically reasonable explanation without capturing the full operational history.

The risk also depends on the quality of the available evidence. AI tools can inspect code and documentation, but their answers remain limited by the information they can access and interpret. They may overlook indirect dependencies, misread configuration, or suggest a change that conflicts with an undocumented constraint.

Organizations should use AI to broaden access to knowledge while continuing to reduce unnecessary knowledge concentration. That means documenting critical decisions, sharing ownership of important systems, improving tests, and giving multiple engineers practical experience with operational tasks.

Tip: Identify systems that depend heavily on one person's knowledge, then use AI-assisted exploration to help additional engineers understand their architecture, failure modes, and maintenance procedures. Validate the explanations with the existing owner, improve the documentation, and ensure more than one person can safely deploy, troubleshoot, and modify the system.

AI adoption is often discussed in terms of productivity gains: more code, faster development, shorter delivery cycles, or fewer hours spent on routine tasks. Those outcomes matter, but they do not fully capture the opportunities created when people become more familiar with what AI tools can and cannot do.

Developers who use these tools regularly learn which tasks benefit from delegation, which questions produce useful explanations, and where human review remains essential. They discover that an AI assistant may be excellent at tracing a code path or drafting a test but less reliable when requirements are ambiguous or the task depends on context that has not been supplied.

That practical experience creates a different kind of capability: the ability to recognize problems that can now be solved more easily than before.

A developer who once avoided investigating an unfamiliar subsystem may now be able to explore it independently. An engineering leader who previously lacked the time to build a small internal tool may be able to create and test a prototype. A product team may discover that a workflow previously considered too expensive to automate is now feasible enough to evaluate.

These experiences can lead to better ideas because people are not limited to imagining AI as a general-purpose assistant. They begin to understand how it can change specific workflows, remove barriers, and enable capabilities that were previously impractical.

This matters beyond engineering teams. Leaders in product, operations, and other functions may have ambitious expectations for AI without understanding the practical limitations or possibilities of the tools. They may assume that adding AI to an existing process is enough, when the larger opportunity could involve redesigning the process itself.

At the same time, enthusiasm should not be mistaken for evidence. A promising prototype does not establish that a solution is accurate, secure, reliable, affordable, or useful to customers. Ideas generated through everyday experimentation still need evaluation, testing, and a clear understanding of the problem they are intended to solve.

The strongest organizations will create space for people to explore these possibilities while maintaining standards for quality, security, and accountability. They will treat AI fluency as a capability that grows through experience, not as a guarantee that every AI-assisted idea will succeed.

Tip: Encourage developers and product teams to share practical examples of where AI has removed a real bottleneck, improved a workflow, or enabled a previously impractical experiment. Evaluate those ideas based on measurable outcomes, reliability, and user value rather than the novelty of the technology.

AI is changing the relationship between engineering leaders and technical work. It can make it easier for leaders to investigate unfamiliar code, contribute to small but important improvements, and understand the systems their teams maintain. It can also help developers learn faster, reduce some knowledge bottlenecks, and explore technologies that once required a larger upfront investment in training.

These changes do not make engineering leadership less important. They make good judgment even more valuable.

A leader still needs to know which problems deserve attention, when a technical shortcut creates unacceptable risk, whether a new service is justified, and how to build a team that can maintain its systems without depending on a single expert. AI can help gather information and accelerate implementation, but the organization still needs people who understand the business context and take responsibility for the decisions.

The most effective approach is neither to keep leaders completely removed from implementation nor to encourage them to become the team's default problem-solvers. It is to use AI to stay technically connected, remove meaningful friction, and strengthen the team's ability to work independently.

That requires balancing experimentation with discipline. Small tools should solve real problems. Documentation should reflect the system that actually exists. New technologies should earn their place through clear benefits. Critical knowledge should be shared rather than concentrated. And AI-generated solutions should be validated before they become part of production systems.

For an engineering leader, the opportunity is to become more effective at connecting technical possibilities with the outcomes the organization needs. Sometimes that means writing a small tool. Sometimes it means helping a new engineer understand a complicated service. Sometimes it means rejecting an attractive architectural idea because its long-term costs outweigh its immediate benefits.

Tip: Choose one recurring engineering bottleneck that affects delivery, reliability, or onboarding. Use AI to investigate the problem and develop a practical improvement, then measure whether the change actually helps the team. Expand the approach only when the results justify it.

AI may write more of the code, explain unfamiliar systems, and shorten the distance between an idea and a working prototype. But the real advantage comes from using those capabilities thoughtfully. The future of engineering leadership is not about knowing every technical detail or delegating every technical task. It is about knowing where human judgment matters most, and using AI to help the entire team make better decisions.

Hit reply and tell me: what is one small technical problem AI helped you understand or fix, and who on the team ended up owning it? I read every answer.

One more from today's sponsor, which helps keep Tiny Big Spark free:

Keep going, one small spark at a time.

Erwin