The changing face of software development in the age of AI
Right now, AI is rewriting the rules for software development - and it's happening fast. The ability to 'code faster' only scratches the surface - the real change lies in the evolving role of developer. There are three key shifts in the age of AI and building 'foundational AI' should be the key focus for forward-looking teams.
Shift one: Developers aren't the only ones writing code
Today's developer is part architect, part quality controller and part conductor. AI tools like Cursor and Replit are now able to handle 30, 40 or even 80 percent of routine code generation for most coding languages. What these tools are great at is writing 'typical' code to solve 'typical' problems. They're fast, productive and sometimes even shockingly effective. But there are important things to consider when using them - they don't know your architecture, your security requirements or how that line of code will interact with your finance system or CRM. They also don't think about edge cases or regulatory implications. They will simply do what you ask; even if it's the wrong thing.
We've already seen what happens when AI tools are deployed without proper guardrails through observing the now-infamous Pak'nSave AI meal bot spectacle. Designed to help customers plan meals from ingredients on hand at home, it suggested dangerous and absurd recipes including combinations that could produce toxic gases. It didn't stop to ask whether something was safe, healthy or legal - it simply did what it was asked.
This fundamentally changes what 'good' looks like. Good developers aren't just typing code - they're shaping ideas into architecture, ensuring security and aligning coding output with business needs. There are 'rough ideas' everywhere; but the bar is rising in terms of quality and developers can add real value by taking a rough sketch and making it fit into a complex, ever-shifting business context.
Shift two: Anyone can code - but not everyone should
We're entering a world of 'vibe coding' in which non-developers use AI tools to spin up simple scripts, chatbots or prototypes. Vibe coding is based on prompts, gut feel or rough ideas and lacks deep planning or architectural consideration. But while vibe coding can be great for experimentation or producing MVPs, it comes with significant risks that include fragile code, poor security and a fast track to technical debt.
The magic happens when vibe coding's speed and creativity are paired with thoughtful software engineering that ensures quality, resilience and fit-for-purpose outcomes. Ease of generation doesn't remove the need for context, governance or quality assurance. The question leaders need to ask is what level of risk are we willing to accept, and where does governance fit into this new speed?
Shift three: Using AI tools vs. building specific AI
Software teams should frequently shift where they are on a spectrum between using AI tools in a product and building AI for a product. Choosing the approach that best fits the problem and their skill set is a key aspect of leading and growing a modern software team.
1. Using AI systems - This involves integrations with AI such as ChatGPT , Claude or LLaMA; and adding internal data and minor algorithms on top. This is where most companies are playing right now and they stitch together AI services and create quick wins. This can be very effective.
2. Building AI specific to a product - This is where the real future lies for companies that want to be unusually successful. These teams don't just integrate; they create proprietary systems, layers, filters and algorithms tailored to specific problems. Usually these will be on top of base models or systems, but there is ownership deep into the stack and has unique data collection. It's the difference between deploying just another chatbot that is adequate at dealing with 60% of queries and building systems that create a customer experience superior to previous standards. For forward-looking teams, the opportunity doesn't lie in replicating what OpenAI or DeepSeek are doing, but in building IP on top with the quality assurance, the context and the expertise to make these tools fit and solve real business problems.
Innovation needs more than permission
One of my favourite sayings is "When a great team meets a lousy market, the market wins." You can replace market with organisation and it's still true. You can't just tell your teams to innovate while leaving barriers, hoops and approval processes in place. Innovation dies in the face of bureaucracy and today's leaders need to create environments where challenging the status quo is rewarded, not punished. Otherwise, all the AI tools in the world won't make a difference.
The ethical debate: overblown or undercooked?
There's plenty of hand-wringing around ethics, copyright and data privacy in AI. Some of that's legitimate; but much of it is fear-driven. Quality control is important for AI - just as it is for all software and for person based services. There is a strong similarity between quality control for AI systems and people based systems. You need to understand the data inputs, assess bias, review output, and encourage transparency. It's impossible to do that without domain expertise and this is challenging for many that seek greater regulation or control.
What we shouldn't do is use these concerns as excuses to become a technical backwater.
The takeaway: resist at your peril
AI isn't coming for developers - it's already here and it's a tool to be used. The nature of the job has changed and banning AI or ignoring it might buy you six months, tops - but it won't stop the rise. Smart teams are leaning in, using these tools to do more, learn faster and build better. The best teams will pair human creativity and judgment with AI's brute-force productivity because that's where the magic happens.
The question for every dev team right now is: are you playing Tetris with today's tech or building something that will still stand when the pieces stop falling?
