DEV Community: Jonathan Sherpa

I don't want to be a ML engineer who trains models.

Jonathan Sherpa — Sat, 05 Sep 2026 16:01:07 +0000

I don’t just want to train a model in a Jupyter notebook and call it an ML project.

I want to understand how to take that model and turn it into something people can actually use.

Data → Model → API → Backend → Database → Deployment → Production

I want to understand every step.

And this is where I’ve started thinking about AI-assisted development.

Vibe-coding has become incredibly popular, and what I’d call “AI brain-rot” can become a form of cognitive offloading — where we stop solving problems ourselves because a tool can solve them for us.

And I don’t think cognitive offloading itself is necessarily bad.

The problem starts when we stop trying to understand what we’re building.

Because, in my perspective, something fundamental about engineering disappears when a project becomes:

Ctrl+C → Ctrl+V → It runs → Deploy.

But where is the joy?

Where is the satisfaction of figuring out why something works?

For me, software engineering is about taking something that exists in my head and turning it into something that exists in the real world — something useful, something people can interact with, something I can look at and say:

“I built this.”

And thinking about what ML can eventually do honestly gives me goosebumps.

I’ve always been a romanticist and a huge sci-fi movie fan.

TARS from Interstellar and JARVIS from Iron Man have probably influenced my interest in AI more than I realized.

Because they represent something fascinating to me:

Technology that doesn’t just execute commands, but understands context, assists its human, makes decisions, and interacts with the world around it.

Now imagine combining that kind of intelligence with modern AI, robotics, and increasingly capable autonomous systems.

Maybe one day we’ll build systems that feel much closer to those fictional assistants.

Maybe they’ll become AI companions, assistants, or something we haven’t even imagined yet.

I don’t know exactly what the future will look like.

But I know I want to understand how these systems are built.

I don’t want AI to think instead of me.

I want AI to make me a better engineer.

And I don’t want to merely use the AI revolution.

I want to understand it — and eventually build a part of it.

Are We Forgetting Software Engineering in the Race Toward AI/ML?

Jonathan Sherpa — Mon, 31 Aug 2026 03:18:10 +0000

First of all, I warmly welcome everyone out there in the DEV Community.
[Completely open for discussion — drop your thoughts below.]

From my perspective, it feels like everyone is racing towards AI/ML.

The moment someone says they want to become an AI/ML Engineer, the conversation immediately shifts towards:

Python → ML → Deep Learning → LLMs → Latest AI Tools

And thinking about it, well, it’s quite understandable too.
AI is one of the most exciting areas in technology right now.

BUT, I have a question…

Why are we starting to treat AI/ML Engineering as something completely different from Software Engineering?

I often see people following an extremely narrow path towards AI/ML while completely skipping the fundamentals of Software Engineering.

Backend development gets ignored.
Databases, networking, operating systems, system design — all of them get ignored.

And afterwards:
APIs, deployment, testing, distributed systems…
All of these seem quite trivial, right?

Because the end goal is simply to create or automate something with AI.
But it’s quite clear to me that AI can’t possibly live by itself.

For any AI model to thrive, we need data.
That data needs storage and pipelines.
A model needs an application around it.
That application needs APIs.
Those APIs need backend infrastructure.

And now we have an actual system.
That system needs to be monitored for bugs, optimized for CPU and memory efficiency, refactored when necessary, maintained over time, and tested against new use cases.

So thinking about all of this:

How does one even fathom becoming an AI/ML “Engineer” without understanding what they are actually engineering into and working on?

Maybe AI/ML Engineering and Software Engineering aren’t two completely different entities.

Maybe they are different components of the same system.

Now, I’m not saying:
“You should become an expert in everything.”
Specialization is indeed important.

But specialization doesn’t necessarily mean abandoning the fundamentals that the specialization is built upon.

This reminds me of a parable a friend once told me.

Consider these two paths:

Python → ML → Deep Learning → AI

It’s like building a strong house specialized in ML on top of a foundation built on sand.

Eventually, the system encounters real-world problems — unexpected failures, scaling issues, security vulnerabilities, inefficient infrastructure, broken data pipelines — and suddenly that beautiful house starts falling apart.

But consider this path:

Programming → CS Fundamentals → Software Engineering → Backend/Systems → Data → ML → AI

Now you’re building that same house on a strong foundation.

The house can still specialize in ML.
But when the environment changes, the foundation doesn’t collapse.

And perhaps that’s the part we’re forgetting.
AI/ML isn’t happening in isolation.

We’re still building software.

So I’ll end with the same recurring question:

Are we specializing too early in AI/ML and forgetting that, underneath all of it, we’re still building software?

I’d genuinely love to hear what other developers think about this.

Deploying Lovable to Vercel — Cracked"

Jonathan Sherpa — Sat, 30 May 2026 19:32:31 +0000

🚀 Live demo: urljourney.vercel.app

Deploying Lovable + TanStack Start to Vercel kept throwing 404s and "No Output Directory" errors no matter what I tried. After hours of debugging, here's exactly what was wrong and the 2-file fix.

What Lovable Generates:
Lovable scaffolds projects using TanStack Start with Nitro as the server engine. This is a full-stack SSR framework, not a static site.
That's the root cause of every Vercel deployment problem.

Why It Fails Out of the Box
Problem 1: Vercel expects public/ but gets nothing
Vercel assumes a static site. TanStack Start + Nitro outputs a server bundle.
So you get:
No Output Directory named "public" found after the Build completed.

Problem 2: Setting outputDirectory: "dist/client" gives 404
Even after pointing Vercel to dist/client, every route returns 404. TanStack Start uses SSR — every route needs the Nitro server to handle it.
Without the server running, nothing works.

Problem 3: The rewrite trick doesn't work
Adding this to vercel.json:
json{ "source": "/(.*)", "destination": "/dist/server/server.js" }
...fails because dist/server/server.js is just an error logger, not the actual server entry.

Problem 4: Vercel functions runtime syntax is wrong
Trying "runtime": "nodejs20.x" throws:
Function Runtimes must have a valid version, for example now-php@1.0.0

Problem 5: Default Nitro preset is Cloudflare, not Vercel
The @lovable.dev/vite-tanstack-config comment in vite.config.ts says:

"nitro (build-only using cloudflare as a default target)"

A Vercel preset exists in Nitro but it's never used unless you explicitly set it. That's the real fix.

The Fix (2 Files)
Step 1: Update vite.config.ts
tsimport { defineConfig } from "@lovable.dev/vite-tanstack-config";

export default defineConfig({
tanstackStart: {
server: { entry: "server" },
},
nitro: {
preset: "vercel",
output: {
dir: ".vercel/output",
serverDir: ".vercel/output/functions/__server.func",
publicDir: ".vercel/output/static",
},
},
});
Step 2: Create vercel.json
json{
"buildCommand": "npm run build",
"outputDirectory": ".vercel/output",
"framework": null
}
Step 3: Build and verify locally
bashnpm run build
ls .vercel/output/

Should show: config.json functions/ static/ nitro.json

Step 4: Commit and push
bashgit add vite.config.ts vercel.json
git commit -m "fix: use nitro vercel preset with prebuilt output"
git push

Why This Works
Nitro's Vercel preset generates .vercel/output in Vercel's Build Output API v3 format:
.vercel/output/
config.json ← routing rules
static/ ← static assets served by CDN
functions/
__server.func/
index.mjs ← serverless function handling all SSR routes
.vc-config.json ← tells Vercel this is a Node.js function
Vercel natively understands this format and correctly wires up static asset serving + the serverless function. No manual rewrites needed.

Starting Fresh on Lovable?
Make these two changes before your first push and skip all of this pain.

Common Mistakes to Avoid

❌ Don't set outputDirectory: "dist" or "dist/client"
❌ Don't add manual rewrites in vercel.json
❌ Don't set framework: "vite" or any other framework
❌ Don't skip the output.dir override in vite.config.ts
✅ Always run npm run build locally first and verify .vercel/output/ exists before pushing