AI Is Changing Software Development — But There’s a Catch (ft. Gerardo Estaba)
“Anyone can build software now.”
That sentence would have sounded unrealistic five years ago.
Back then, shipping an application usually meant assembling engineers, architects, DevOps support, cloud infrastructure, authentication, databases, APIs, queues, deployment pipelines, and enough technical knowledge to know what could go wrong before it did.
Today, it is completely different story. A single person with a clear idea, an AI coding assistant, and a modern backend platform can build and launch something real over a weekend.
That is exciting and also slightly terrifying.
Because if AI-assisted development makes it easier for anyone to build, it also raises a much harder question: Can everyone build safely?
That is the centre of our latest episode of What The Tech Podcast (AU).
In this conversation, we sat down with Gerardo Estaba, Solutions Architect at Supabase, to explore how AI is reshaping the software development lifecycle, why the modern stack is becoming simpler, and why the boring parts of engineering — databases, security, architecture, and governance — suddenly matter more than ever.
About the Guest
Gerardo Estaba is a Solutions Architect at Supabase, one of the most widely adopted developer platforms among modern builders today.
He works closely with startups, product teams, and engineering organisations across APAC, helping them design, build, and ship modern applications faster.
Before joining Supabase, Gerardo spent almost nine years at Amazon Web Service, working with engineering teams through the cloud adoption era. That experience gave him a useful perspective on what has changed, what has stayed the same, and what many organisations still get wrong when they think about scale.
This episode is not just about Supabase.
It is about the bigger shift happening across software development:
The stack is compressing. The barrier to building is collapsing. But the foundations still matter.
The Software Stack Is Getting Simpler Again
For years, software teams borrowed architectural ideas from companies like Google, Netflix, and Facebook.
Microservices. Distributed systems. Complex cloud environments. Multiple databases. Layers of orchestration.
For companies operating at internet scale, those decisions often made sense.
But for many teams, especially in markets like Australia, the complexity arrived long before the scale did.
Gerardo puts it bluntly in the episode:
“Engineering teams largely do not have a scaling problem… 99% of the time, engineering teams have a complexity problem.”
That idea sits at the heart of this conversation.
In a world where AI can help people build faster, the cost of unnecessary complexity becomes even higher. Every extra service, every unnecessary abstraction, and every poorly understood integration becomes another place where security, reliability, and maintainability can break.
This is why platforms like Supabase are interesting in the current AI moment.
They do not just help developers move faster. They represent a broader return to simpler foundations: Postgres, authentication, storage, APIs, and security controls sitting closer to the data layer.
The lesson is not that every system should be simple forever; it is that teams should earn complexity.
AI Has Raised the Floor for Builders
One of the most exciting parts of the episode is the discussion around the rise of the non-technical builder.
Tools like Lovable, Claude Code, Cursor, and modern backend platforms have made it possible for founders, operators, designers, domain experts, and internal teams to build working software without starting from a traditional engineering background.
That matters.
Because some of the best product ideas do not come from people who know Kubernetes.
They come from people who deeply understand a problem.
Gerardo describes this as one of the most empowering shifts in AI: giving more people the ability to turn ideas into working products quickly.
This is the optimistic side of the AI development lifecycle.
More people can build.
More ideas can be tested.
More problems can be solved by the people closest to them.
But there is another side to the story.
AI Has Also Raised the Risk
If more people can build software, more people can also accidentally build insecure software.
That is where the episode becomes especially important.
AI can generate code. It can scaffold applications. It can create interfaces, database schemas, and workflows. But it does not automatically understand your compliance obligations, your internal security policies, your data access rules, or the long-term consequences of a poor architectural decision.
Gerardo makes this point clearly:
“The foundations haven’t gone anywhere. The foundations are even more important than ever.”
That line captures the real catch behind AI-assisted development.
The faster we build, the more important it becomes to design systems where security is enforced at the right layer.
Prompting an AI model to “be secure” is not a serious enterprise control. If permissions, access, and data boundaries only live in application code generated by AI, the system is fragile from the beginning.
But if those controls are enforced closer to the data layer, through proven infrastructure patterns such as Postgres row-level security, teams can allow more experimentation while still protecting the organisation.
That is the balance every company is now trying to find:
How do we let people move faster without letting risk move faster too?
Why Postgres Is Having a Moment
One of the most interesting parts of the conversation is Gerardo’s explanation of why Postgres has become so central to modern application development.
For many people, Postgres sounds like an old, boring relational database.
But that is exactly why it matters.
It is mature. It is widely understood. It is open source. It has a massive community. And because of its extension ecosystem, it can now support far more than traditional database workloads.
In the episode, Gerardo talks about extensions like:
PostgREST, which helps expose Postgres through APIs.
pg_cron, which supports job scheduling.
pgvector, which allows teams to store and search AI embeddings directly inside Postgres.
That last point is especially relevant for AI products.
Instead of introducing a separate vector database too early, some teams can keep their application data and AI embeddings closer together, reduce orchestration complexity, and simplify the system.
Again, the theme is not “never use specialised tools.”
The theme is: Do not add complexity before the product has earned it.
What Still Requires Deep Engineering?
This episode also pushes back against the simplistic idea that AI will remove the need for engineers.
Yes, AI is changing the work.
Yes, more code will be written by AI.
Yes, smaller teams will be able to ship more.
But the need for engineering judgement is not disappearing.
In fact, it may become more valuable.
When systems scale, when security matters, when costs need to be controlled, when customer data is involved, and when an AI-generated product needs to become a production-grade business, deep engineering still matters.
Someone still needs to understand the trade-offs.
Someone still needs to know when Postgres is enough, when it needs optimisation, when read replicas make sense, when sharding becomes necessary, and when a simple product has become a serious system.
Gerardo makes this practical near the end of the episode when he mentions that Supabase is hiring people with deep operational Postgres expertise — because running millions of databases still requires serious engineering knowledge.
That might be the clearest answer to the “will AI replace engineers?” question.
AI will change the job.
But the deeper the system becomes, the more valuable real engineering judgement becomes.
The Bigger Shift: From Software Development Lifecycle to AI Development Lifecycle
One of the strongest ideas in the episode is that the traditional software development lifecycle is being compressed.
Planning, designing, building, testing, deploying, and iterating used to happen across teams, tools, meetings, and long delivery cycles.
Now, AI collapses many of those steps into a much faster loop.
Prompt. Generate. Review. Deploy. Iterate.
That does not mean the old lifecycle disappears completely.
But it does mean the shape of software development is changing.
The teams that succeed will not simply be the ones that use AI the most.
They will be the ones that understand where AI accelerates the process, where human judgement is still required, and where strong infrastructure must sit underneath everything.
That is the real message of this episode.
AI is changing software development. But the catch is that faster building requires stronger foundations, not weaker ones.
Listen to the Full Episode
In this episode of What The Tech Podcast (AU), we explore:
How AI-assisted development is changing the way software is built.
Why the traditional software development lifecycle is being compressed.
How platforms like Supabase are helping builders move faster.
Why Postgres is becoming central to modern AI-enabled applications.
What organisations should think about when non-technical users start building production tools.
Why security, compliance, and data access controls need to sit closer to the infrastructure layer.
And what deep engineering still means in the age of AI.
🎧 Listen now on:
📬 You can also subscribe here on Substack for episode breakdowns, reflections, and behind-the-scenes thinking from What The Tech Podcast (AU).
Question for readers
If AI has made it easier than ever to build software, what matters more now:
the speed of building, or the strength of the foundation underneath it?