Changing the Narrative on AI

If you have followed the news recently, you’re most likely getting inundated with news about AI and particularly news about companies using AI to reduce or eliminate positions because AI can “do their jobs.” Some of this could be a convenient excuse to reduce staff, but in general I feel it shows a lack of company vision around maximizing their adoption of AI.
I have been working in software development for more years than I care to admit, but my son who also chose to enter this exciting field and is just beginning his career is worried about AI taking his job someday. I imagine many college students who were thinking about going into software development are feeling the same. With the increase of AI usage, software developers are likely to be needed more, but to keep that supply of new engineers companies need to stop using AI as an excuse to eliminate and reduce staff.
I have seen tech trends come and go throughout my career and often new technology, which has touted that it’s the end-all be-all or it’s the future of software development, is often replaced by even newer and different technologies. Much like any of these past trends, AI is still evolving and changing. New versions keep coming out and change how they’re being used. It’s important for us as software developers to use AI as a tool and not as a crutch. Anytime we become too dependent on one of these trends we run the risk of relying too much on what they provide. I remember in the 90s when the Microsoft Component Object Model (COM) was the new thing and the first COM wizard came out to create your COM objects. People began to lean on those wizards so much that they no longer knew how their code worked and fixing problems became a nightmare. We need to avoid having AI write so much code that we lose touch with how things really work.
Don’t get me wrong, I do feel AI can make me more productive at times, but that productivity on the coding side is spent perfecting the prompts I give the AI to produce good code and the reviews after that code’s production to make sure it’s free of defects and vulnerabilities. Could the AI have also produced that? Sure, if my prompt was thorough enough; back to writing good prompts. The more I use AI, the more I get better and learn how to tell it what I want and the shorter the review time is afterwards, but one fact remains, I am involved and I still use my many years of software development to get it right.
I Feel Companies Should Choose “More” Over “Less”
If you would consider: Two software companies get the same AI coding tools. Company A uses them to eliminate their junior developer positions, “Why hire juniors when AI can write basic code?” Company B gives those same tools to their entire team and watches junior developers start delivering features that used to take senior developers weeks to build.
Fast forward two years: Company A is struggling to grow and find senior talent and has a knowledge transfer crisis and a talent vacuum while Company B has a pipeline of rapidly-advancing developers who understand both the codebase and how to leverage AI effectively. Guess which one is actually shipping faster?
Everyone is obsessed with AI efficiency stories. “Look how we automated away 30% of our workforce!” But here’s what nobody mentions: what happens to your innovation capacity when you optimize for minimum viable humans? A lot of companies are walking into the wrong AI future.
Reframing the Conversation
The “Replace and Reduce” mentality (what most companies default to) should be shifting to the “Enhance and Expand” approach (what forward-thinking companies actually do).
Smart companies aren’t using AI to reduce and replace staff, they are using AI to reduce and replace less strategic work that their staff was faced with doing. This allows their staff to breeze through previously manual and tedious tasks that took them away from what was important.
When you cut staff, you don’t just lose headcount, you lose institutional memory. That senior developer who got laid off? He knew why that weird workaround exists in the payment system. The junior who got cut before his review? He was the only one who understood the client’s actual workflow because he’d been shadowing their team for months. AI might write code, but it can’t tell you the story of why decisions were made or what’s been tried and failed before. Companies that mass-eliminate staff often spend the next two years rebuilding knowledge that walked out the door.
Here’s what the efficiency reports don’t capture: when Company X lays off 200 people to “AI-optimize,” those aren’t just numbers, they’re 200 fewer mortgages being paid, 200 families reconsidering their kids’ college plans, and one community that just watched a major employer choose algorithms over people. The reputational damage is real. Good talent starts avoiding you. The developers you do want to hire are reading the same headlines and thinking “I’ll be next.” Your brand takes a hit that no press release about “strategic restructuring” can fix. You read about some companies that can’t fill roles offering major salaries, because these prospective employees know that the same company feels humans are expendable when that job is complete.
When your team watches AI eliminate their colleagues, they don’t think “Great, now I can focus on innovation!” They think “I better not build anything that makes me replaceable.” So they stop experimenting. They stop sharing the clever automations they’ve built. That junior developer who figured out how to use AI to auto-generate test cases? He’s keeping that script on his local machine, thank you very much. You’ve just created an environment where people actively hide innovation to protect their jobs. The irony? You cut staff to become more efficient and ended up making your entire organization less innovative.
What Happens When People Aren’t Afraid? Job security unlocks creativity with AI tools. Instead of a development team being worried about automating themselves out of a job, the development team creates an internal AI debugging assistant which ends up becoming a product they now license to other companies, an innovation dividend that only comes from psychological safety.
Companies should be shifting from “What can we eliminate?” to “What becomes possible?” Companies racing to have the fewest employees are creating the same vulnerability. The companies building AI-enhanced human capabilities? They’re becoming harder to replicate.
AI Is Not Always Right
The real problem comes from relying too much on AI. I have read many articles about AI gone wrong in major ways, but I have been lucky enough to avoid those mishaps, not because the prompts I submit are so perfect that I always get exactly what I was looking for, but instead because I use those years of doing software development to look at what was produced and realize I either need to refine what I asked it to generate or take what it gave me and make it work correctly.
For instance, I have had AIs generate scripts to do some simple functions in the database before, and if I took what it produced, pasted it into my tool and clicked execute without reviewing it, it would have deleted crucial data from the database. I have had it generate code for me before, only to have it create new features that I didn’t ask for and which didn’t always work. Or even change names on a document that were clearly spelled out in the prompt. Imagine sending a proposal out that you just assume the AI produced satisfactorily and have it received with a different content than you intended.
The Compounding Returns of Capability Building
Here’s the potential of what I feel happens when you enhance instead of eliminate:
Year One: Your junior developer uses AI coding assistants to ship her first major feature in three weeks instead of three months. She’s learning faster because she’s actually building, not just reading documentation. This learning should be under the guidance and mentorship of a senior developer with frequent input and code reviews. The junior developer should show understanding of the code that was produced and be building a foundation of solid development knowledge and not only learning the code that’s produced, but understanding why the approach is taken will not only grow their skills, but also enhance their ability to scrutinize AI’s choices. The junior developer continues to enhance her skills and improve the code she produces with and without AI. Another human in the loop is not an option, it is required.
Year Two: That same developer now mentors two new juniors while tackling increasingly complex problems. She’s begun to develop an intuition for when to trust AI suggestions and when to question them; a skill that only comes from experience. That’s why being mentored by a senior developer is so important and still continues. They help the junior developers understand what code they’re looking at and help them make good choices. Your team velocity has doubled, but more importantly, your capacity to take on different types of problems has expanded. There’s many things an AI will not question when developing code and it’s important that people using these tools learn to spot and work around deficiencies.
Year Three: Your mid-level engineer (that former junior) just proposed an architecture improvement that your senior engineers missed. Why? Because that mid-level engineer came up through a world where AI tooling was normal, so she thinks differently about what’s possible. She’s not constrained by “how we’ve always done it.” That’s one item, unless you go out of your way to train it to, an AI does not consider. AI is not concerned with forging new ground or developing code that doesn’t factor in previous code which opens up more channels for innovation and improvement.
Year Five: That developer is now leading a team, and she’s built a culture where AI augmentation is second nature. She’s hiring and training the next generation. Your company isn’t just shipping features faster; you’re solving problems you couldn’t have even articulated five years ago because your team’s capability ceiling has been raised permanently.
The math is simple but powerful: When we use AI to do our jobs better, we don’t just work faster; we get better at getting better. An AI tool has roughly the same capability on day 1 as day 1,000. A human using AI tools gets exponentially more effective over that same timeframe. That’s compounding returns.
Where to Start
Here’s the thing about choosing the augmentation vs. elimination path; it requires different thinking from day one. You can’t just bolt AI onto existing processes and hope for innovation magic. You need to fundamentally reimagine what becomes possible when human creativity meets AI capability. Here’s where Solution Street can help: Instead of focusing on what AI can replace/eliminate, we help companies discover the potential of what they can build with the right AI adoption strategy.
By helping companies intelligently use AI across the entire Software Development Lifecycle (SDLC), we’ve helped teams reduce deployment times from weeks to hours while keeping the same headcount. We’ve watched QA engineers become security and performance optimization specialists. We’ve seen junior developers start approaching more complex programming challenges they couldn’t touch before. The result? Companies that don’t just ship faster, they ship things they never thought possible.
My message to my son is that tech trends will come and go, but the engineers that embrace them and use them to their advantage to keep learning will position themselves for the future. The engineers that maximize the new technology that’s out there and uses those skills to improve and advance their own ability will be the ones that companies need down the road to take advantage of the next big thing.
The next time someone presents you with an AI implementation plan, ask one simple question: “Does this make us more capable, or just cheaper?” Because in five years, the companies that chose “more capable” will be the ones writing the case studies.
Ready to explore what “more capable” looks like for your team? Let’s talk about turning your AI investment into innovation acceleration instead of headcount reduction.
