What AI Can (and Can't) Do for Your Engineering Team (Beyond the Hype)
Co-written with Teal Bauer, Founder & Managing Director of Starsong Consulting. Teal (they/them) has over 25 years of experience from software engineering, design, to architecture, to strategic partnerships with businesses to navigate the complexities of building and scaling technology systems and human organizations.
Article Summary (TL;DR)
GenAI tools are fundamentally changing what engineers do day to day, but not in the ways most executives think, and the public hype and bold marketing messages around these tools make it difficult to have useful conversations about it. The technology is genuinely useful for specific, well-defined tasks, but it's also revealing a massive gap between hype and reality. Many engineers are experiencing an identity crisis as their relationship to code changes, while leaders struggle to set realistic expectations. The core skill of software engineering—solving problems, not just writing code—remains irreplaceable, but the day-to-day work is shifting toward conceptualization, planning, and more actual end-to-end ownership.
Note, March 7, 2026: I just read the newly-released book How to AI: Cut Through the Hype. Master the Basics. Transform Your Work., by Christopher Mims, and found it a solid primer that does a good job at cutting through the hype and giving useful pointers for how to make good use of AI.
We need to talk about what's actually happening to software engineering roles right now and how they're changing in this era of GenAI (Generative Artificial Intelligence: Using generative models to generate text, software code, images, or other forms of data). All of us working in tech are navigating a lot of hype, breathless marketing pitches, fear-mongering, amped up productivity pressures, and a messy, complicated reality beneath.
Many engineers and engineering leaders find it tricky to navigate and cut through all of that, identify what’s currently realistic in terms of tools, and what it means for them and their teams. We also often hear that teams found it useful to hear how others are going about it. That’s why we wanted to provide some perspective based on our conversations with leaders and engineering teams from five-person startups to corporations with thousands of employees.
In this article, we'll talk about:
What we're seeing in AI adoption practices in software engineering teams in companies of various sizes
What GenAI is currently good at in software development
What humans do better
The resulting challenges that engineers are facing
And how leaders can address them
Let's Start With Some Ground Truths
Before we dive in, we need to establish a few tenets that frame everything else in this article:
There is still a lot of hype around AI and a lot of snake oil being sold. Overpromises abound that the technology simply can't deliver on. GenAI is a powerful force multiplier for certain tasks. It's also a compressed word model at its core. Asking it for meaning is like asking a zip file for meaning.
These tools don't “know” anything and have no conscience. People anthropomorphize GenAI tools far too much. They're a bunch of mathematical functions. You give some input and get some output, but they have very limited context. They don't have continuity of existence and aren't living things. You can't really question or challenge their past "decisions." Any output is only as good as the input you give it: Garbage in, garbage out (GIGO).
The time savings and productivity gains are vastly oversold. Models still take a while to process, especially newer, more complex ones. The true bottleneck in software development has been and is the time it takes to think and conceptualize the input, not the coding itself. This doesn't look like it's going to change too soon. These tools will continue regurgitating what already exists, therefore limiting what they can do. Technically, you may be able to work on ten projects at once, but it also means you're still working on ten projects and need to context-switch accordingly. That's going to continue being a challenge.
The Current State: What We’re Actually Seeing
Teal has been following the evolution of AI tools very closely since the start [cue to early December 2022, prompting ChatGPT to generate a play Elon Musk’s Twitter takeover, but make it a Greek drama]. They primarily use Claude Code, Open Code, and Pi, for coding their own software and side projects, some client work, DevOps, home automation, and Open Source software development and contributions. Lena mostly uses Claude Desktop's Code mode to build small applications and automate daily tasks.
We both work with companies ranging from startups to corporations that operate globally or in markets like Europe and North America. The AI usage we see ranges dramatically: from organizations where engineers are actively lobbying against adoption, to (typically unspecified) "AI mandates" handed down from executives, to greenfield organizations vibecoding big chunks of their initial codebases.
On average, most teams and engineers have been playing around with these tools for a while and are having internal discussions about where and how they can be most useful. At the same time, most teams are under significant pressure, especially from C-level executives, to use AI more, often driven by concerns about missing out on the competition and falling behind.
Here's what adoption actually looks like across different company sizes:
Across the board, unless they don't for ideological reasons, software engineers use coding assistants and find them quite useful. Many companies have enhanced or partially replaced customer service and support with AI. Results vary greatly. These are the most universal adoption patterns we're seeing:
In smaller startups with existing production software: There's variety in how enthusiastically and intensely people use these tools. More enthusiastic users may deploy them for everything from analyzing and planning to iterating on specs, coding, and PR reviews and quality control—with varying levels of success. GenAI tools seem to have created more space for individuals to take ownership to a fuller extent than previously. Individual engineers are often asked to take on a broader, more end-to-end role than they used to for getting deliverables from scoping to launch.
We're also seeing boundaries between roles soften. Product managers in smaller companies occasionally land PRs for small features or fixes they hadn't done before. Engineers are taking more active roles in shaping the product, which goes back to that conceptualization skill.
Agentic AI assistants are gaining popularity, but they can be both powerful and very risky. We're also seeing teams experiment with AI for documentation or to automate tedious processes, such as triaging customer support tickets. Lots of experimentation all around. There's also much more pressure on product managers to use AI not just for their core roles but to build minimum viable products or even take on engineering work themselves, again with varying success. The pressure to use AI very intensely seems to be highest in smaller companies and startups.
In more established companies: Clear requirements to use AI on a daily basis seem a bit more common, while usage seems more guided by individual or team-level preferences and working styles. Many use knowledge management systems where AI ingests entire knowledge bases—this can be useful because it functions as a good search engine. However, beyond those initiatives, it looks like larger companies are sitting at the extremes of the adoption spectrum, with some adopting very little and others seemingly going all-in.
What GenAI Is Actually Good At Right Now (In Software Development)
Let's be specific about where these tools genuinely excel right now:
Code generation for well-defined tasks. Anything with a clear goal definition that's ideally also testable technically, either because you have a decent test suite set up or because there's a very clear definition of success. The better-scoped and the more well-defined the task, the better the results will be. Otherwise, small tasks work well, as long as they’re tightly monitored by a human.
Refactoring, debugging, and bug fixing can be straightforward when you have good bug reports or clarity on what's supposed to happen.
Feature development, when specified very clearly. The emphasis here is on "very clearly."
Language generation and natural language parsing, such as structuring documents or extracting important information. You still need to know what you're doing to avoid hallucinations.
Lowering entry barriers for making meaningful contributions in areas or codebases where people have less context, skills, or experience, or even work in stacks that they’re less experienced with. This can be tremendously useful for breaking down knowledge silos. It can also easily be misused or lead to problematic contributions.
What doesn't work: Very junior people or people new to the industry, trying to learn to code with AI. They get to functioning code quickly, but it's not maintainable, and they don't know why or how to fix it.
What Humans Still Do Better (And Always Will)
Here's where human engineers have clear, irreplaceable advantages:
We have an actual world model. We actually exist in the world and have an embodied experience and memory. We understand human motivation better than any model can. We have continuity, context, and history (and maybe even a future). We can step back, unprompted, and reflect on potential actions or events. We have goals and motivations. We're able to think critically and love and laugh.
We can be held accountable, and we have empathy. Unless we're billionaires, then neither of these things are true. We care about others. This matters enormously in building technology that serves human needs.
Conceptualizing and planning work. It's a huge advantage and, at some point, even a prerequisite to know how software development works to be able to instruct AI properly. Remember: garbage in, garbage out.
Making the right decisions for the context and the time in complex systems of humans and tech. For example, while AI may be able to generate an architecture, its ability to produce the appropriate architectural solution for your business at this point in time will be severely limited by its context and limited memory.
Handling complexity. A current limitation of most models is that they lack sufficient context to handle more complex problems. This can, in parts, be mitigated by tight specs, but there are limits. Context collapse and lack of a world model limit the resulting embodied context, memory, and persistence. Here's a major tenet in software development that's always been true: Write code only half as clever as you are because you need to be twice as smart to debug it. If you write code as clever as you are, then you are by definition not clever enough to debug it.
Now, if you have AI write code, it's going to write clever code, but almost by definition, it's going to be cleverer than you'll understand in the future. This means that you need to guide it really strongly toward writing sensible code, good code, reproducible code, easy-to-understand code that follows best practices, so that anyone looking at the project later, whether that's you or a human colleague or another agent, has a clue of what's going on. Without this guidance, you'll need to manage increasingly complex code, which will lead to an explosion of complexity.
It’s worth repeating: Software development has at its core always been about solving problems, not about writing code.
What Engineers Are Struggling With Around AI Adoption
It’s worth emphasizing that businesses overall and engineering organizations are undergoing seismic shifts that affect everyone. And while these changes have been underway for a few years now, the technologies we’re talking about here continue to evolve, and, as we’ve seen, how exactly they play out for different companies and people varies greatly. There’s a lot of uncertainty to handle. Many engineers, especially more senior ones, are experiencing something close to an identity crisis. We're seeing a mix of struggles:
External factors
BS messaging and targets set by senior leaders. Many engineers are quite open to tools like coding assistants, but are (rightfully) wary of senior leaders regurgitating AI companies’ pitches and pointless targets handed down by executives around AI adoption and “productivity.” Unspecified “AI mandates” or goals for lines of code generated by AI just continue a long history of questionable incentive structures and BS targets that don't really add value to teams, let alone the business.
Skepticism towards the hype around AI, and this really isn't unjustified. Engineers who have been in the industry for more than a few years have seen many tools come and go, lived through dozens of hypes around the latest and greatest, and seen those often be short-lived. The current inflated messaging around many AI tools doesn’t exactly ease suspicions about them.
Uncertainty about what’s useful, what isn’t, what good looks like.
Questions around value versus cost. Many have legitimate concerns about the enormous costs these tools entail, from impacts on our climate, the internet, and humanity at large.
Signal vs. Noise. There's a lot of noise from people who have now built software using AI without understanding the complexity involved, creating tools with glaring security gaps. It doesn’t even have to be deliberate “AI slop”; from lengthy, AI-created documents to piles of pull requests to review, poor standards around AI usage have created a lot of noise in some organizations, contributing to the erosion of trust.
Internal factors
Career concerns. Many worry about the future of their careers, the future-proofness of their skills, and their ability to earn an income with their job and support their families. All the noise in the media around “AI taking all jobs” doesn’t exactly help here, either.
Confusion about what success looks like. Many find it difficult to understand what their job should be now, what value they can add to the team and how, and what success looks like. Many managers struggle to articulate this themselves, making this even harder.
Threatened identity. Some engineers used to take great pride in their status as a "programmer" and feel somewhat threatened in this identity.
The engineers we've seen most successfully handle these challenges have done so with a mix using tools by companies that align with their values where possible, some curiosity for new tools and playfulness, pragmatism around how they use these tools and where they draw boundaries, finding ways to make their own lives easier, and reconfiguring their own notion of success.
What Engineering Leaders Should Do Right Now
If you're leading engineers through this transition, here's our tactical advice for the next 30-60 days:
Don’t treat their reactions as “change resistance”, but as “responses” to change. Your own attitude towards the changes your organization is undergoing makes a difference in your ability to handle it. This guide has more steps to help you lead compassionately and take your team members along.
Don't just regurgitate the hype messages or BS from senior management. Your engineers can smell it a mile away, and it destroys trust. Your question, as always, should be: What are our (business) goals, and how can we best reach them? (See also Lena’s article series on productivity and metrics.)
Focus on producing good results for the business, just doing so using different tools. Don't set bullshit targets like lines of code produced by AI, AI usage percentages by engineers, or accepted PRs generated by AI. These aren't great measures. Are you reaching your business goals? That's what matters.
Create sensible systems with your team
Actively stop antipatterns like gigantic PRs or sloppily created documents that are useless and impossible to review. Best practices for collaboration haven’t suddenly become outdated just because AI is around.
Have people take accountability for their work, regardless of how much is produced with AI input or without. Take pride in your own work. Don't overwhelm the people around you with slop.
Work with your engineers
Really understand where your engineers are at in their understanding. Have individual conversations. What are they using? What are they struggling with? What are their concerns? What would be helpful to them?
Assess what use cases make sense and where the limits are. Be specific about your context, your codebase, and your business needs. Using any tool for the sake of using it has never led to great results.
Help engineers learn from each other. Facilitate workshops together or support pair programming sessions where people use AI tools. Create space for sharing what's working and what isn't.
Continue investing in becoming better engineers. That need is not going away. In fact, it's becoming more important.
Open Questions We're All Navigating
We don't have all the answers. None of us do. Here are some of the questions we're sitting with:
What's the role and function of teams going to be going forward? At the same time that the way team members work has been shifting, the function of teams may be evolving. Over the last 10 years, there's been great emphasis on the "high-performing team" as the pillar of the engineering and delivery organization—the core entity that creates results. Humans remain social creatures, and many team functions—from social exchange to collaboration, creation, and knowledge exchange—can't be replaced by AI. But we think this development raises questions about the future of software engineering teams and the functions they serve socially and systemically within a delivery organization. We need teams for more than just distributing coding tasks—but what does that look like in practice?
How do we maintain code quality and security at scale when more code is being generated by tools and people who don't understand the consequences? The tendency toward complexity explosion is real, and incidents arising from improper or poorly reviewed GenAI use have begun piling up.
What does career growth look like for engineers now? If the nature of the work is changing fundamentally, how do we think about junior-to-senior progression?
These are questions we're all figuring out together. The landscape is changing rapidly, and certainty is in short supply. What we do know is this: The engineers and leaders who approach this transition with curiosity, pragmatism, clear values, and a commitment to solving real problems—not just adopting tools for their own sake—will navigate it most successfully.
The role of software engineers is changing. But the need for people who can think critically, understand complex systems, make sound decisions in context, and solve meaningful problems? That's not going anywhere.
