DEV Community: Regnard Raquedan

The "AI Sandwich" of Future Tech Jobs

Regnard Raquedan — Thu, 05 Mar 2026 19:35:39 +0000

Ten years ago, I co-founded a startup called CubbySpot and it created a platform that helped parents find child care in Toronto.

I remember hiring an offshore team to help with software development, and I spent a lot of time searching, screening, and eventually hiring the software development team. We spent at least $10,000CAD to develop our Most Viable Product (MVP).

Despite good intentions and best efforts, the startup folded and the code was shelved into the vast obscurity of the Cloud Computing void.

This past week, I tried my hand in modern AI-driven software development, or commonly called vibe coding. The first time I really felt the Software Development Life Cycle (SDLC) turn into the AIDLC. And I figured that a good project to do was to revive CubbySpot from the virtual ashes.

I used a combination of Claude Code, Gemini, Antigravity, GitLab and Firebase (I know, my setup is not the most lean). And within a day, I was able to create a prototype of what I think is a new, lovable MVP.

I remembered the time I was negotiating, cajoling, and directing the software development team and contrasting that to what I had just accomplished with a AI Chief of Staff and an AI Coder. The old MVP took at least two months to get off the ground, the new one was under 24 hours.

This is really the future of productivity in software development and it's happening now.

Now, it's not all rainbows and unicorns with vibe coding.

I encountered the "Last Mile" problem with the AIDLC where there are some bugs in the finished product and the time spent debugging the final 20% spent 80% of my time.

Then I realized this "AI Sandwich" in working with this so-called digital twin: AI will really do all of the heavy lifting in coding, but the real work of people will be done before and after that.

There will be a lot of work defining the guardrails of the AI, writing the requirements, verifying alignment with business and customer needs, and prioritizing scope. There will also be a lot of orchestration and determining which AI agent will do what.

Once the code is done, there will be a lot of work directing where the deployment will be, doing the requisite QA, and evaluating if the objectives and goals were met. And of course, the roll out and operationalizing of the said software will be another track to do.

My advice to white collar professionals now is to get ready and prepare for the pre- and post- work that will go along with the work that AI will do. Embrace this AI Sandwich and aim to thrive.

Otherwise, you will be chewed out by the industry.

AI is a lot of things, but it's a Lever.

Regnard Raquedan — Mon, 23 Feb 2026 20:24:42 +0000

One thought I had on AI recently was sparked by simple machines.

Basically the "force multiplier" effect you may have already seen or hear, AI is like a lever where it multiplies your effort to lift a load. You can 5x your capabilities with AI especially if you are skilled in your domain of expertise.

However, if you are not skilled yet, AI can only enhance that limited capability. You still need to develop the domain expertise. That will help you create better prompts, understand the generated content, and verify that the AI-produced content is accurate.

Using a simple math model, if you're a experienced knowledge worker and your skill level is a 8/10 and AI will multiply your skill and productivity 5-fold, imagine the effect to someone with a skill level 1/10 with a 5x effect-- they are still less skilled that experienced person.

This is why there's data that suggests that senior developers are thriving with AI and the beginners are spinning their wheels with AI in their workflows. The seniors are optimizing and refining their battle-tested approaches while the junior devs are seeing hieroglyphics. That can create a productivity gap with the same tools and same AI models.

There is no silver bullet to close this gap. Skill-building and upskilling will be part of that conversation to ensure AI will be the same force multiplier for everyone.

If you haven't already, deepen you domain knowledge while getting up to speed on AI tools.

The AI Agent Revolution: Are We All Full-Stack Developers Now?

Regnard Raquedan — Tue, 22 Apr 2025 00:34:37 +0000

It was impossible to miss the dominant theme at Google Cloud Next ‘25: AI Agents. Seeing the sheer focus on agents, coupled with practical integrations like GitLab's recent release of GitLab Duo leveraging Amazon Q, has solidified a thought I've had: the traditional lines between developer specializations are blurring very quickly:

Are AI Agents effectively turning all developers into full-stack developers?

I’m convinced the industry is trending that way.

For years, the software development landscape often demanded deep specialization. You were a front-end developer, a back-end developer, a database expert, or a DevOps engineer.

Staying current meant constantly learning the ‘programming language du jour.' While that deep expertise certainly hasn't lost its value, the necessity of mastering every layer just to be productive across the stack is decreasing, thanks to AI.

I don't necessarily need immediate and intimate knowledge of every framework or configuration nuance to get started or contribute meaningfully across different domains. Why? Here's my take:

Because AI and, more specifically, AI Agents are becoming very quick knowledge sources and translators.

They can generate boilerplate code in unfamiliar languages, suggest configurations for cloud services I haven't touched before, explain complex legacy systems, and even help debug intricate deployment issues.

These agents act as bridges, filling the immediate tech skill gaps and dramatically shortening the learning curve. They empower us to operate effectively across the entire development lifecycle, embodying a new kind of full-stack capability.

Now, let's address the skepticism. We can collectively roll our eyes at the notion of AI assistance in development, like "Vibe Coding." And yes, there's a valid concern that over-reliance on AI could potentially stifle foundational learning. However, I believe framing the current shift based on that misses the bigger picture.

This isn't about blindly trusting AI to write mission-critical code without oversight. ("Can AI drop a database?") It's about strategic automation. Imagine AI Agents handling unit testing frameworks, managing complex deployment pipelines across multi-cloud environments, securing workloads before they get to production.

When AI Agents reliably take care of these crucial, yet often time-consuming and repetitive tasks, it doesn't make developers redundant. It liberates us.

Agentic AI-supported development frees up invaluable time and effort for the tasks where human ingenuity truly shines: architectural design, understanding nuanced user requirements, and tackling complex problem-solving. This is the real future of software development: a killer combo of human creativity and AI efficiency.

The announcements from Google Cloud Next '25 and the tangible tools emerging in the cloud ecosystem aren't just incremental updates; they signal a fundamental shift.

We're moving towards a reality where developers are less defined by the specific tools they've mastered and more by their ability to leverage AI to build, deploy, and manage applications holistically.

The era of the AI-augmented, full-stack developer isn't just coming – it's already starting to unfold.

Clear Link Between DevSecOps and Data Engineering

Regnard Raquedan — Fri, 13 Sep 2024 16:16:18 +0000

I recently cleared the AWS Data Engineering - Associate certification, and I would say that my background as a Solutions Architect at GitLab helped a lot. In fact, almost became an exercise of translating stock knowledge obtained at work.

No, there's not a cheat code, but I came to this realization that prompted me to pursue the certification:

DevSecOps and DataEngineering are virtually the same practice with different workloads.

BOOM. 😳

Being in the space made me see the similarities. Both involve:

1️⃣ - Pipelines & orchestration design

2️⃣ - Automation

3️⃣ - Security & governance

Data pipelines and CI/CD pipelines are really just different flavors of the same thing. In CI/CD, you’re building and shipping code; in data engineering, it’s about moving, transforming, and loading data.

Both need airtight orchestration to keep things running without blowing up. Automation? That’s table stakes in both. Cut out the manual junk and let the system do the heavy lifting.

And don’t get me started on security. Whether it’s code or data, if you’re not locking things down, you’re just asking for trouble. The same rules apply: security needs to be baked in, not bolted on, from the start.

My work at GitLab has given me a perspective on CI/CD, which really ties in very neatly to modern data engineering practices. It’s great how much crossover there is once you start looking at the big picture.

Translating an Azure Serverless App Architecture into AWS

Regnard Raquedan — Wed, 23 Feb 2022 15:32:56 +0000

In my last post, I made a cheat sheet to help cloud architects translate services between Microsoft Azure and AWS. It was well-received by the community, and I thought of ways how to make these translations more useful for the community.

If you're like me, I've been working between Azure and AWS, and it's starting to feel like working between two programming languages, like JavaScript and Python. I find it a good and useful exercise to keep abreast with the analogous services between the two major cloud platforms. (Multi-cloud folks would have a different opinion on this, but I digress.)

Azure Reference Architecture

A possible way to make this translation more tangible is to take a look at existing architectures and see what it looks like with another cloud service. I found this simple and elegant serverless web application architecture from Azure:

Translated AWS Architecture

I translated the Azure-based application into AWS and here is what it looks like:

Let's do a quick breakdown of the AWS services:

S3 - This is where the static files will be stored, like HTML, CSS, and JavaScript files.
CloudFront - We will use this as our Content Delivery Network to enable caching content and accelerate delivery of content, as well as providing an HTTPS endpoint.
Lambda - The key engine that makes this work.
API Gateway - As the name implies, it will provide as the access point for the application.
RDS - The application's data store.
Single Sign-On - This is the equivalent to Azure's Active Directory for user authentication.
CloudWatch - Although not technically part of the application, this helps us monitor the performance and infrastructure data collection.
CodeDeploy - Modern web applications need a seamless and easy workflow. CodeDeploy is the tool for the CI/CD for building, testing, packaging, and deploying.

In closing, I hope this helps you see Azure to AWS translation more than just a conversion, but also provide some insight on how these services integrate.

👉🏻 Follow me on Twitter

AWS-Azure Mapping Cheat Sheet

Regnard Raquedan — Thu, 26 Aug 2021 20:15:03 +0000

Between Amazon's AWS and Microsoft's Azure, you have two-thirds of the world cloud computing infrastructure market share-- with AWS having twice the size of Azure's slide of the pie.

That's why you have people like me who straddle back and forth between the two cloud behemoths, and the services can become hard to keep track of.

It's relatively easy when you're dealing with the building block services like EC2 Instances in AWS and Virtual Machines in Azure, but it gets a little confusing when you're looking at more advanced services, like the service equivalent to AWS CodeCommit (Spoiler: it's Azure DevOps).

This information is handy too when you're preparing for a certification exam. Fundamental-level certifications like Azure Fundamentals (AZ-900) and AWS Certified Cloud Practitioner (CLF-C01) covers a very broad range of services, and it's very likely that you will find yourself “translating” between AWS and Azure.

One important thing to note is that mapping each service 1:1 might not be possible, but feature parity might be achieved by a combination of services.

Using the exam objectives of the AWS Certified Cloud Practitioner exam, here's a cheat sheet to lay out the mapping:

1. Compute services

AWS	Azure
Elastic Compute Cloud (EC2)	Virtual Machine (VM)
Auto-scaling	VM Scale Sets
Elastic Container Services	Container Instances
Lambda	Functions

2. Storage services

AWS	Azure
S3	Blob Storage
Elastic Block Storage	Storage Account
S3 Glacier	Archive storage
Snowball	Data Box
Elastic File System	Files
Storage Gateway	StorSimple

3. Networking services

AWS	Azure
Virtual Private Cloud (VPC)	Virtual Network
Route 53	DNS
Direct Connect	ExpressRoute

4. Database services

AWS	Azure
RDS	SQL Database
DynamoDB	Cosmos DB
Redshift	Synapse Analytics

5. Cost management

AWS	Azure
Trusted Advisor	Advisor
Cost Explorer	Cost Management
QuickSight	Power BI
Organizations	Subscription Management

This list is not exhaustive by any means, but I think it's a good starting point to help you with the high-level AWS-Azure mapping. Also, if I got anything wrong, I welcome your feedback!

👉🏻 Follow me on Twitter