Productivity with AI: A Double-Edged Boost

Jakub Stetz — Thu, 12 Jun 2025 16:06:50 +0000

Over the past few months, I've become increasingly effective at using ChatGPT as a coding partner. My productivity has skyrocketed, and I've been learning new things at a rapid pace.

A few days ago, based on a friend's recommendation, I downloaded and started using Cursor. I've been playing around with it, and having deep AI integration right in my code editor has been a game changer. The speed at which I can scaffold projects, add features, and iterate has surged once again.

But this has also reinforced a principle that’s already become deeply ingrained in me from my work with ChatGPT:

AI is a powerful tool, but it doesn't replace genuine knowledge, skills, and thoughtfulness.

⚠️ The Limitations of AI

Often, when I ask Cursor to generate code, that code looks polished and impressive — but:

...it’s poorly integrated with the rest of my project,
...it’s redundant or overengineered,
...or it introduces subtle bugs that didn’t exist before.

This isn't a dig at Cursor. I actually appreciate these moments. They give me a chance to notice flaws, refine logic, and sharpen my critical thinking.

Reviewing my own code is one thing. But reviewing 50 lines of beautiful AI-generated code — and resisting the urge to just accept it — requires even more discipline and discernment because of how easy it is to simply leave it as is and move on.

🧠 The Real Multiplier: Staying Engaged

Over time, I’ve come to see there’s a massive difference between using GenAI passively and using it collaboratively.

If I use AI passively, I get a 5x productivity gain — I can deploy faster, finish tickets quicker, and move on to the next task.

But even that 5x is often deceptive. The code might compile and the features might work, but the foundations are fragile. Rushed output often hides subtle bugs, poor structure, and short-sighted decisions — cracks I won’t notice until they cause friction later on, or worse, break in production.

On the other hand, when I stay fully engaged — reading critically, reviewing suggestions carefully, questioning the structure — that 5x productivity boost becomes 10x. I not only move faster but also greatly reduce how much debugging and backtracking I need to do later on.

The key is to keep my brain in the loop — and to keep learning. Whether it’s brushing up on design patterns, understanding performance tradeoffs, or deepening my knowledge of the frameworks I’m working with, skill development is what turns AI from a shortcut into a force multiplier.

🔍 Learning By Example

One of my friends, a senior software engineer, told me she’s often slower than her peers in submitting code, because they use GenAI to fly through tickets whereas she works more carefully.

But when code reviews come, their pull requests get kicked back, and hers glide through. By stepping through logic, checking for edge cases, and making sure everything aligns cleanly with the existing codebase, she does more work in the moment but eliminates unproductive back-and-forth and iteration down the line.

Her reflection stuck with me. Productivity isn’t just about shipping fast. It’s about how much rework I avoid, and the long-term quality of my contributions.

🧘‍♂️ Where I Stand

So that’s where I am today: deeply appreciative of GenAI, but even more grateful for the thoughtfulness, discipline, and wisdom that I’ve developed through using it with intention — and through actively building my own knowledge and skills along the way.

I’m a big fan of AI-assisted development. I could talk for hours about how transformative it’s been. But I never let AI overshadow the values that guide my software practice: clarity, care, and craft.

Not All CORS Errors Are CORS Errors

Jakub Stetz — Tue, 22 Apr 2025 16:27:37 +0000

The Debugging Tale of a Backend Crash Disguised as a Frontend Mystery

Last night, I lost three hours of my life to a single error message:

...blocked by CORS policy: No ‘Access-Control-Allow-Origin’ header is present...

If you’ve worked with frontend-backend communication across origins, you’ve probably met the dreaded CORS error. It’s like a rite of passage—an error message that usually means you forgot to set the right headers or misconfigured CORS middleware.

Except… sometimes it doesn’t mean that.

🧩 The Setup

I was building out a résumé analysis app using a React frontend (Vite) and a FastAPI backend, with a couple of AI models running under the hood. The backend was fully implemented and the UI laid out—I was just wiring up the frontend to hit my API.

I had three API endpoints that I wanted to reach with my frontend:

POST /upload-resume
POST /upload-job
POST /analyze

Also, I'd already configured CORS in FastAPI:

app.add_middleware(
    CORSMiddleware,
    allow_origins=["http://localhost:5173"],
    allow_credentials=True,
    allow_methods=["*"],
    allow_headers=["*"],
)

I tested my upload endpoints, and everything worked fine. I could see in my server console that I was getting 200 OK responses from my API, and I could see in DevTools that my React components were properly storing the returned data.

When I implemented an API call to my /analyze route however, I got a CORS error. When that happened, I assumed I’d messed up the config.

But everything looked right. Through a litany of console log statements and DevTools analysis I triple-checked:

Allowed origins were properly listed.
Middleware was active.
My request was well-formed.
The network tab even showed the request reaching the server and being processed.

Still: CORS error.

🕵️ The Clue

What eventually tipped me off was this: other endpoints worked. Same domain. Same headers. Only /analyze was choking.

I was baffled—why would only some routes throw a CORS error? That inconsistency turned out to be the key. Once I had triple-checked that my CORS middleware was set up properly, I honed in on the backend implementation of the /analyze endpoint.

I tried a simple experiment. I stripped out all the logic from /analyze and replaced it with a plain string return.

It worked. No CORS error.

Interesting.

💥 The Real Problem

I felt a thrill and relief from getting closer to the issue. Turns out the issue had nothing to do with CORS, but rather had something to do with my function implementation.

Specifically, my handler was returning a dictionary that included an embedding from a machine learning model. This embedding was a NumPy array, which—unbeknownst to me—contained numpy.float32 and numpy.int64 values.

What surprised me is that NumPy floats and ints look like native Python floats and ints, but they aren’t. FastAPI (via JSONResponse or its default encoder) expects standard Python types—and NumPy’s versions aren’t JSON-serializable out of the box, meaning they can’t be converted into JSON.

Therefore, when FastAPI encountered these NumPy-specific numeric types, it quietly failed to serialize them. The result? A 500 Internal Server Error, which aborted the response entirely.

Because the response never completed, the browser didn’t receive any CORS headers—so it flagged the issue as a CORS error, even though the real problem was deep in the backend.

Once I converted the NumPy floats and ints to standard Python types using float(x) and int(x), everything worked fine.

‼️ The Core Takeaway

Not all CORS errors are CORS errors.

When FastAPI is unable to serialize data into JSON, the server crashes.

When the server crashes, no response is returned to the frontend.

And when no response is returned, naturally the frontend never receives the CORS headers that it expects. Therefore it registers a CORS error, even though CORS has nothing to do with the issue.

In summary: A backend server crash may register as a CORS error in the frontend.

📚 Lessons Learned

✍️ Not all CORS errors are CORS errors

Sometimes they're just backend failures with a CORS costume.

✍️ Isolate ruthlessly

Strip endpoints down to echoes. Meticulously track what's been verified to work. Rebuild upward until it breaks again.

✍️ DevTools and print statements beat intuition

Real data > vibes-based debugging.

✍️ ChatGPT is a powerful tool, but never replaces thoughtful debugging

It’s great for rubber-ducking, research, and writing helpers—but when it comes to debugging gnarly issues in a live system, you’re better off with print statements, DevTools, and your own patience. There's no shortcut to robust development.

✍️ Serialization matters

NumPy floats and ints look like native Python types, but they aren’t—and FastAPI can’t serialize them. This subtle mismatch caused the backend to crash without warning. Always convert NumPy types before returning them in a response.

✍️ Experience is a brutal but effective teacher

I felt totally drained by this debugging session, but I also feel grateful for having learned a subtle lesson that I'll never forget. This is the kind of wisdom and experience that's hard-fought, and which distinguishes hobbyist programmers from true engineers.

🧠 Reflections

I’ve been learning software development seriously for just over a year now, and moments like this remind me how much of engineering is earned through experience—not tutorials. There was no trick, no clever insight—just me, a browser console, and a backend silently crashing.

The whole saga was humbling and mentally draining—but honestly, I feel grateful. This kind of grind is where real engineering experience is forged.

Now that I’ve got this scar, maybe someone else won’t need to get the same one.

DEV Community: Jakub Stetz