DEV Community: Miguel Paracuellos

OpenAI Just Went Open Source (For Real This Time)

Miguel Paracuellos — Wed, 06 Aug 2025 19:18:43 +0000

Two models. Open weights. No API lock-in. This release is way more than just another LLM drop.

🚀 The Big Moment: OpenAI Open-Sources GPT-OSS

Remember when OpenAI said they might open source again someday?

Well, they just did. And it’s not some toy model. It’s a full-blown, reasoning powerhouse that you can run on your laptop or fine-tune for your startup. No paywall. No black box. No strings attached.

In this article, I’ll break down:

What GPT-OSS is
Why this release is a game-changer
What you can actually do with it
How it stacks up against the current LLM landscape

Let’s dive in.

🧠 What OpenAI Just Dropped

OpenAI released two new open-weight language models:

gpt-oss-120b: A 117 billion parameter model using a Mixture-of-Experts (MoE) architecture. It activates just 5.1 billion parameters per token and competes with o4-mini, outperforming many closed models in reasoning and code tasks.
gpt-oss-20b: A more compact 21 billion parameter model that activates 3.6 billion per token. It can run on consumer GPUs — yes, your gaming rig with 16 GB VRAM might handle it.

Both are released under the Apache 2.0 license, which means:

You can modify them
You can deploy them commercially
You can fine-tune them for your use case

They’re available now via Hugging Face, AWS, Azure, and more.

This isn’t OpenAI dipping a toe in the water — it’s a cannonball into the open-source LLM pool.

💥 Why This Is a Game-Changer

Let’s not understate it: this is huge. Here’s why:

First real open release since GPT-2 (2019). That’s six years of proprietary-only models — until now.
They’re actually useful. Chain-of-thought reasoning, tool use, long-context understanding, and benchmark wins — these aren’t just research artifacts.
You can run them locally. The 20b model runs on decent consumer hardware. The 120b model needs something heavier (like an 80 GB GPU) but is still accessible for labs or serious devs.
128k context window. That’s massive. Think entire books, legal contracts, and huge codebases — all processed in a single go.
They’re safe. OpenAI ran third-party evaluations for biosecurity, cybersecurity, and alignment. Even adversarial fine-tuning didn’t make them go off the rails.

In short: OpenAI just handed the world a high-performance, permissionless LLM. For free.

🛠 What You Can Do With These Models

So, you’ve got two shiny new models. What can you actually build with them?

1. Run It on Your Own Hardware

Got a decent GPU? The 20b model should run smoothly. No more waiting on API tokens or worrying about rate limits.

2. Fine-Tune for Your Domain

Legal assistants, medical chatbots, internal coding copilots — train it on your dataset and build something tailored to your use case.

3. Build AI Agents with Tool Use

Want to create an AI that plans, executes, and explains its actions? These models support chain-of-thought and tool-calling workflows. Perfect for agent-style systems.

4. Power Retrieval-Augmented Generation (RAG)

With 128k tokens of context, you can feed in massive docs, search results, logs — and get accurate, coherent output without complex chunking logic.

🔍 How GPT-OSS Stacks Up

OpenAI’s move clearly targets open-weight rivals like Meta’s LLaMA, Mistral, Qwen, and DeepSeek. But GPT-OSS brings some unique advantages:

Apache license: No non-commercial caveats
Reasoning-first design: Built for logic, not just language
Huge context window: 128k tokens, no hacks needed
MoE architecture: Activates fewer parameters for better performance-per-watt

And maybe most important: transparency. You can see what’s happening under the hood. No more mystery-model behavior.

🔮 What’s Next?

This feels like the start of something much bigger. A few questions on everyone’s mind:

Will OpenAI release even larger OSS models?
Will more companies switch to local fine-tunes over API lock-in?
How fast will the ecosystem around GPT-OSS grow — adapters, RAG pipelines, fine-tunes?

You could be early to all of it. And this time, you don’t need to be in a research lab to join the fun.

🎯 Final Thoughts

OpenAI just open-sourced something that’s not only free — it’s powerful, fast, and yours.

The best part? You don’t need to be a PhD or a VC-backed founder to use it. Just a laptop, a terminal, and an idea.

📣 Want More?

I’ll be writing a hands-on guide next - how to run GPT-OSS locally, fine-tune it, and deploy it in real-world apps.

Follow me if you want that in your feed. And if you’ve already tried GPT-OSS, leave a comment. I’d love to hear what you're building.

Let’s make open AI actually mean something again.

AI Coding Assistants Don't Suck Anymore

Miguel Paracuellos — Mon, 04 Aug 2025 13:44:57 +0000

The hype is fading, the hallucinations are dropping, and the robots finally feel like teammates instead of toddlers with keyboards.

☕️ Quick Sip Summary

New models, fewer face-palms. Claude Sonnet 4 (via Cursor), GPT-4.5, and Gemini 2.5 crank hallucinations down to ~15%.
Speed is real, trust is tricky. A controlled METR study showed a 55% speed boost, but Stack Overflow’s 2025 survey says only 29% of devs actually trust AI output.
My reality check: AI now handles the boring 80%, but the final 20% is still very human. I’ve never merged a PR without running tests and giving the code a side-eye.

1. The Day My “Intern” Grew Up

Back in early ’24, AI coding tools felt... twitchy. I remember asking it to build a login page and getting something that not only skipped validation but practically whispered "hey, let’s hardcode a password for fun."

But I didn’t quit on it. I kept using it — more cautiously at first — learning where it helped and where it hallucinated. It was like watching a junior dev slowly grow up. The suggestions started making more sense. The bugs showed up less often. And somewhere between dozens of commits and a few thousand prompts, I realized: I was trusting it more than I thought.

Then came May 2025. Cursor integrated Claude Sonnet 4, and everything clicked. I typed: “Scaffold a Nuxt 3 page listing Stripe invoices with a Tailwind table.”

Two lattes later, I had a fully working page: clean props, sensible Tailwind, pagination built-in, no missing imports. It didn’t just look good — it ran.

Why the glow-up?

The AI Hallucination Benchmark 2025 clocks GPT-4.5 and Sonnet 4 at ~15% hallucinations (down from over 50%).
The METR study shows AI can make devs 55% faster on focused tasks.

That aligned with what I was feeling: the tool had matured — and maybe so had I.

2. Where AI Shines — And Where It Slips

After months with Sonnet 4, here’s what’s felt like magic — and what still gives me pause:

What works well:

Boilerplate scaffolding (components, DTOs)
Writing unit tests
Repo Q&A like “Where do we parse JWTs?”
Project-wide refactors

Where I don’t trust it (yet):

Security-critical flows like auth and crypto
Perf-sensitive logic
Legacy spaghetti with zero documentation
Tasks I haven’t mentally designed yet

If I don’t know exactly what I want, the model will happily hallucinate an entire fantasy architecture. Then I get to debug my own laziness at 2 a.m.

3. My Four-Step Prompt Ritual 🙏

Here’s how I talk to the model now:

Set the scene. “You're a senior dev experienced in Nuxt and Stripe.”
Describe the goal. “Implement server-side pagination for /api/invoices.”
Set the stack. “Nuxt 3, Prisma, PostgreSQL, limit 50 rows, return totalCount.”
Guide the scope. “Please outline the steps only.”

From there, I review its plan, give feedback, and go step-by-step through implementation. It feels like pair programming — minus the headphone tugging.

4. Trust Issues: Everyone’s Using It, Nobody’s Sleeping Easy

80% of devs use AI tools (according to Stack Overflow 2025).
Only 29% trust the output unedited.

Reddit is full of rants like “Management wants 20% of commits from Copilot.” One post even mentioned execs tracking prompt counts per day.

That’s not how I roll. I’d rather measure features shipped, not lines of AI-assisted code.

5. The Numbers Don’t Lie

One recent feature:

Old-school dev time: ~3h 45m
- 45m for scaffolding
- 120m for core logic
- 60m for tests
With Cursor + Sonnet 4: ~1h 45m
- 5m prompt for scaffolding
- 90m prompts + tweaks
- 10m for tests

That’s two hours saved — enough for a gym session, or let’s be real, another coffee and a doomscroll.

6. Five Things I Wish I’d Known Sooner

Design before you prompt. AI isn’t great at mind-reading.
Break it up. Big tasks become small, accurate prompts.
Test everything. No green CI, no merge.
Sleep on major merges. AI optimism is real — and sneaky.
Don’t ditch juniors. Pair them with AI, then make them explain every line.

7. So… Should You Trust the Robot?

Yes — but only like you’d trust a hyper-literal intern. Brilliant with grunt work. Hopeless with nuance. When I give it structure and oversight, it makes me faster. When I hand it the wheel, it usually drives into a wall of undefined variables.

Your Turn

Are you vibing with the new generation of AI dev tools? Or still fighting ghosts in your PRs?

Drop a story below — horror or happy ending. And if enough folks ask, I’ll share my prompt cheat sheet in the next post.

This article was originally published on Medium:
AI Coding Assistants No Longer Hallucinate — If You Know What You’re Doing

5 PostgreSQL Tricks That Made My SaaS x10 Faster (2025 Edition)

Miguel Paracuellos — Wed, 30 Jul 2025 07:10:33 +0000

TL;DR Five copy‑pasteable fixes that turned sluggish production queries into lightning‑fast responses. All examples use generic tables—orders, users, products—so you can follow along even if you’re new to Postgres.

Why This Matters

Slow queries cost money (cloud bills climb, customers churn).
Most blog posts stop at “just add an index”—real life is messier.
These five techniques gave my SaaS a 10× speed boost this year without bigger hardware.

If you store anything more than a to‑do list, stick around.

Roadmap

Measure First 🔬 — EXPLAIN ANALYZE BUFFERS
Eliminate Duplicate Rows ⚔️ — LEFT JOIN LATERAL + json_agg
Index Power‑Ups 🚀 — Partial & Covering Indexes
One‑Pass Stats 📊 — FILTER Aggregates
Readable + Fast 🧩 — CTEs (with a dash of LATERAL)

(Skim the headings now, then read straight through—each trick builds on the last.)

1. Measure First 🔬 — `EXPLAIN ANALYZE BUFFERS`

Rule #1 – Never tune blind. You need real numbers before you change anything.

EXPLAIN (ANALYZE, BUFFERS)
SELECT *
FROM   orders
WHERE  created_at >= NOW() - INTERVAL '30 days';

Red Flags

Actual vs Estimated Rows > 10× → run ANALYZE or fix statistics.
Node Execution Time dominates (> 70 %) → add an index or rewrite the join.
Shared Read Blocks huge on a “small” query → you’re hitting disk, add an index or more cache.

Tip: Upload the plan to https://explain.dalibo.com/ for an instant visual map of bottlenecks.

2. Eliminate Duplicate Rows ⚔️ — `LEFT JOIN LATERAL` + `json_agg`

Rule #2 – Aggregate as close to the data as possible. One parent row in, one parent row out.

Use Case

Return every order with its items—but keep the result set to one row per order.

Before – Classic join (row explosion)

SELECT o.id, o.total, oi.*
FROM   orders o
LEFT   JOIN order_items oi ON oi.order_id = o.id;

-- Result
 id | total | item_id | qty
----+-------+---------+-----
101 | 49.00 |  9001   |  1
101 | 49.00 |  9002   |  2
102 | 15.00 |  9003   |  1

A single order with two items becomes three rows.

After – `LATERAL` + `json_agg`

SELECT o.id,
       o.total,
       json_agg(oi.* ORDER BY oi.id) AS items
FROM   orders o
LEFT   JOIN LATERAL (
  SELECT *
  FROM   order_items
  WHERE  order_id = o.id
) oi ON TRUE
GROUP  BY o.id;

-- Result
 id | total | items
----+-------+-------------------------------------------------------
101 | 49.00 | [{"id":9001,"qty":1},{"id":9002,"qty":2}]
102 | 15.00 | [{"id":9003,"qty":1}]

One row per order; items are delivered as a tidy JSON array.

Outcome: Dashboard latency dropped 650 ms → 38 ms.

Tip: Index order_items.order_id so each per‑row sub‑query uses an index scan, not a sequential scan.

3. Index Power‑Ups 🚀 — Partial & Covering Indexes

Rule #3 – Build the smallest index that fully answers the query. Smaller indexes read faster and write faster.

3.1 Partial Index (only active rows)

CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_user_active
  ON users(id)
  WHERE deleted = false;

Indexes just the rows you actually query—often 90 % smaller than a full index.

3.2 Covering / INCLUDE Index (avoid heap access)

CREATE INDEX CONCURRENTLY IF NOT EXISTS idx_orders_status_inc
  ON orders(status)
  INCLUDE (total, created_at);

Postgres can now satisfy:

SELECT status, total, created_at
FROM   orders
WHERE  status = 'SHIPPED';

using only the index—no table lookup at all.

On 100 k rows: latency 120 ms → 9 ms; buffer reads 18 k → 1 k.

Tip: Prove the footprint with SELECT pg_size_pretty(pg_relation_size('idx_orders_status_inc'));—stakeholders love hard numbers.

4. One‑Pass Stats 📊 — `FILTER` Aggregates

Rule #4 – Scan once, compute many metrics. Let Postgres do the heavy lifting in a single pass.

Before – Two separate scans

SELECT COUNT(*)                   FROM orders;             -- total
SELECT COUNT(*) FROM orders WHERE status = 'SHIPPED';      -- shipped

After – One scan, multiple metrics

SELECT COUNT(*)                                           AS total_orders,
       COUNT(*) FILTER (WHERE status = 'SHIPPED')         AS shipped_orders,
       AVG(total) FILTER (WHERE status = 'SHIPPED')       AS avg_shipped_value
FROM   orders;

Dashboard latency: 45 ms → 12 ms on 500 k rows.

Tip: Combine with the covering index from Section 3—your aggregate becomes index‑only.

5. Readable + Fast 🧩 — CTEs (with LATERAL)

Rule #5 – Isolate heavy logic, then reuse it. CTEs make complex queries readable; Postgres 15 inlines them for free speed.

Goal

Return every product with its latest price—one row each.

Before – Correlated sub‑select (runs per product)

SELECT p.id, p.name,
       (SELECT price
        FROM   prices pr
        WHERE  pr.product_id = p.id
        ORDER  BY pr.changed_at DESC
        LIMIT 1) AS latest_price
FROM   products p;

After – CTE + `DISTINCT ON` + LATERAL

WITH latest_prices AS (
  SELECT DISTINCT ON (product_id) *
  FROM   prices
  ORDER  BY product_id, changed_at DESC
)
SELECT p.id, p.name, lp.price, lp.changed_at
FROM   products p
LEFT   JOIN LATERAL (
  SELECT price, changed_at
  FROM   latest_prices lp
  WHERE  lp.product_id = p.id
) lp ON TRUE;

On 10 k products: 780 ms → 54 ms.

Tip: Add an index on (product_id, changed_at DESC) in prices so DISTINCT ON is instant.

What’s Next?

If you found these tricks helpful:

Smash Clap so more devs see the post.
Follow me for deep‑dive follow‑ups on each technique.
Drop your slowest Postgres query in the comments—I may refactor it in a future article.

Your query planner salutes you 🚀

This article was originally published on Medium:
5 PostgreSQL Tricks That Made My SaaS x10 Faster (2025 Edition)

Understanding git bisect!

Miguel Paracuellos — Thu, 04 Jul 2024 19:52:52 +0000

Have you ever been put in a situation where a bug has been spotted on your project, which you know was not there some time ago but you do not know when it was introduced.

This situation forces you into, at least, 2 possible paths 👇🏻

Trying to debug your codebase to find out where the bug is coming from, which in large codebases or certain situations can become difficult.
Going back to previous commits one by one, which in big projects or those shared by lots of people may imply going back tons of commits, which can become really time consuming to say the least.

If this seems like the situation you’re facing or have ever faced, keep reading!

Imagine you’re facing the following case 👇🏻

If you needed to spot where the issue was introduced at, you would start a linear search where you would go back 1 commit by 1 commit and seeing where the issue was introduced

Imagine the issue was introduced 40 commits ago, you would have been forced to checkout 40 times until you found the first commit where the bug did not exist 😱

What does git bisect offer?

The idea behind git bisect is to replace the linear search by a binary search. Let’s look at it through an example (for the sake of simplicity, the example will be reduced to a use case with 8 commits) 👇🏻

When running git bisect we will be asked to give a commit in which the issue was not happening (start commit) and a commit where the issue has been spotted (end commit):

Start commit → Commit 1 (just try some random older commits and take the first one that works)
End commit → Commit 8

Binary search will take a random commit in the middle called pivot, Commit 5 for example, and check if the issue still appeared there or not.

On our case, Commit 5 still presents the issue so we can ensure that Commit 6 & Commit 7 & Commit 8 won’t be the ones that introduced it.

Just like this, we have avoided checking Commit 6 & Commit 7. Way to go!

We will just take a pivot around the middle again, on this case Commit 2.

In this case, Commit 2 does not present the issue! Therefore, we can ensure that Commit 1 did not introduce it neither. Another commit less to check again!

We just need to check if the bug was introduced by Commit 3 or Commit 4 🏃🏻

We’ll repeat the process!

Same as before is done and therefore we’ll easily find out that Commit 3 introduced our bug, and now we just need to look through the changes done in that specific commit, easy! 🥳

You might be wondering…

Okay the drawings look good but, is this really faster?

In general terms, the costs usually are something like 👇🏻

That’s it!

I hope you found this post useful and that it might help you next time you’re facing something similar!