A new Open AI agent builder, is actually not an agent builder at all, here is why:

Kirill Gerts — Thu, 09 Oct 2025 15:29:46 +0000

Many products announced as “AI agents” are not truly agents but workflows with a fancy coat of paint. OpenAI’s Agent Builder is the latest to draw headlines, but behind the marketing are fundamental architectural differences that matter to anyone building robust AI applications.

Agents vs. Workflows: The Heart of the Matter

The distinction isn’t just semantics, it’s about where the intelligence happens. True agents are large language models that dynamically control their own processes, deciding in real-time which tools to use, how to plan each step, when to seek feedback, and how to adapt when things go off track. In contrast, most point-and-click “agent builders” set up strict predefined paths: inputs go in, the system marches through a set orchestration, and, with luck, spits back an answer. If you ever needed more flexibility, creativity, or the capacity to recover from error, these rigid workflows fall short.

The Workflows that Masquerade as Agents

OpenAI’s Agent Builder lets developers visually string together prompt chains and call APIs or tools in a predefined sequence. These setups feel like agents, especially for simple automations, but they remain fundamentally prescriptive. They follow scripted paths and rarely deviate from the hardcoded workflow. Here are a few examples:

A customer support bot that triages and looks up common questions using document search and knowledge bases.
A sales assistant bot that chats with leads, qualifies them, and schedules calls using APIs.
An intelligent document processor that ingests contracts, compares versions, and answers questions about changes.
An internal monitoring bot that watches business metrics and drafts alerts when anomalies appear.

Why This Matters: True Agents Rise to Real-World Challenges

Real agents, like those documented by Anthropic, thrive in environments where requirements can’t be predicted in advance, where each input might require a new plan, and every step needs context-aware choices. Examples include coding assistants that analyze and resolve complex issues across multiple files, support bots interacting with customer databases and updating tickets, and autonomous researchers gathering information and refining their answers until a high-quality solution emerges. It’s the difference between a static assembly line and an expert problem solver.

The Risks of Conflating Agents and Workflows

Calling workflows “agents” might help companies market their tools, but it misleads users, leading to mismatched expectations and wasted investment. Quick wins with workflow engines can stall as projects grow: suddenly, cost, latency, and brittleness take center stage. Teams often find themselves refactoring, stripping away layers of abstraction, and wishing they’d started with simpler approaches, like direct LLM API calls, openly composable integrations, and clear, easy-to-debug interfaces.

Conclusion: Choose the right tool/technology

This isn’t about labeling workflows “bad”, it’s about clarity and choosing the right tool for the job. It’s problematic when even software developers don’t understand the crucial difference between workflows and true AI agents. Use real AI agents only when you truly need the autonomy they provide. If your task can be accomplished with simple API calls, do that. It’s cheaper, faster, and easier to maintain.

If your use case requires complex but predictable logic, workflows like OpenAI’s Agent Builder, n8n, or Zapier will serve you well. These tools speed development for many practical automation needs.

But when your problem demands unbounded adaptability, changing plans on the fly, retrieving context, and synthesizing new information dynamically, that is when you turn to real AI agents built on frameworks designed for true agentic behavior.

P.S. In the next article, we'll discuss the best tools to use for building real agents 🤖

Prisma ORM vs Drizzle: Game Over for Prisma?

Kirill Gerts — Wed, 16 Jul 2025 22:47:22 +0000

As an expert senior web developer specializing in Next.js (App Router), React, TypeScript, and Tailwind CSS, I've architected my share of production apps, and lately, one question keeps popping up: With Drizzle's rise, is it game over for Prisma? Drizzle is significantly faster, way smaller in size, plays perfectly with serverless functions, and pushes you to master SQL (a timeless skill that pays dividends everywhere, unlike Prisma's proprietary query language). It's a compelling case, but is Prisma really obsolete? Let's dissect this with real examples and pragmatic advice. Spoiler: Drizzle might be pulling ahead for many use cases, but it's not a total knockout.

1. Speed and Size: Drizzle's Knockout Punch in Performance Wars
Drizzle isn't just faster, it's a lean machine (under 100KB gzipped vs. Prisma's bulkier package) that compiles to optimized SQL, slashing query times in high-stakes scenarios. For serverless setups like Vercel or AWS Lambda, it's a dream, no connection pooling headaches, just pure efficiency. If you're chasing sub-100ms responses, this could be why Prisma feels like yesterday's news.

Example: Querying users in a scalable e-commerce API with Drizzle, idiomatic SQL that runs like lightning:

// drizzle.config.ts (simplified)
import { drizzle } from 'drizzle-orm';
import { pgTable, serial, text } from 'drizzle-orm/pg-core';

export const users = pgTable('users', {
  id: serial('id').primaryKey(),
  name: text('name'),
});

const db = drizzle({ /* your connection */ });

// Next.js API route
import { eq } from 'drizzle-orm';

export async function GET() {
  const result = await db.select().from(users).where(eq(users.id, 1));
  return Response.json(result);
}

This setup encourages SQL proficiency,super transferable, especially for devs with finance backgrounds analyzing market data. Prisma's abstraction? It adds overhead that might not cut it at massive scale.

2. Developer Experience: Prisma's Last Stand in Rapid Builds
Okay, Prisma isn't dead yet, it's still a beast for quick prototyping with its type-safe client, auto-generated schemas, and tools like migrations. The declarative queries are newbie-friendly, ideal for React-focused teams avoiding SQL complexity. But in a world demanding efficiency, is that enough when Drizzle offers similar safety with real SQL under the hood?

Example: The same query in Prisma, simple, but arguably less "future-proof":

// schema.prisma
model User {
  id   Int    @id @default(autoincrement())
  name String
}

// Next.js app
import { PrismaClient } from '@prisma/client';

const prisma = new PrismaClient();

export async function GET() {
  const user = await prisma.user.findUnique({ where: { id: 1 } });
  return Response.json(user);
}

Great for MVPs, but if you're not learning portable skills, are you really leveling up?

3. Serverless and Skills: Drizzle's Winning Formula

Drizzle dominates serverless with zero friction and motivates you to learn SQL—a market-aware edge in any tech role. Prisma's custom language? Handy in its bubble, but it won't help elsewhere. For strategic, production-ready apps, this shift feels inevitable.

My Strategic Take: Time to Refine Your Stack?

Drizzle's advantages make it feel like the future for performance-hungry, serverless projects. I've swapped to it mid-app for 20% cost savings on a real-time dashboard. Prisma holds ground for rapid dev and ecosystems like T3 Stack, but if speed and skills matter most, yeah, it might be game over for many. What's your verdict? Tried switching? Share below, let's debate! Need help architecting your Next.js ORM choice? DM me. 🚀

DEV Community: Kirill Gerts

A new Open AI agent builder, is actually not an agent builder at all, here is why:

Prisma ORM vs Drizzle: Game Over for Prisma?