DEV Community: TAGBA G-Josaphat E.

AI Is Killing the SaaS Model. And I Think That's a Good Thing.

TAGBA G-Josaphat E. — Sat, 27 Jun 2026 10:36:02 +0000

I'll be honest with you.

The last time I considered paying for a SaaS product, I caught myself thinking: "Wait. Could I just build this myself?"

And the answer, increasingly, is yes.

That moment changed something in how I see the software industry.

AI democratized building. Nobody fully processed what that means yet.

A few years ago, building a working web app required real technical depth. Months of learning. A team. Infrastructure knowledge. It was a high barrier and SaaS products existed precisely because most people couldn't build their own tools.

That barrier is collapsing.

With AI, a developer even a junior one can now conceive, design, and ship a functional application in days. Not months. A solo student in their bedroom can build what used to require a funded startup.

And here's the logical consequence nobody talks about enough: if anyone can build software, why would they pay someone else for it?

I already think this way. And I don't think I'm alone.

Before subscribing to any tool now, I ask myself three questions:

Do I actually need all the features this SaaS offers, or just 20% of them?
Could I build a lightweight version that does exactly what I need?
Would maintaining it be worth the subscription cost?

More and more often, the answer points toward building my own version.

Not because I'm cheap. But because AI makes it genuinely faster and easier to build a custom solution than to adapt my workflow to someone else's product.

A personal project management tool. A custom dashboard. A note taking app with exactly the features I want. A budget tracker built around my actual habits.

Why pay $12/month for a tool that does 80% of what I need when I can build 100% of what I need in a weekend?

The SaaS products that will suffer

Not all SaaS will die. But I think a specific category is in serious trouble: the simple, single-purpose tools.

The ones that do one thing. Solve one problem. The ones where the value proposition is essentially: "We built this so you don't have to."

That value proposition just got a lot weaker.

If your product's entire moat is "we wrote the code and you didn't have to" AI just erased your moat.

Think about:

Simple form builders
Basic invoice generators
Lightweight project trackers
Note-taking apps with no unique angle
Simple landing page builders

Every single one of these is now buildable by a motivated developer with AI assistance in a weekend.

The SaaS products that will survive

The ones that survive will have something AI-assisted solo development can't easily replicate:

Network effects value that comes from other users being on the platform
Data moats insights and intelligence that come from aggregating millions of users' data
Deep integrations years of ecosystem connections that would take months to rebuild
Compliance and trust regulated industries where "I built it myself" isn't good enough
Scale infrastructure the kind of backend complexity that goes far beyond a weekend project

Notion, Stripe, Figma, Linear, these aren't threatened by someone building their own version. They offer something fundamentally hard to replicate alone.

The $9/month form builder with no unique angle? That's a different story.

What this means for developers building SaaS today

If you're building a SaaS product right now, I think this is the most important question you need to answer honestly:

Could a motivated developer with AI assistance replicate your core value in a weekend?

If the answer is yes you have a problem. Not an immediate one. But a growing one.

The market for "we built this so you don't have to" is shrinking. The market for "we built something you genuinely couldn't build yourself" is still very much alive.

My honest take

I think we're entering a world where software splits into two categories:

Personal, custom tools built by individuals for themselves, free, perfectly tailored, AI-assisted
Platform-scale products with network effects, data, compliance, and infrastructure that individuals can't replicate

The middle ground the simple paid SaaS with no unique moat is going to get squeezed from both sides.

And honestly? I think that's good for users. We've been paying subscription fees for tools that were always a little too generic, a little too bloated, a little too expensive for what they actually delivered.

AI is giving us a way out.

What do you think are you starting to build your own tools instead of paying for SaaS? Or do you think paid products will always have an edge that self-built tools can't match?

This is part of a series where I share my honest thoughts on AI, learning, and building in tech.
*Follow along on Facebook

Is AI Making Us More Vulnerable? The Growing Threat of Cyberattacks in the AI Era

TAGBA G-Josaphat E. — Tue, 16 Jun 2026 18:55:50 +0000

Something feels different about security incidents lately.

Breaches, leaks, account takeovers, phishing campaigns they're not new. But their frequency, sophistication, and scale seem to be growing at a pace that feels genuinely alarming.

Instagram accounts hacked overnight. Corporate systems compromised in hours. Phishing emails that sound disturbingly human.

As someone studying AI & Big Data, I can't help but ask: is AI responsible for this? And if so, how?

I think the honest answer is: yes but in two very different ways.

The two faces of AI in cybersecurity

When we talk about AI and cyberattacks, most people imagine one scenario: hackers using AI to attack systems faster and smarter.

That's real. But it's only half the picture.

The other half is something we talk about far less: the vulnerabilities that come from integrating AI into systems in the first place.

These are two very different problems. And conflating them leads to the wrong solutions.

Problem 1: AI is expanding the attack surface

Every time a platform integrates an AI feature, they're adding something new to their infrastructure. And new infrastructure means new potential vulnerabilities.

AI systems require:

Massive data pipelines more data flowing through more systems
APIs connecting multiple services more endpoints that can be exploited
Third-party models and tools more external dependencies, more trust relationships
Real-time processing less time to detect anomalies before damage is done

Many organizations are integrating AI features faster than their security teams can audit them. And the consequences are already visible.

In June 2026, hackers reportedly manipulated AI-powered support systems to gain unauthorized access to Instagram accounts. The attack didn't target traditional software vulnerabilities it targeted the AI system itself, exploiting the automated account recovery flow that Meta had built with AI.

This is the new reality: attackers are no longer just targeting your code. They're targeting your AI pipelines, your automated flows, your trust relationships.

We've also seen entirely new categories of AI-specific attacks emerge:

Prompt injection tricking AI systems into ignoring their safety rules
Model poisoning corrupting training data to manipulate AI behavior
API abuse exploiting poorly secured AI endpoints to extract data or bypass authentication

Problem 2: Your supply chain is now a weapon

If you're a JavaScript developer, this one should concern you directly.

On May 11, 2026, between 19:20 and 19:26 UTC just six minutes an attacker published 84 malicious versions across 42 @tanstack/* npm packages. If you've built anything with React or modern JS tooling, you've almost certainly used TanStack. @tanstack/react-router alone has over 12 million weekly downloads.

The attack was elegant and terrifying. The attacker forked a TanStack repository, submitted a malicious commit, and triggered GitHub Actions to automatically build and publish the malware poisoning the CI/CD cache in the process. No npm tokens were stolen. The pipeline itself became the weapon.

The malicious packages could silently exfiltrate AWS credentials, GitHub tokens, SSH keys, and .npmrc contents automatically, on every developer machine that ran npm install.

The blast radius extended far beyond TanStack. Grafana Labs, OpenAI, and Vercel were all impacted through downstream dependencies. Other compromised packages included tools from Mistral AI, Bitwarden, and Aqua Security.

This wasn't an isolated incident either it was the fourth wave of an ongoing campaign by a threat group called TeamPCP, using a self-replicating worm dubbed "Mini Shai-Hulud."

The lesson? Every npm install is a trust decision. And most of us make hundreds of them without thinking.

Problem 3: Hackers are using AI to attack smarter

On the other side of the equation, the people attacking these systems are also using AI and it's fundamentally changing what attacks look like.

Phishing used to be easy to spot. Broken English, obvious templates, suspicious links. Most people learned to recognize them.

Now? AI generates phishing emails that are grammatically perfect, contextually relevant, and deeply personalized. It can scrape your LinkedIn, your GitHub, your public social profiles and craft a message that sounds like it came from your actual manager.

Microsoft tracked a phishing platform called Tycoon2FA that generated tens of millions of phishing emails per month and was linked to nearly 100,000 compromised organizations. At its peak, it accounted for roughly 62% of all phishing attempts Microsoft was blocking monthly. It didn't just steal passwords it intercepted MFA tokens in real time, defeating two-factor authentication entirely.

Nation-states are in this too. Microsoft and OpenAI confirmed that threat actors aligned with China, Iran, North Korea, and Russia are actively using large language models to enhance their offensive operations reconnaissance, scripting, social engineering at scale.

Voice cloning, deepfake video, AI-generated text all now available to attackers at low cost. What used to require an expert team can be done today with the right prompts and a modest budget.

So which is it AI in systems, or AI as a weapon?

Both. And they compound each other.

Organizations are rushing to integrate AI features to stay competitive, often outpacing their security practices. At the same time, attackers are rapidly adopting AI to improve their techniques. The result is a widening gap between attack capability and defense readiness.

It's not that AI is inherently dangerous. It's that speed of adoption without security rigor creates windows of vulnerability that sophisticated attackers are very good at exploiting.

Sam Altman himself acknowledged the possibility of a "world-shaking cyberattack" in 2026 as AI capabilities accelerate. That's not fear-mongering it's a signal that even the people building these systems know we're in uncharted territory.

What this means for you as a developer

A few concrete things worth thinking about:

Audit your dependencies the TanStack incident proves that even massively popular, well-maintained packages can be compromised
Harden your CI/CD pipelines GitHub Actions cache poisoning is a documented, repeatable attack class
Treat AI integrations like any third-party dependency understand their failure modes, limit their permissions
Be skeptical of any input that reaches an AI model prompt injection is real and underestimated
Educate your users the human layer is still the most exploited vector, and AI is making social engineering much harder to detect

The question I keep coming back to

We're in a moment where AI is being embedded into everything build pipelines, support systems, authentication flows faster than our collective ability to understand the risks.

The attacks we're seeing aren't theoretical anymore. They hit tools we use every single day.

So here's what I want to know: as a developer, how are you thinking about security in your own projects? Has the TanStack incident changed how you approach your dependencies?

Drop your take below especially if you've been directly affected by a supply chain attack.

This is part of a series where I share my honest thoughts on AI, learning, and building in tech *
*Follow along on Facebook

Learning to Code in the AI Era Feels Broken. And Nobody Talks About It.

TAGBA G-Josaphat E. — Wed, 10 Jun 2026 20:51:13 +0000

Let me be honest about something uncomfortable.

When you're learning to code today really learning, from scratch, fighting with syntax errors and logic bugs and CSS that refuses to behave there's a voice in the back of your head that won't shut up.

"AI could do this in 3 seconds."

That voice is brutal. And I think it's making learning harder than it's ever been.

When I started, AI wasn't there to do it for me

I started web development a few years ago. JavaScript was confusing. CSS felt like a random guessing game. I spent entire evenings debugging a function that turned out to have a missing semicolon.

But here's the thing: there was no shortcut. I had to figure it out. The struggle wasn't optional it was the path.

Every bug I fixed alone left a mark. Every concept I finally understood after hours of confusion became part of how I think as a developer.

Now I look at someone just starting out in 2024-2025 and I wonder: what is their path?

The new frustration nobody prepares you for

Imagine spending three days trying to understand how async/await works in JavaScript.

You watch tutorials. You read docs. You write broken code, fix it, break it again. You're exhausted.

Then a friend casually says: "Just ask ChatGPT, it'll write the whole thing for you."

And it does. Perfectly. In 4 seconds.

That feeling I don't have a perfect word for it. It's somewhere between frustration, discouragement, and a quiet existential question: why am I even doing this the hard way?

For someone just starting out, that feeling can be enough to make them quit. Or worse to never really start learning at all.

The gap between using and understanding

Here's what worries me most about the current moment.

There's a growing gap between two types of people in tech:

Those who can use tools to build things
Those who understand what's happening under the hood

AI is making the first group explode in size. Anyone can ship a working app today with minimal technical knowledge. That's genuinely amazing.

But the second group the people who truly understand systems, who can debug when things break in unexpected ways, who can make real architectural decisions that group is built through struggle. Through learning the hard way.

And right now, we're making the hard way feel pointless.

The basics still matter. Maybe more than ever.

I learned HTML before I touched any framework. I wrote vanilla JavaScript before I used Vue or React. I understood what a loop actually does before I let anyone human or AI write one for me.

That foundation is why I can look at AI-generated code and know if it's good, bad, or dangerous. It's why I can debug when things break. It's why I can have opinions about architecture instead of just accepting whatever the AI gives me.

If you skip the basics, you don't become a developer. You become dependent on a tool you don't understand.

And tools break. Tools change. Tools have limits you can't see if you don't know what's underneath.

So. Vibe coding.

If you haven't heard the term: vibe coding is the idea of building software almost entirely through AI prompts, with minimal traditional coding. You describe what you want, the AI builds it, you iterate.

Some people think it's the future of development. Some think it's a dangerous shortcut. Most of us are somewhere in the middle, figuring it out.

I genuinely don't have a definitive answer. But I have a question I keep coming back to:

If a new developer today learns entirely through vibe coding never really wrestling with the fundamentals what kind of developer are they in 5 years?

Are they more creative and productive because they offloaded the boring parts?

Or are they fragile, because they built on a foundation they never actually learned?

I don't know. But I think how we answer that question will define what "being a developer" means in the next decade.

What do you think? Should beginners learn the basics the hard way before touching AI? Or is vibe coding a legitimate new path into tech? Drop your take below I really want to know.

This is part of a series where I share my honest thoughts on learning, AI, and building a career in tech.
Follow along on Facebook

The Hidden Problem With Learning Through AI

TAGBA G-Josaphat E. — Wed, 03 Jun 2026 19:44:06 +0000

AI is an incredible learning tool. I said it in my previous article, and I still believe it.

But after spending months learning new web frameworks and technologies with AI as my main companion, I noticed something uncomfortable.

I was moving fast. But was I really understanding?

The old way was painful and powerful

Before AI, learning a new technology meant suffering.

You'd hit a bug. You'd search for hours. Read Stack Overflow threads, YouTube videos. Try things that didn't work. Get frustrated. Sleep on it. Come back the next day and finally click. It works.

That process was slow. Sometimes humiliating. Often exhausting.

But here's what I didn't realize at the time: that struggle was doing something to my brain.

Every hour spent searching, failing, and retrying was building a deep, almost physical understanding of the concept. When I finally found the solution, I owned it. I knew not just the answer, but every wrong path around it.

Now I just ask. And get an answer. Instantly.

With AI, that whole painful loop collapses into a single message.

Bug? Ask AI. Confusing concept? Ask AI. Don't know the right syntax? Ask AI.

The answer comes in seconds. Clean. Well-explained. Usually correct.

And I move on.

The problem is: moving on is not the same as understanding.

What I actually noticed

Learning Vue, Nuxt, and other web technologies with AI, I realized something: I needed to build far more projects than before to reach the same depth of understanding.

Without AI, one difficult project could teach me something deeply because I had wrestled with every problem alone.

With AI, I could finish that same project twice as fast, but the understanding was shallower. I had to build three or four more projects to reach the same level of genuine comprehension.

The friction wasn't just wasted time. The friction was the learning.

This doesn't mean AI is bad for learning

I'm not saying we should go back to suffering alone for hours.

What I'm saying is: we need to be intentional.

A few things that help me:

Try first, ask second. Before asking AI, I give myself at least 15-20 minutes to struggle alone. The struggle primes my brain to actually absorb the answer.
Ask AI to explain, not just fix. Instead of "fix this bug", I ask "why is this happening and what does it teach me about how this framework works?"
Build more, copy less. More small projects from scratch. Less copy-pasting AI-generated code without understanding it.

The bottom line

AI accelerates learning. But depth still comes from doing really doing and from the discomfort of not knowing yet.

The goal isn't to avoid AI. It's to use it without losing the struggle that makes knowledge stick.

Have you felt this too? Are you learning faster but sometimes feeling like things don't fully sink in? Let's talk in the comments.

Follow my journey on Facebook I share thoughts on tech, learning, and building in the open.

I'm a Master's Student in AI & Big Data. And AI Just Gave Me My Freedom Back.

TAGBA G-Josaphat E. — Tue, 26 May 2026 16:37:13 +0000

I'm currently preparing my Master's degree in AI & Big Data.

You'd think that means I spend my days confidently building neural networks, designing data pipelines, and shipping ML models. And in a way, yes — that's the curriculum.

But here's the thing no one really talks about in tech education: we learned a lot of things, and almost none of them deeply enough.

The paradox of a broad curriculum

In my program, we covered a bit of everything. Machine learning. Big Data architecture. Statistics. Cloud infrastructure. Web development. Databases. Computer vision. NLP.

Every few weeks, a new topic. Every few weeks, just enough to understand the surface before moving on.

I don't blame my professors or my school. That's just the nature of a two-year program trying to give you a panoramic view of a field that's enormous.

But it left me with a strange feeling: I knew about a lot of things, but I couldn't really do most of them.

And as graduation gets closer, the pressure grows: pick a lane. Choose a specialty. Decide who you are professionally.

Web developer? Data engineer? ML engineer? Backend dev? DevOps?

I had to choose — because that's how the job market works.

The cost of choosing

Here's what hurt the most about that choice: curiosity doesn't disappear when you pick a lane.

I chose to focus on web development alongside my studies — Vue/Nuxt, JavaScript, TypeScript, CSS. I love it. But I've always been drawn to everything else too.

I'd look at a computer vision project and think: "I want to build something like this."

I'd see a cool data pipeline and think: "I want to understand how that really works."

I'd read about systems programming, DevOps, mobile development, and feel that familiar pull.

But exploring those domains felt expensive. Not in money — in time and frustration. The entry cost for any new technical field is high: new syntax, new mental models, new tooling, new vocabulary. You spend weeks just getting comfortable before you can do anything interesting.

And with a Master's thesis, coursework, and personal projects already fighting for my attention, that entry cost was almost always too high.

So I held back. I watched from the edges.

Then AI changed the equation

When I started using AI as a learning companion — not just to generate code, but to actually explore — something shifted.

The entry cost dropped dramatically.

Now when I'm curious about something new, I don't have to start from zero alone. I have a thinking partner that:

Explains new concepts by connecting them to things I already know
Helps me read and understand code from domains I'm not fluent in
Answers the "dumb" questions I'd be embarrassed to ask anyone else
Turns a confusing error message into an actual learning moment

Want to understand how a Kafka pipeline works? I can explore it in a real conversation, mapped to my existing mental models — not by reading a dense 40-page documentation for two weeks.

Curious about how a specific ML architecture actually processes data? I can dig into it interactively, ask follow-up questions, build a mental picture.

The translation layer that used to take weeks now takes a conversation.

This is not about shortcuts

I want to be honest here, because I know how this sounds.

This is not about having AI do everything for me. It's not about faking expertise I don't have.

It's about removing the fear and friction of being a beginner in something new.

I still struggle. I still hit walls. I still have to put in real work to actually understand things. But now I can get to the interesting part — the part where concepts click, where I can build something small, where curiosity turns into real knowledge — without burning weeks just fighting the setup.

That changes everything about how willing I am to explore.

What I actually believe now

For a long time, I thought choosing one specialty was the only responsible path. The market rewards experts, right? Go deep. Become the AI person, or the frontend person, or the data person.

But I've started to think that framing was always a bit off.

The most impactful people in tech I look up to aren't people who know one thing incredibly well. They're people with wide peripheral vision — who understand enough about different domains to connect ideas, ask better questions, and see things that pure specialists miss.

AI didn't make me a generalist overnight. But it gave me permission to be curious without guilt, and the tools to turn that curiosity into something real.

Where I am now

I'm still a Master's student in AI & Big Data. Still building in Vue/Nuxt. Still figuring out what my career will look like.

But I no longer feel like I have to wall myself off from everything that isn't my specialty.

I explore data engineering because it helps me understand the full picture of what I'm studying.

I write frontend code because building things that people can see and touch keeps me grounded.

I poke at ML projects not because I'll be an ML researcher, but because understanding them makes me better at everything else.

Am I an expert in all of these? Absolutely not.

But am I afraid of any of them? Not anymore.

Are you also a student or early-career dev who feels pressure to specialize? How do you handle the tension between depth and curiosity? I'd love to hear your experience in the comments.