
Sign up to save your podcasts
Or


Are AI and developers the world’s best friends or is artificial intelligence a threat to the future of programmers? As artificial intelligence models are becoming increasingly sophisticated, many questions are raised about the future of developers across the industry. Will AI replace programmers entirely, as Eric Schmidt and Dario Amodei are predicting? Will junior developers be facing extinction, as Steve Yegge surmised in a now-famous blog post? Or are we witnessing the dawn of a new era in which technology amplifies human creativity rather than replacing it? I interviewed Nathaniel Okenwa, Developer Evangelist at Twilio, to pick his brains about this question, and his conclusion is that, in the future, software development will undoubtedly remain human-driven even though many changes will occur. The video recording of that interview is available at the end of this blog post.
With nearly a decade of hands-on programming experience and a unique perspective on developer community engagement, Nathaniel Okenwa brought both technical depth and strategic insight to this conversation about the evolving landscape of software development.
“My parents celebrated when I got that job title of developer evangelist,” Okenwa said. “I speak and meet with developers, online or in person, and I talk about the tools and the technologies they’re using. A part of this job is being with the community and then spreading the good news of Twilio as well.”
For those unfamiliar with the company, “Twilio is a customer engagement platform and one of the providers helping businesses with their customer support, communication tools, and APIs.”
The elephant in the room for the Tech industry is the fate of junior developers. Steve Yegge’s provocative piece ‘The Death of the Junior Developer’ has sparked intense debate, suggesting that AI won’t make inexperienced developers smarter but will enable experienced programmers to eliminate the need for juniors altogether. A daunting perspective for young programmers.
Nathaniel offers a more nuanced perspective that challenges this binary thinking .
Often, a company doesn’t hire junior developers for their current capabilities. They recruit them because they’re investing in what they will become in the future. Junior developers need to exist if we are going to have mid-level senior developers, developer leaders, and architects at a later time.
Nathaniel is right. Programming isn’t just about syntax and algorithms; it’s about developing problem-solving instincts, understanding business contexts, and learning to translate human needs into technological solutions.
‘If you want to create the next generation of builders, then I don’t think junior developers are going to disappear in the long term. We may forget how important they are for a little bit, but they will definitely make a comeback later on.’
The urgency of these questions intensified when Eric Schmidt, former CEO of Alphabet, made bold predictions about the timeline for developer displacement. His assertion that developers would be reduced to merely correcting AI output within six months and potentially eliminated entirely within a year sent shivers down the spines of the programming community.
Nathaniel acknowledges the partial truth in Schmidt’s predictions while advocating for a more sophisticated understanding of what developers do. “I think there are elements of truth in it, but I think the situation is a bit more nuanced. AI is, in my mind, another Industrial Revolution. In this context, it means we’ll be looking for repeatable tasks that are extremely simple and how to replace them with technology.”
The industrial revolution analogy is particularly apt here. Just as mechanisation didn’t eliminate human work but transformed it, AI appears poised to reshape rather than replace programming roles. “I think AI is going to take some aspects of programming and make them so cheap from an effort perspective that it’s not necessarily going to be the best use of people’s time. However, I think developers aren’t just folks that are repeatedly solving minor syntax sentences. They are creative builders coming up with different ways of taking a real-world problem and abstracting it into technology pieces.”
One of the most compelling aspects of Nathaniel’s perspective is his emphasis on abstraction as the key to understanding how AI will transform development work. Rather than replacing developers, AI represents another rung on the abstraction ladder that programmers have been climbing for decades.
Right now, I can use my programming skills to build a website and serve it to millions of people on the Internet. Thirty or forty years ago, I would have needed a whole set of different skills to make that happen. I would have needed so many more hardware skills and so many more specific high-level networking skills. And all of those things have been abstracted away for me to really focus on making this website really fast and performant.
This historical perspective illuminates a pattern that AI-anxious people are missing. Each generation of developers has built upon increasingly sophisticated foundations, allowing them to tackle more complex problems without getting bogged down in lower-level implementation details.
The printing press analogy further clarifies this progression: “If we think about the printing press, at first you needed to have lots of people who would sit down and handwrite a book in order for you to make 100 copies. The printing press came around, and the amount of effort and skills to achieve that shrunk considerably. But you still needed someone who could run that printing press.”
However, this progression toward higher abstraction levels raises uncomfortable questions about inclusivity and capability. Not every developer possesses the intellectual agility to continuously climb the abstraction ladder, and there’s value in acknowledging this reality.
Nathaniel addresses this concern with characteristic optimism while maintaining realism. “I suppose there will always be people who remain comfortable doing what they are doing in the ways they are doing it. But with technology making so many more different things available, what’s going to happen is users, customers, and the general public are all going to expect more from our technologies and from us.”
The market forces driving this evolution are relentless. As AI enables higher-quality experiences at scale, customer expectations rise accordingly, creating pressure on all technology providers to evolve or risk irrelevance.
“The folks who aren’t meeting these higher standards of experiences will not be able to deliver the value that their customers and employers are expecting from them. If they don’t continue to meet that bar of expectation that is growing higher and higher, especially as AI helps people to develop new ways of doing this, they will be left behind.”
This raises an interesting paradox about digital transformation that I’ve observed throughout my career in technology consulting. Thirty years ago, we predicted that traditional industries like banking would be disrupted by digital-native competitors. Yet established banks have largely survived, adapting gradually while maintaining their market positions.
Nathaniel offers an insightful perspective on this seeming contradiction: “It didn’t kill banks, but I would argue that even if maybe they took a while to get there, the way we interact with our banks is completely different from the way we interacted with banks when we were younger. There are 18-year-olds who have no idea what a chequebook is.”
The transformation happened, but more gradually and less dramatically than predicted. This pattern suggests that AI’s impact on development may follow a similar trajectory—profound but evolutionary rather than revolutionary.
Perhaps the most practical insight from our conversation concerns how AI tools are being adopted by developers. The success of GitHub Copilot and similar tools demonstrates that integration beats replacement as an adoption strategy.
“Sometimes there are engineers who are reluctant to use AI or don’t want to go out of their way to bring AI into their workflows. But when Copilot came out, when other tools that have that technology built into the applications, the interfaces they are already using, the adoption increases significantly.”
This observation reveals a crucial truth about technology adoption: the most successful innovations enhance existing workflows rather than demanding entirely new ones. The future of development tools lies not in replacing programmers but in making them more effective within familiar environments.
One of the most honest moments in our conversation addressed the reality of code reuse – something every developer practises but few discuss openly. The fear that AI will turn programmers into mindless copy-paste operators misses the historical context of how developers have always worked.
“Copying and pasting has been an integral part of the engineer’s journey for decades, and it’s not going anywhere soon. Even if we are copying and pasting from a different place, and even if we are no longer using Ctrl-C and Ctrl-V, we have always been learning from the code that others write.”
The key distinction lies not in the source of solutions but in the developer’s understanding of what they’re implementing. “The real issue is that of developers who go and find a solution online and copy and paste it without understanding what is going on. Now, if people do that with AI, they may create a black box, and that’s going to be great when it works. But when it doesn’t, when you receive a phone call in the middle of the night, and that production’s gone down, that’s a different kettle of fish. Having a black box is not going to be something that a huge company, a huge enterprise, is going to want to rely on.”
Our conversation touched on one of the most persistent challenges in enterprise software: the prevalence of legacy systems built in languages like COBOL that have resisted modernisation for decades. This serves as a fascinating case study in the relationship between technological possibility and human decision-making.
I think we underestimate the power of people. People are sometimes afraid of change. They sometimes want to rely on what has worked for years. And so, even if AI presents a great solution, it’s going to be people who decide whether to take it on board or not.
This observation cuts to the heart of why technological predictions often prove overly optimistic. Technical feasibility doesn’t guarantee adoption, and institutional inertia remains a powerful force in shaping the pace of change.
For students and emerging developers wondering how to navigate this uncertain landscape, Nathaniel offers pragmatic guidance that emphasises exploration.
“The first thing is to explore and experiment. Experiment with the new technologies. Find out what those new job titles are going to be and chart the path to become an expert. Either a specialist in using AI as a tool, or an expert in creating AI, or an expert in maximising its performance, or an expert in building the tools that AI will use.”
Nathaniel’s emphasis on APIs is particularly noteworthy: “APIs are nothing new. The better your API, the better the AI agents that will resort to it.” This suggests that developers who understand how to build AI-friendly interfaces will find themselves increasingly valuable.
Most importantly, he advocates for focusing on uniquely human contributions: “Don’t just focus on the typical tasks a junior developer is asked to do because AI can do them really well. Instead, focus on the ways that you can bring a unique twist to your solution.”
As our conversation with Nathaniel Okenwa demonstrates, the future of developers isn’t about choosing between human programmers and AI systems—it’s about understanding how these technologies can work together to solve increasingly complex problems. The most successful developers will be those who embrace AI as a powerful tool while focusing on the uniquely human aspects of software development: creativity, problem-solving, and the ability to translate human needs into technological solutions.
In a sense Nathaniel’s advice isn’t that different from Steve Yegge’s. You’ll have to become an expert to make good use of AI; it’s not artificial intelligence that will turn you into an expert.
Rather than fearing obsolescence, developers should view this moment as an opportunity to evolve, much as previous generations adapted to new programming languages, frameworks, and paradigms. The future belongs to those who can harness AI’s capabilities while providing the human insight, creativity, and understanding that no algorithm can replicate.
The future of developers isn’t about replacement—it’s about enhancement, evolution, and the continued pursuit of building technology that serves human needs. In that mission, developers remain not just relevant but essential.
The post The Future of Developers in the Age of AI appeared first on Marketing and Innovation.
By Visionary MarketingAre AI and developers the world’s best friends or is artificial intelligence a threat to the future of programmers? As artificial intelligence models are becoming increasingly sophisticated, many questions are raised about the future of developers across the industry. Will AI replace programmers entirely, as Eric Schmidt and Dario Amodei are predicting? Will junior developers be facing extinction, as Steve Yegge surmised in a now-famous blog post? Or are we witnessing the dawn of a new era in which technology amplifies human creativity rather than replacing it? I interviewed Nathaniel Okenwa, Developer Evangelist at Twilio, to pick his brains about this question, and his conclusion is that, in the future, software development will undoubtedly remain human-driven even though many changes will occur. The video recording of that interview is available at the end of this blog post.
With nearly a decade of hands-on programming experience and a unique perspective on developer community engagement, Nathaniel Okenwa brought both technical depth and strategic insight to this conversation about the evolving landscape of software development.
“My parents celebrated when I got that job title of developer evangelist,” Okenwa said. “I speak and meet with developers, online or in person, and I talk about the tools and the technologies they’re using. A part of this job is being with the community and then spreading the good news of Twilio as well.”
For those unfamiliar with the company, “Twilio is a customer engagement platform and one of the providers helping businesses with their customer support, communication tools, and APIs.”
The elephant in the room for the Tech industry is the fate of junior developers. Steve Yegge’s provocative piece ‘The Death of the Junior Developer’ has sparked intense debate, suggesting that AI won’t make inexperienced developers smarter but will enable experienced programmers to eliminate the need for juniors altogether. A daunting perspective for young programmers.
Nathaniel offers a more nuanced perspective that challenges this binary thinking .
Often, a company doesn’t hire junior developers for their current capabilities. They recruit them because they’re investing in what they will become in the future. Junior developers need to exist if we are going to have mid-level senior developers, developer leaders, and architects at a later time.
Nathaniel is right. Programming isn’t just about syntax and algorithms; it’s about developing problem-solving instincts, understanding business contexts, and learning to translate human needs into technological solutions.
‘If you want to create the next generation of builders, then I don’t think junior developers are going to disappear in the long term. We may forget how important they are for a little bit, but they will definitely make a comeback later on.’
The urgency of these questions intensified when Eric Schmidt, former CEO of Alphabet, made bold predictions about the timeline for developer displacement. His assertion that developers would be reduced to merely correcting AI output within six months and potentially eliminated entirely within a year sent shivers down the spines of the programming community.
Nathaniel acknowledges the partial truth in Schmidt’s predictions while advocating for a more sophisticated understanding of what developers do. “I think there are elements of truth in it, but I think the situation is a bit more nuanced. AI is, in my mind, another Industrial Revolution. In this context, it means we’ll be looking for repeatable tasks that are extremely simple and how to replace them with technology.”
The industrial revolution analogy is particularly apt here. Just as mechanisation didn’t eliminate human work but transformed it, AI appears poised to reshape rather than replace programming roles. “I think AI is going to take some aspects of programming and make them so cheap from an effort perspective that it’s not necessarily going to be the best use of people’s time. However, I think developers aren’t just folks that are repeatedly solving minor syntax sentences. They are creative builders coming up with different ways of taking a real-world problem and abstracting it into technology pieces.”
One of the most compelling aspects of Nathaniel’s perspective is his emphasis on abstraction as the key to understanding how AI will transform development work. Rather than replacing developers, AI represents another rung on the abstraction ladder that programmers have been climbing for decades.
Right now, I can use my programming skills to build a website and serve it to millions of people on the Internet. Thirty or forty years ago, I would have needed a whole set of different skills to make that happen. I would have needed so many more hardware skills and so many more specific high-level networking skills. And all of those things have been abstracted away for me to really focus on making this website really fast and performant.
This historical perspective illuminates a pattern that AI-anxious people are missing. Each generation of developers has built upon increasingly sophisticated foundations, allowing them to tackle more complex problems without getting bogged down in lower-level implementation details.
The printing press analogy further clarifies this progression: “If we think about the printing press, at first you needed to have lots of people who would sit down and handwrite a book in order for you to make 100 copies. The printing press came around, and the amount of effort and skills to achieve that shrunk considerably. But you still needed someone who could run that printing press.”
However, this progression toward higher abstraction levels raises uncomfortable questions about inclusivity and capability. Not every developer possesses the intellectual agility to continuously climb the abstraction ladder, and there’s value in acknowledging this reality.
Nathaniel addresses this concern with characteristic optimism while maintaining realism. “I suppose there will always be people who remain comfortable doing what they are doing in the ways they are doing it. But with technology making so many more different things available, what’s going to happen is users, customers, and the general public are all going to expect more from our technologies and from us.”
The market forces driving this evolution are relentless. As AI enables higher-quality experiences at scale, customer expectations rise accordingly, creating pressure on all technology providers to evolve or risk irrelevance.
“The folks who aren’t meeting these higher standards of experiences will not be able to deliver the value that their customers and employers are expecting from them. If they don’t continue to meet that bar of expectation that is growing higher and higher, especially as AI helps people to develop new ways of doing this, they will be left behind.”
This raises an interesting paradox about digital transformation that I’ve observed throughout my career in technology consulting. Thirty years ago, we predicted that traditional industries like banking would be disrupted by digital-native competitors. Yet established banks have largely survived, adapting gradually while maintaining their market positions.
Nathaniel offers an insightful perspective on this seeming contradiction: “It didn’t kill banks, but I would argue that even if maybe they took a while to get there, the way we interact with our banks is completely different from the way we interacted with banks when we were younger. There are 18-year-olds who have no idea what a chequebook is.”
The transformation happened, but more gradually and less dramatically than predicted. This pattern suggests that AI’s impact on development may follow a similar trajectory—profound but evolutionary rather than revolutionary.
Perhaps the most practical insight from our conversation concerns how AI tools are being adopted by developers. The success of GitHub Copilot and similar tools demonstrates that integration beats replacement as an adoption strategy.
“Sometimes there are engineers who are reluctant to use AI or don’t want to go out of their way to bring AI into their workflows. But when Copilot came out, when other tools that have that technology built into the applications, the interfaces they are already using, the adoption increases significantly.”
This observation reveals a crucial truth about technology adoption: the most successful innovations enhance existing workflows rather than demanding entirely new ones. The future of development tools lies not in replacing programmers but in making them more effective within familiar environments.
One of the most honest moments in our conversation addressed the reality of code reuse – something every developer practises but few discuss openly. The fear that AI will turn programmers into mindless copy-paste operators misses the historical context of how developers have always worked.
“Copying and pasting has been an integral part of the engineer’s journey for decades, and it’s not going anywhere soon. Even if we are copying and pasting from a different place, and even if we are no longer using Ctrl-C and Ctrl-V, we have always been learning from the code that others write.”
The key distinction lies not in the source of solutions but in the developer’s understanding of what they’re implementing. “The real issue is that of developers who go and find a solution online and copy and paste it without understanding what is going on. Now, if people do that with AI, they may create a black box, and that’s going to be great when it works. But when it doesn’t, when you receive a phone call in the middle of the night, and that production’s gone down, that’s a different kettle of fish. Having a black box is not going to be something that a huge company, a huge enterprise, is going to want to rely on.”
Our conversation touched on one of the most persistent challenges in enterprise software: the prevalence of legacy systems built in languages like COBOL that have resisted modernisation for decades. This serves as a fascinating case study in the relationship between technological possibility and human decision-making.
I think we underestimate the power of people. People are sometimes afraid of change. They sometimes want to rely on what has worked for years. And so, even if AI presents a great solution, it’s going to be people who decide whether to take it on board or not.
This observation cuts to the heart of why technological predictions often prove overly optimistic. Technical feasibility doesn’t guarantee adoption, and institutional inertia remains a powerful force in shaping the pace of change.
For students and emerging developers wondering how to navigate this uncertain landscape, Nathaniel offers pragmatic guidance that emphasises exploration.
“The first thing is to explore and experiment. Experiment with the new technologies. Find out what those new job titles are going to be and chart the path to become an expert. Either a specialist in using AI as a tool, or an expert in creating AI, or an expert in maximising its performance, or an expert in building the tools that AI will use.”
Nathaniel’s emphasis on APIs is particularly noteworthy: “APIs are nothing new. The better your API, the better the AI agents that will resort to it.” This suggests that developers who understand how to build AI-friendly interfaces will find themselves increasingly valuable.
Most importantly, he advocates for focusing on uniquely human contributions: “Don’t just focus on the typical tasks a junior developer is asked to do because AI can do them really well. Instead, focus on the ways that you can bring a unique twist to your solution.”
As our conversation with Nathaniel Okenwa demonstrates, the future of developers isn’t about choosing between human programmers and AI systems—it’s about understanding how these technologies can work together to solve increasingly complex problems. The most successful developers will be those who embrace AI as a powerful tool while focusing on the uniquely human aspects of software development: creativity, problem-solving, and the ability to translate human needs into technological solutions.
In a sense Nathaniel’s advice isn’t that different from Steve Yegge’s. You’ll have to become an expert to make good use of AI; it’s not artificial intelligence that will turn you into an expert.
Rather than fearing obsolescence, developers should view this moment as an opportunity to evolve, much as previous generations adapted to new programming languages, frameworks, and paradigms. The future belongs to those who can harness AI’s capabilities while providing the human insight, creativity, and understanding that no algorithm can replicate.
The future of developers isn’t about replacement—it’s about enhancement, evolution, and the continued pursuit of building technology that serves human needs. In that mission, developers remain not just relevant but essential.
The post The Future of Developers in the Age of AI appeared first on Marketing and Innovation.