DEV Community: David (ダビッド )

The Four Engineerings of AI

David (ダビッド ) — Fri, 17 Jul 2026 21:43:56 +0000

The AI industry has just converged on the very same multi-agent architecture I've spent the last few weeks stumbling my way toward in my own code. I saw it all at once in two YouTube talks: one by Sally-Ann Delucia, from Arize, on how they solved context management in their agents; another by Luke Alvoeiro, from Factory, presenting a multi-agent architecture capable of building and shipping software for days on end.

I watched them with a strange mix of recognition and relief: the feeling of reading the design of something I had already built, and thinking "so I'm on the right track after all." Because I've spent the last few weeks writing a parallel-agent orchestration plugin —I call it parallel-work— and I built it by tripping over things, not by reading papers. And yet there they were, two people who don't know me at all, describing from their own trenches the same conclusions I had reached the long way around.

That's what this post is about: the four "engineerings" that are structuring how we work with AI —prompt, context, harness and loop engineering—, what those two talks say, and —at the end— a third speaker who talks not about architecture but about us: about the role left to the human when code becomes free. And why I believe that convergence is the most reliable signal that an idea is right — including one objection I'll raise against myself before you get the chance to.

The ladder: prompt → context → harness → loop

I owe the framework to Addy Osmani, who organizes work with models into four rungs, each one wrapping the previous:

Prompt engineering. The model's native reasoning. You write the request well and trust what the model ships with. It's the rung we all started on, and the one the industry is already climbing out of.
Context engineering. The agent fetches into its own window whatever it needs: tools, files, MCP results. The focus shifts from what you ask to what it sees while it works.
Harness engineering. An external system manages context from the outside: it splits the requirement into a stable, structured task list, and survives the model's window instead of depending on it.
Loop engineering. External scaffolding so the agent prompts itself and runs continuously, with the human out of the loop.

I'll also leave you a more visual, explanatory video on the topic: Loop Engineering Explained in 8 Minutes

The elegance of the model is that each rung doesn't replace the previous one — it wraps it. And if I had to pin my plugin to one point on that ladder, I'd say without hesitation that its center of gravity is the third: harness engineering. A wink I wasn't expecting: both speakers use that very word, each on their own —Sally-Ann calls her product "an AI harness"; Luke introduces himself as responsible for Factory's "core agent harness"—. When the vocabulary converges without anyone agreeing on it beforehand, it's usually because the concept was real. But to explain it properly, first the two talks.

Arize: "agents don't fail because of prompts, they fail because of context"

Sally-Ann Delucia's talk opens with an anecdote that's scary because it's so recognizable. At Arize they built an agent, Alyx, to analyze trace data from their own platform. The problem: every time Alyx ran, it generated more trace data, which bloated its context window, which made it hit the limit, which made it fail… and the failure's own trace added even more data to the next attempt. An agent drowning in its own data trail.

The line that stuck with me: "agents don't fail because of prompts, they fail because of context." It's the jump from rung 1 to rung 2 said in a single sentence.

The interesting part is what didn't work. The naive fix —truncating, keeping the beginning— produced amnesia: follow-up messages lost the thread. The "obvious" fix —asking an LLM to summarize— didn't work either: compression with no principle, no control over what got preserved. The two shortcuts we all think of first, ruled out with data.

What did work was a three-piece architecture:

Smart truncation: keep the head and tail of the conversation in the active context.
A retrievable memory store for the middle: it isn't thrown away, it's moved somewhere the agent can pull from when it needs to.
Sub-agents that take on the heavy operations (analyzing traces, searching) and return only the distilled result, keeping the main conversation light.

Her design principle sums it up perfectly: "context decides what the model sees, memory decides what survives." And the detail that surprised me: Delucia says Claude Code independently converged on the same truncation-and-compression strategy. She told it with a smile —when Anthropic published part of Claude Code's source, the Arize team read it "hoping to get a little bit of a secret from them," and found their own approach staring back—. It's not an Arize proprietary trick. It's a pattern that emerges when different people push against the same wall.

Factory: the multi-agent architecture that actually ships software

Luke Alvoeiro's talk goes one rung higher. His opening thesis is a good provocation: the bottleneck in software engineering is no longer model intelligence — it's human attention. We don't lack the capacity to generate code; we lack the capacity to supervise all the code being generated.

His answer is an architecture —they call it Missions— with three specialized roles:

Orchestrator: plans features and milestones and, crucially, writes the validation contract before a single line of code is written. It defines what "correct" means independently of how it will be implemented. It plays interlocutor, asks questions, closes requirements.
Worker: implements. And it does so with fresh context per feature —it inherits a "clean slate," without the accumulated baggage of previous tasks—, commits via Git and does a structured handoff.
Validator: verifies, and here's the refined part. There are actually two validators launched at the close of each milestone: one for scrutiny (a battery of tests, types, lints and a review agent per feature) and one for user testing that behaves like a human QA —it spins up the application and actually uses it: fills in forms, clicks buttons, checks that the flows work end to end—. Neither of them has seen the code before: validation is adversarial by design. And they often run on a different model provider, so that the same model that wrote the code isn't the one signing off on it.

A couple more decisions that strike me as the important ones. First, serial execution: a single worker or validator active at a time, because when you let agents run fully in parallel, "agents conflict, duplicate work, and make inconsistent architectural decisions." Second, model-agnostic design: minimal hardcoded logic —all the orchestration lives in about 700 lines of prompts and skills, not in a state machine—, so the system "improves with every model release rather than becoming obsolete." His way of putting it stuck with me: "missions ensure the discipline and the models provide the intelligence" —which is, word for word, how I think about my plugin: the machinery (hooks, skills, agents, commands and scripts) enforces the discipline, the model supplies the judgment—. The validation contract written before the code strikes me as the gem of the talk, because it inverts the usual vice: tests written after confirm the decisions you already made; they don't catch bugs.

The result they show: a Slack clone built in a sustained 16-day "mission," with 90% of the code covered by tests that, in the end, make up half the lines in the repository. And an honest data point from the talk itself: validation almost never passes on the first try —the system has to open corrective features over and over—, and the bulk of a mission's wall-clock time isn't spent generating code, but waiting for the user-testing validator to exercise the live application. That half the final code is tests, and that verification eats the clock, is not the system's toll: it is the system.

Where my plugin fits

And this is where I went back to my own notes with a mix of vertigo and relief. Because I wrote parallel-work without having seen either talk, tripping through real runs, and yet the correspondence is almost one to one.

parallel-work is a Claude Code plugin that encodes a coordinator-driven parallel-agent methodology: Intake → Design Lock → lanes in worktrees → a reviewer per PR → QA → architect audit → merge exactly once. Five roles.

Why a Claude Code plugin, and not a standalone system from scratch? Two reasons — one about design, one more prosaic. The design one fits everything above: Claude Code's harness is already very mature and very good —context management, tools, permissions, hooks, sub-agents—, so building my coordination layer on top of that harness, instead of reinventing the base, is the right engineering call. I bring the rung I care about —the multi-agent orchestration harness— and Claude Code supplies the ones underneath. The prosaic one: this way I leverage my own Claude Code subscription instead of standing up and paying for separate infrastructure. Less scaffolding to maintain, more time on the problem I actually want to solve.

And there's a sister question, the one I asked myself first: if Anthropic already offers Claude Code Teams —its own native multi-agent orchestration layer—, why build my own? Because I tried it before deciding. A while back I put Teams to work on a production NestJS service, with four Linear tickets that were the four layers of a single feature, and I wrote about it on the blog (in Spanish). The code came out solid, but the failures were the revealing part: the supervisor was too passive; the "team lead" approved plans on its own without escalating them to me, skipping protocols I had made explicit; and the agents worked in parallel even though the dependencies were sequential. Three cracks that, funnily enough, are exactly the three things parallel-work turns into hard invariants: the human pinned to the Design Lock and to the merge gate —the latter enforced by a hook, not by the model's good will—, the waves that order in time whatever depends on something else, and independent verification gates that don't rely on anyone remembering to look. It's not that Teams is bad —it's a solid foundation—; it's that I get out of the box what Teams gives me plus, on top, exactly the pieces its own trial showed me were missing. In the time I've been running the plugin it behaves much better for the way I work —with the usual caveat: it's my first-hand experience, not a benchmark, but it's precisely the experience that made me choose—.

If I put my vocabulary side by side with Factory's and Arize's, this is what comes out:

Industry concept	parallel-work equivalent
Orchestrator (Factory)	Coordinator — the persistent session, with the human
Worker with fresh context per task	Builder in its own worktree — my central thesis
Validator that has never seen the code (creator ≠ verifier)	Reviewer / QA / Architect — fresh context; reviewer and architect additionally read-only
Validation contract before the code	Design Lock (glossary + ADRs before building)
Structured handoffs	The `handoff` skill writing its `HANDOFF.md`
Context manager that survives the window	`STATE.md` — always re-read, survives compaction
Sub-agents returning distilled results, not raw data	Reviewer and architect return verdicts, not work
Human on the goal, agent on the execution	The merge gate — the human-shaped hole
Model-agnostic scaffolding	The discipline lives in prompts and skills, not a state machine — improves with every model

Two confessions about that table, so you don't buy it wholesale. First: the Factory piece I don't have yet is validator model diversity —having the verifier run on a different provider than the one that wrote the code—. My independence is built with a different mechanism: fresh context (the reviewer never watched the builder reason, so it can't rationalize its decisions) plus read-only enforced in the agent's definition. I stand by that mechanism, but it's not the same axis, and adding model diversity is in my backlog, not in my code. Second: "model-agnostic" does not mean executor-agnostic. The plugin is deliberately coupled to Claude Code, because its enforcement layer —the hooks that make it physically impossible for a builder to merge— is precisely the part that wouldn't port cleanly to another platform, and it's also the differentiating asset. The discipline survives every model release; it doesn't pretend to survive a change of executor, and that's a decision, not an oversight.

Osmani's definition of "harness" —"an external system that manages context from outside, dividing the requirement into a stable, structured task list"— is, literally, my STATE.md plus the coordinator. It survives compaction, splits the epic into lanes and waves, and gives every role fresh context instead of a self-summarized context that leaks. Arize's answer to the context problem is retrievable memory; my answer to the same problem is to never let the context get dirty in the first place —every role starts clean—. Different paths, same mountain.

There's another coincidence I especially liked. Luke lists five multi-agent communication patterns, and Missions uses four: it deliberately discards direct communication between agents, because without a coordinator the state fragments and the single source of truth disappears. In parallel-work the builders never talk to each other either: everything goes through the coordinator and through STATE.md, which is the single source of truth. Two systems landing on the same rule without knowing each other —agents don't coordinate peer-to-peer, they coordinate against a central state— is exactly the kind of coincidence that made me write this post.

The honest divergence: serial vs parallel

Not everything fits, and the point where it doesn't is the most interesting one to tell. Factory serializes features to keep agents from colliding. I do exactly the opposite: I parallelize the lanes. It's the word that gives the plugin its name.

A contradiction? Not if you look at how the conflict is resolved in each case. Factory avoids the collision by executing one at a time. I avoid the same collision with worktree isolation (each builder works in a separate git tree), a shared integration branch every PR targets, and a single merge once the epic is whole. Same problem —agents stepping on each other, inconsistent architectural decisions—, two valid solutions: they solve it in time (serial), I solve it in space (worktrees). That two designs arrive at different answers to the same risk doesn't weaken either one; it delineates when to choose each.

And here is where anyone who has suffered through concurrency raises an eyebrow, rightly: the worktree only solves the physical clash —two agents editing the same file—. What about the logical one, when lane A changes a method signature or a schema that lane B depends on? The worktree doesn't touch that one; it's governed by three other layers:

The Design Lock pins the shared contracts before a single lane opens: the glossary and the ADRs close off shared signatures, schemas and architectural decisions. Builders don't invent divergent interfaces; they start from the ones already sealed.
The waves order dependencies in time. The coordinator only parallelizes deliberately independent lanes; whatever touches a shared surface goes in an earlier wave, so the dependents already inherit the change. The parallelism is within the wave, not indiscriminate.
QA and the architect's audit at the seams catch whatever drift slipped through anyway: the architect reads the converged whole —not each lane separately— looking precisely for cross-lane inconsistency; QA tests the joints. And all of that happens before the single merge.

What if the contract itself turns out to be unworkable mid-execution —lane A discovers that the agreed signature doesn't hold? That's where isolation doesn't mean losing the ability to speak up. Every role still runs inside interactive Claude Code sessions, so a builder that sees the contract collide with reality doesn't keep building on something broken: it raises an alert, and the user —or even the coordinator, which also has the ability to look at the builders' state— can decide whether to pause the wave and go back to the design table with the human, to update the Design Lock and STATE.md before resuming or redirecting the builders. The plugin automates and parallelizes everything it can, but it puts the human in the loop exactly when reality breaks the plan. A Design Lock that couldn't be renegotiated would be dogma; this one gets renegotiated when it has to.

In one sentence: Factory avoids the logical conflict by never giving it the chance —one agent at a time—; I avoid it by bounding the shared surface up front and auditing it at convergence. Without those three layers, parallelizing would be reckless; with them, the worktree becomes the most visible of the defenses, not the only one.

The line I don't cross

The fourth rung, loop engineering, is where I choose to stop on purpose. The move that defines loop engineering is the agent prompting itself in a closed loop, with no human. My plugin has the machinery for that —a watch loop in which the coordinator re-prompts itself to detect finished lanes— but it keeps the human pinned to two anchors:

Triggering the epic and the Design Lock decisions.
The merge gate. Only the coordinator can merge, and since a recent version not even the coordinator can do it while the watch loop is active: a marker file the loop drops blocks merging until the loop ends. Merging went back to being a deliberate act, not something the loop does on its own.

Osmani breaks that loop rung down into six components. Doing the tally against the plugin is the part that surprised me most when watching the videos, because it comes out at five and a half out of six:

Loop component (Osmani)	In parallel-work	Match?
Worktree	Self-provisioned lanes under `.worktrees/`, in parallel, never contaminating the main tree	✅ Full
Sub-agents	Reviewer, architect and QA: agents that verify and audit before anything is called done	✅ Full — and it's the thesis of the plugin
State	`STATE.md` / `HANDOFF.md` / `DEBT.md`, per-epic source of truth, survives compaction	✅ Full
Skills	The plugin ships as modular skills (coordinator, builder, qa, guide, harness, backlog, steward)	✅ Full
Plugins & Connectors	It is a Claude Code plugin; it connects herdr, `gh`, trackers and the GitNexus MCP	✅ Full
Automation	The `/loop` is a watch heartbeat, not a cron writing code alone and unsupervised	⚠️ Partial — on purpose

And here's the beautiful part: the only component I leave half-done —Automation— is exactly the one that would be needed to close the loop entirely, the one that would hand the irreversible step to the machine. It's not a box I forgot to tick; it's the same line as before, seen from another angle. I have the whole ladder assembled except the last rung, and that gap is person-shaped on purpose.

This connects with the part of Alvoeiro's talk that resonates with me most: if the bottleneck is human attention, the right design isn't to remove the human — it's to place them where their attention yields the most —on the goal and on the irreversible step— and remove them from everything else. My bet is that the value is in the scaffolding —parallel isolation, independent verification, durable state—, not in taking the human out of the last step. It's loop-engineering machinery with a person-shaped hole in exactly the right place.

And so this doesn't stay a pose: the plugin carries an evidence instrument that measures precisely this. In the first epic it ran on itself, the independent gates —reviewer, QA, architect— produced 18 findings: none critical —15 low and 3 medium—, but 17 of them would have shipped to production without those gates, and one of the mediums was against the coordinator itself — exactly the kind of failure a monolithic system cannot see in itself. With the honest caveat that this number is n=1, on a shell-and-documentation repo —the real stress test, unleashing the five roles on a decoupled, strictly-typed backend, is still to come—. Since that first epic the plugin has already driven several more, real ones, which have been hardening it into today's version: it's not a weekend experiment. But I'm not going to sell you that it competes in maturity with Arize or Factory — far more consolidated, far better-backed products than mine. And maybe that's the most revealing part: arriving at their same shape in barely a few weeks, working side by side with very capable models (Opus 4.8 and Fable 5), says less about my merit than about how hard the convergence pushes.

Why the convergence matters to me

I could tell all of this as "look, I'd already done it." But that's not the interesting part. The interesting part is something else: how can you come to know a design decision is right when you make it alone, with nobody pushing back?

When you build something alone, your greatest fear is being in love with an idea that only works inside your head. Convergent evolution is the antidote: when people who don't know each other, working on different problems, with different incentives, land on the same shape —fresh context per unit of work, verification by an independent agent, an external state manager that survives the context window, and a human guarding the irreversible step— that stops being an opinion and starts looking like a constraint of the problem.

Now, the objection I promised to raise against myself before you do: what if the convergence isn't about the problem, but about the substrate? I built on top of Claude Code, whose primitives —sub-agents, compaction, worktrees, skills— already channel you toward this shape; Arize says they read Claude Code's source; and these talks circulate on the same conference circuit. Maybe it's not that we were all pushing against the same wall, but that we were all walking down the same corridor. It's a serious rebuttal, and it lowers the degree of independence I can honestly claim: from "three separate paths" to "three paths sharing a landscape." But it only moves the question up one level — it doesn't dissolve it: someone designed that corridor, and got there on their own — Delucia herself tells how Arize and Anthropic converged on the same context strategy without copying each other, each against their own wall. That the substrate channels you toward a shape is also evidence that the shape is a real constraint; it's just that the evidence is worth somewhat less than it appears at first glance, and I'd rather discount it myself than have you discount it for me.

None of the three of us has to be right. But that all three of us point at the same place, along paths that are at least partly separate, is the best clue I have that the place exists.

`finally { }`: and still, someone has to read the code

And here comes the third speaker I promised, the one who isn't about architecture but about us. Alex Volkov describes the debate running through the profession: at one end, "code is free… not a thing to get hung up on anymore"; at the other, "slow down… read every line." His twist is that the question is badly framed: it's not about the people, it's about the tasks. The same engineer reads every line of the payments code and waves through the non-critical stuff without looking. You route each change to the scrutiny it needs.

What made me smile is that his "routing table" includes, without knowing it, two rules I had already turned into code. One: separate. Don't let the same agent write, inspect, and grade itself —"it's like if I came up with an exam and then I took the exam and I scored myself on it"—. That is, exactly, the reason my reviewer and my architect start with fresh context and read-only. And two: build a system that builds the system; reading spends your attention once, but designing makes the system remember it. That's the entire plugin: the machinery that enforces the rules and executes the method so I don't have to police everything by hand.

The other two videos validated my architecture; this one validates my decision to leave a person-shaped hole. Because, as he says, "loops don't remove judgment, but they do raise the stakes on where you put it" — and that's why I leave that hole where I leave it: not on every line —that no longer scales—, but on the goal and on the merge, the one place where my judgment still earns its keep. Not every line of 2026 needs your eyes; every system still needs your judgment.

And with that I throw down the gauntlet, because these are debatable decisions and I want you to debate them. Parallelizing instead of serializing; forbidding agents from talking to each other and forcing them to coordinate against a central state; putting the human-shaped hole exactly at the merge and nowhere else. The plugin is still private —I can't show you the code, but I can show you the design, which is precisely what I've dissected here—, so what I'm offering is the conversation: where do you draw the line? How do you avoid logical collisions when several agents work at once? Have you already hit the context wall, and how did you get out? Tell me in the comments. This is a field we're all sketching out together, and I'd rather you push back than nod and close the tab.

Talks cited: Sally-Ann Delucia — How we solved Context Management in Agents · Luke Alvoeiro — The Multi-Agent Architecture That Actually Ships · Alex Volkov — should we still be reading code in 2026? (the ZL continuum, AI Engineer). The four-engineerings framework: Addy Osmani's writing on loop engineering (explained in 8 minutes).

Nx vs. Turborepo: Integrated Ecosystem or High-Speed Task Runner? The Key Decision for Your Monorepo

David (ダビッド ) — Wed, 12 Nov 2025 10:53:47 +0000

Original Post

Introduction: The Monorepo "Problem"

In modern software development, monorepos have become a standard solution for managing complexity. Housing multiple applications and libraries in a single repository offers undeniable advantages, though it's a strategy that must be weighed carefully. (If you're still debating between a monorepo and a multi-repo, I've explored that decision in detail in my article Repository Architecture: Exploring Monorepo, Multi-repo, and Beyond).

Once you commit to a monorepo, it brings a headache that grows over time: speed.

As the project expands, build, test, and linting times skyrocket. Tasks that once took seconds now take minutes (or hours). This is where modern build systems come into play.

Today, two titans dominate this conversation: Nx and Turborepo.

I've helped multiple teams scale their projects and have dealt with the consequences of choosing the wrong tool. The truth is, a feature-by-feature comparison doesn't tell the whole story. This isn't just a technical decision; it's a philosophical decision about how you want to manage your workspace and your team.

In this article, we won't just compare features; we'll analyze what you are really "buying" with each.

The Fundamental Question: What Are You Buying?

Before looking at the tools, you must decide what problem you're trying to solve:

Are you buying speed? Do you want a minimalist task runner that you can add to your existing project to make your scripts fly, without getting in your way?
Are you buying an ecosystem? Do you want a complete framework that guides you, offers code generators, enforces architectural rules, and helps you manage complexity long-term, in addition to being fast?

Your answer to this question will almost instantly lean you toward one of the two solutions.

🚀 Option A: Turborepo (The F1 Engine)

Turborepo (acquired by Vercel) is a high-performance task runner. Its philosophy is minimalism and pure speed.

It focuses on one thing and does it exceptionally well: understanding the dependencies of your package.json scripts and executing tasks in parallel, aggressively caching the results.

Its configuration is simple, often a single turbo.json file in the root, where you define your pipelines.

✅ The Good: The Speed Argument

Adoption in Minutes: You can add Turborepo to an existing monorepo (managed with pnpm, yarn, etc.) in under 10 minutes and see immediate speed improvements.
Minimalist (Not Intrusive): It doesn't force you to restructure your project. It's still "your" monorepo; Turborepo just handles running the scripts defined in your package.json.
Simple Remote Caching: It integrates natively with Vercel for shared remote caching, which is pure gold for CI pipelines.

⛔ The Critique: Speed Without Direction

Turborepo gives you an incredibly fast car, but it doesn't give you a map or a seatbelt.

It only solves the problem of execution speed. It doesn't help you with architecture. It doesn't stop you from creating circular dependencies, offer generators to create new components consistently, or give you a visualizer for the chaos you might be creating.

The responsibility for architecture, coherence, and best practices falls 100% on your team's discipline.

🛠️ Option B: Nx (The Construction Kit)

Nx (by Nrwl) is an integrated workspace ecosystem. Speed is just one of its features, not its sole purpose.

Nx's philosophy is that a healthy monorepo needs more than speed: it needs structure, consistency, and governance. It offers a set of "opinionated" tools to build, test, and deploy your code.

✅ The Good: The Architecture Argument

Code Generators: Its strongest feature. It allows you to generate applications, libraries, and components with a single command, ensuring they all follow the same structure.
Dependency Analysis (affected): Nx understands your code at a deep level. It can run tasks (like tests) only on the projects that have been affected by your changes. This is much smarter than a simple cache.
Module Boundaries (Governance): For me, this is its hidden gem. Nx allows you to define architectural rules. For example: "The frontend app cannot import code directly from the backend app." This actively prevents technical debt.
Visualization: It includes an interactive visualizer for your project's dependency graph.

⛔ The Critique: The Price of an Opinion

Nx is "heavy" and "magical." Its power comes at a cost:

Learning Curve: You have to "buy into" the Nx philosophy. It requires a more complex setup (multiple project.json files or package.json configuration) and learning its CLI.
Intrusive: Migrating an existing project to Nx is much more complex than adding Turborepo. Nx wants to manage your workspace its way.
Cognitive Overhead: Sometimes, doing something simple that falls outside the standard generators can be frustrating if you don't understand how the "magic" works under the hood.

Quick Comparison: Nx vs. Turborepo

Feature	🚀 Turborepo	🛠️ Nx
Main Purpose	Fast Task Execution	Workspace Management
Configuration	Minimalist (`turbo.json`)	Detailed (`nx.json`, `project.json`)
Code Generation	No	Yes (Extensive, plugin-based)
Architecture Rules	No	Yes (Module Boundaries)
Dependency Graph	No	Yes (Interactive)
`affected` Commands	No (Cache-based)	Yes (Deep Graph Analysis)
Adoption Curve	Very Low	Medium / High
Best for...	Speeding up existing projects	Starting new, complex projects

The Verdict: What Should You Choose?

As an experienced software engineer, my answer always goes beyond the tool itself: "It depends on your strategic and team goals."

➡️ You should choose Turborepo if...

Your main (and perhaps only) problem is that your CI/CD and local builds are slow.
You have an existing monorepo and don't want to perform a costly migration.
You have a senior, disciplined team that can self-manage architecture without needing tools to enforce it.
You value minimalism and flexibility over structured guidance.

➡️ You should choose Nx if...

You are starting a new project and want a solid structure from day zero.
Your project is large, complex, and needs long-term maintainability.
You have teams of varying seniority and need tools to ensure consistency and best practices.
You value architectural governance (avoiding "spaghetti code") as much as or more than execution speed.

Conclusion (The Dave Stack's Take)

The choice between Nx and Turborepo defines your project's trajectory.

Turborepo is a tactical tool that offers a quick, impressive win.
Nx is a strategic tool that requires an initial investment but pays dividends in long-term maintainability and scalability.

At The Dave Stack, the approach I want to promote and share is that of building software that not only works today but is sustainable tomorrow. That's why, for most new and complex projects, I tend to lean towards the governance and structure that Nx provides. In fact, for TypeScript-based projects, Nx has become my go-to tool, as I explain in detail in my article Nx: Why It's Become My Favorite Tool for TypeScript Projects.

At the end of the day, the right tool is the one that aligns with your team and business strategy.

Now it's your turn: Nx or Turborepo?

You've read my analysis, now I want to know yours. What tool do you use in your day-to-day, and why? Do you value Nx's governance more, or Turborepo's minimalist speed?

Share your experience in the comments. The discussion enriches the entire community.

DeepSeek Does It Again: From MoE to DSA, The New Era of LLM Efficiency

David (ダビッド ) — Mon, 20 Oct 2025 15:09:43 +0000

Header image sourced from Chat-Deep

Original post.

Introduction: The Invisible Wall of LLMs

In the fast-paced world of Artificial Intelligence, we often marvel at the size and capabilities of new Large Language Models (LLMs). However, behind every breakthrough lies an invisible wall—a fundamental challenge that limits their scalability and accessibility: computational cost. The team at DeepSeek AI seems to have made tearing down this wall their specialty.

First, they introduced us to their DeepSeek-V2 model with its groundbreaking Mixture-of-Experts (MoE) architecture, a clever way to scale models by activating only a fraction of their parameters for each task. And now, they've done it again. With the release of DeepSeek-V3.2-Exp, they are tackling another pillar holding up that wall: the complexity of the attention mechanism.

The Core Problem: The Tyranny of Quadratic Complexity ($O(L^2)$)

To grasp the magnitude of this innovation, we first need to talk about the enemy: quadratic complexity ($O(L^2)$) within the Transformer's attention mechanism.

Since its inception, attention has allowed models to understand the relationships between words in a text. To do this, each new token being processed must "attend" to every single token that came before it. This is incredibly powerful, but it comes at a cost.

In simple terms, quadratic complexity means that if you double the length of the text (the context), the computational cost and processing time don't just double—they quadruple. If you triple it, the cost multiplies by nine. This creates an exponential bottleneck that makes processing very long documents, entire codebases, or books prohibitively expensive and slow.

The Solution: DeepSeek Sparse Attention (DSA)

DeepSeek-V3.2-Exp introduces an elegant solution to this problem: DeepSeek Sparse Attention (DSA). Instead of "dense" attention (all-to-all), DSA implements "sparse" attention, where each token only attends to the most relevant preceding tokens.

How does it achieve this? The architecture relies on two main components:

Lightning Indexer: This is the brains of the operation. It's a highly efficient component that, before the main attention calculation, computes an "index score" ($I_{t,s}$) between the current query token and all previous tokens. This score determines relevance. Its design is key to its efficiency, as it uses few heads and can be implemented in FP8.
Fine-grained Token Selection: Based on the indexer's scores, this mechanism is purely selective. It retrieves only the key-value entries corresponding to the top-k (the 'k' best) index scores. In the paper, for instance, they mention selecting 2048 key-value tokens for each query.

The result is that the main attention calculation is no longer performed over the entire sequence but on a small, relevant subset of tokens. This changes the game, reducing the attention complexity from $O(L^2)$ to $O(Lk)$, where 'k' is a fixed number far smaller than the context length 'L'.

The Results: Radical Efficiency Without Sacrificing Performance

This is where DeepSeek's approach truly shines. This isn't just a theoretical optimization; the results are tangible and, most importantly, achieved without a significant drop in performance.

On-Par Performance: Benchmark comparisons show that DeepSeek-V3.2-Exp does not exhibit substantial performance degradation compared to its predecessor, DeepSeek-V3.1-Terminus. On key benchmarks like MMLU-Pro, the score is identical (85.0), and variations in others are minimal.

Drastic Cost Reduction: Figure 3 from the paper is conclusive. It shows how the cost per million tokens—for both prefilling (processing the initial prompt) and decoding (generating the response)—skyrockets linearly for the older model as the context length increases. In contrast, with DSA, the cost curve flattens dramatically, demonstrating massive savings in long-context scenarios.

You can find a more detailed analysis in their paper.

What This Means for the Future

From my perspective, focusing on custom software development and AI implementation, this breakthrough is more than just an incremental improvement; it's an enabler.

The Era of Hybrid Architectures: DeepSeek is showing us the way forward. The future isn't a single solution but the intelligent combination of efficient architectures. Imagine a model that combines the parameter efficiency of MoE with the context efficiency of DSA. We would be looking at a new generation of LLMs that are fundamentally more scalable and cost-effective.
New Frontiers for Applications: With lower costs for long-context tasks, use cases that were once prohibitive are now viable. Think of AI agents that can analyze and reason over entire code repositories in real-time, legal assistants that can review thousands of pages of case law instantly, or financial analysis systems that process full annual reports in a single pass.
The Democratization of Power: Efficiency doesn't just benefit large corporations. Lower training and, crucially, inference costs allow startups, freelance developers, and smaller companies to access and deploy state-of-the-art models to build custom solutions.

Ultimately, DeepSeek is cementing its reputation as a team that doesn't just chase raw performance but tackles the fundamental engineering problems that will allow us to build the next generation of AI applications. And it's fascinating to see how this race for efficiency—driven in part by US hardware restrictions on China—is sparking software innovations that benefit us all. It's the classic story of necessity breeding ingenuity, and in the AI race, architectural ingenuity may prove to be more decisive than the brute force of silicon.

First MoE, now DSA. They are, without a doubt, a team to watch.

What are your thoughts? How do you see these new advancements shaping the future? Leave a comment below!

I'm also leaving a link to their card on Hugging Face so you can dig deeper into this new model.

Your Website Speaks to Humans, But Does AI Understand It? A Deep Dive into the Dual Web Strategy

David (ダビッド ) — Tue, 14 Oct 2025 18:05:40 +0000

Original Post

For years, we've been obsessed with SEO, optimizing every H1, every alt tag, and every meta description to please Google. But the game has changed. A new audience is now consuming our content without ever visiting our websites: generative artificial intelligence.

Many organizations are creating incredible content—detailed technical articles, product documentation—only to find that when you ask ChatGPT or Google's SGE about it, they are either ignored or, worse, given a mediocre or flat-out incorrect summary.

This is one of the biggest challenges facing the web today. A recent whitepaper from DualWeb.AI has given a name and a method to a fascinating solution, and in this post, we're going to break it down in detail.

The Diagnosis: Why AI Gets Lost on Your Website

The modern web—rich with JavaScript, frameworks like React and Vue, interactive designs, and dynamic content loading—is a fantastic experience for humans. But for an AI crawler, it's a minefield.

These crawlers often only read the initial HTML returned by the server. Anything loaded dynamically or dependent on complex user interactions is, in practice, invisible to them. Furthermore, our marketing language, full of metaphors and suggestive copy, is ambiguous to a machine searching for concrete facts and data.

The result is a twofold problem:

Invisibility: The AI doesn't "see" key information, so your brand gets omitted from generated answers.
Inaccuracy: The AI misinterprets the content it does see, mixing up data or "hallucinating" information that damages your brand's credibility.

This is critical in a world where the "zero-click" trend—getting the answer without visiting the source—is becoming increasingly dominant. Being featured in these AI summaries isn't an option; it's the new SEO battleground.

The Proposed Solution: "Dual Web"

The "Dual Web" concept is as simple in its logic as it is powerful in its execution: serve each audience the format it needs.

The strategy relies on a technical framework that:

Detects Traffic Type: It distinguishes in real-time whether a visitor is a human or a known AI crawler (like those from OpenAI or Perplexity).
Delivers Tailored Content:
- To humans, it serves the canonical, visual, and interactive website, keeping the user experience and traditional SEO intact.
- To AI, it serves a simplified version of the same page—structured content with clear data points and no visual or navigational "noise," making it ideal for automated processing.

The results presented in their 100-page study are striking, to say the least: the inclusion rate in AI answers jumped from 38% to 88%, and data accuracy improved from 63% to 85%. These are numbers you simply can't ignore.

This Isn't Theory, It's Happening Now: The Market is Moving

This approach isn't just an idea in a whitepaper. Major players are already implementing similar solutions.

A brilliant example is Docker's documentation. If you browse their pages, you'll find a "Page Options" menu with a feature called "Copy page as Markdown for LLMs." With a single click, you get a clean, structured version of the content, ready to be pasted into an AI prompt. They aren't waiting for AI to understand them; they're handing it the content on a silver platter.

Inspired by this proactive vision, at The Dave Stack, we are developing a similar solution for our own website. We're building a service in NestJS that connects to our Ghost CMS and automatically generates a Markdown version of each post. The idea is simple: if our server detects a request from a known AI crawler, instead of serving the full webpage, it will deliver this clean, direct Markdown. It's a demonstration that we practice what we preach. We'll showcase this project in future posts.

A Critical Look: It's Not That Simple

However, it's crucial to apply a critical eye to this proposal. The "Dual Web" approach is powerful, but it opens up an important technical debate.

The Shadow of "Cloaking": The first thing a seasoned SEO expert will think is, "Isn't this cloaking?" Cloaking—showing different content to bots and humans to manipulate rankings—is a practice penalized by Google. The argument from Dual Web is that the intent is not to deceive but to clarify, and the substance of the information remains the same. It's a fine line. The current perspective is that as long as the goal is to improve accuracy and not to alter traditional search rankings, the risk is low. But this is a debate the SEO and AI communities will have to navigate.
Technical Feasibility: The implementation is not trivial. It requires server-level or edge-level access to intercept requests and rewrite responses based on user-agents. How can this be done in modern architectures?

On Vercel or Netlify, you could use Edge Functions to run this logic.
With Cloudflare, Workers are the perfect tool for the job.
On a VPS, a configuration in Nginx or an application middleware (like the one we're developing with NestJS) is the way to go. The solution is not plug-and-play; it requires technical expertise.

Alternatives to Consider: Is Dual Web the only way? No. Other alternatives could be:

Extreme Structured Data (Schema.org): Taking Schema.org markup to an obsessive level of detail to give AI as much context as possible.
llms.txt Files: A proposed standard (even mentioned in the Dual Web whitepaper itself) where you offer a curated summary of your site in a text file.
Content APIs: Exposing your content through an API so AIs can consume it in a structured way.

Conclusion: The Next Step in Digital Evolution

The AI era doesn't ask us to abandon SEO; it demands that we expand it. The concept of Generative Engine Optimization (GEO) is already here, and strategies like "Dual Web" are at the forefront.

It's no longer enough to write for humans and hope that machines will understand. We must be proactive, bilingual, and make their job easier. The reward is enormous: visibility, accuracy, and control over our brand's narrative in the world's new default interface—the conversation with an AI.

For those of us who make a living building and communicating in the digital world, the question is no longer if we should optimize for AI, but how and with what urgency. And the answer is: now.

PostgreSQL 18 Uncovered: Asynchronous I/O, UUIDv7, and Pain-Free Upgrades

David (ダビッド ) — Tue, 30 Sep 2025 11:32:41 +0000

Original post

As is tradition around this time of year, the global PostgreSQL community has surprised us with a new major version, and this time is no exception. On September 25th, the PostgreSQL Global Development Group officially released PostgreSQL 18. I'll tell you right now: it's one of the most exciting updates in recent years, especially if you're obsessed with performance and operational efficiency.

In this article, we'll break down the official announcement to uncover the new features that will genuinely change the way we work—from developing custom software to deploying high-availability architectures. Forget minor tweaks; these are game-changing improvements. Let's dive in!

The Key New Features in PostgreSQL 18

After analyzing the announcement, I've identified four areas that I consider revolutionary.

🚀 The Headliner: Asynchronous I/O (AIO) for a Massive Performance Boost

This is the crown jewel of PostgreSQL 18. Until now, Postgres relied on the operating system's readahead mechanisms to speed up data retrieval, but this isn't always efficient.

PostgreSQL 18 introduces a new Asynchronous I/O (AIO) subsystem. Instead of requesting a block of data and waiting, it can now issue multiple I/O requests in parallel.

What does this mean? For operations that read a lot of data from disk (like sequential scans, VACUUM, etc.), the impact is huge. Community benchmarks have shown performance improvements of up to 3x in certain scenarios.
How do you use it? It's controlled by the new io_method parameter, which lets you choose between different implementations like io_uring (on Linux) or stick with the classic synchronous behavior.

Bottom line: If you have a read-intensive (I/O-bound) workload, like analytics systems or applications with large datasets, you're going to see a night-and-day difference.

😌 Upgrades Are Finally Pain-Free

Anyone who has managed a production database knows the post-upgrade dread: queries run slow until ANALYZE rebuilds the planner statistics. PostgreSQL 18 tackles this problem head-on.

Statistics Preservation: Finally! It's now possible to keep planner statistics during a major version upgrade. This means your database will perform at its optimal level almost immediately after upgrading, eliminating that painful performance degradation phase.
Faster pg_upgrade: The upgrade utility itself has been optimized. It can now run checks in parallel (--jobs) and has a new --swap option that exchanges data directories instead of copying them, dramatically speeding up the process.

Bottom line: The process of upgrading to a new major version will be much faster and less disruptive to your applications.

💻 Developer Gems You'll Love

This release is packed with features that make our lives easier and allow us to write more modern and efficient code.

Say Hello to uuidv7()!: A native function to generate v7 UUIDs has been added. Unlike random v4 UUIDs, v7 UUIDs are time-ordered. Using them as primary keys drastically improves B-Tree index performance by reducing fragmentation and improving data locality. This is a fundamental change for high-insertion tables!
Virtual Generated Columns: Generated columns (GENERATED COLUMNS) are now virtual by default. This means the value is computed at query time instead of being stored on disk, saving space for values that aren't needed constantly.
RETURNING with OLD and NEW: DML statements (INSERT, UPDATE, DELETE, MERGE) can now access both the old (OLD) and new (NEW) values directly in the RETURNING clause. This is fantastic for creating audit logs or implementing change data capture logic in a single query.

Bottom line: Native tools for modern design patterns that previously required more complex workarounds.

🛡️ Authentication, Security, and Important Changes to Note

Native OAuth 2.0 Support: This is one of the hidden gems of the release, especially for professional environments. In practice, it means you can now authenticate database users through external identity providers like Auth0, Okta, Microsoft Entra ID (Azure AD), or Google. Technically, this is enabled directly in the pg_hba.conf file with a new oauth authentication method. You configure key parameters like the issuer (your identity provider's URL) and the scope (the permissions the access token must have). The token validation itself is modular and delegated to specialized libraries, making the system highly flexible. The result is that instead of managing local passwords, you can delegate authentication to your central Single Sign-On (SSO) system. This not only radically simplifies user management but also elevates security by enabling centralized policies like multi-factor authentication (MFA).
The End of an Era: MD5 Deprecation: Although secure authentication with SCRAM has been available for several versions, PostgreSQL 18 takes the final step: it officially deprecates the use of MD5 for passwords. Support will be completely removed in a future release, so there are no more excuses. The community's message is clear: if you're still using MD5, migrating to SCRAM is an urgent and high-priority task.
Default Checksums: New clusters created with initdb will now have page checksums enabled by default. This improves data integrity but is a crucial detail to consider when planning an upgrade from a cluster without them.

My Critical Perspective: What This Means for Your Projects

Is Asynchronous I/O a silver bullet? No. It's a powerful tool for I/O-bound workloads. If your bottleneck is the CPU, you won't see a magical improvement. But for deploying analytics applications or AI services that process large volumes of data, the impact will be enormous.
The Real Operational Game-Changer: While AIO gets the headlines, I believe preserving statistics on upgrades is the single most important feature for production systems. It eliminates one of the biggest headaches and risks associated with an upgrade, reducing uncertainty and making it easier to keep your tech stack up to date.
For Custom Software Development: My recommendation is to start using uuidv7() as the default primary key on all new tables where it makes sense. It's an easy and free performance win. The improvements to RETURNING will also greatly simplify audit logic in the backends I build.
The Ace Up Your Sleeve for Professional Projects (OAuth 2.0): Don't underestimate this feature. If you build custom software for businesses, as I do, offering integration with their SSO system (like Microsoft 365 or Google Workspace) is no longer a nightmare. It's an enterprise-grade feature that now comes standard, allowing you to sell more secure and better-integrated projects into your clients' ecosystems. It's a powerful differentiator.
Immediate Call to Action: Audit your systems. If you're still using MD5 authentication, plan your migration to SCRAM now. This isn't a suggestion; it's an imminent security requirement.

🛠️ Hands-On: Test PostgreSQL 18 with Docker and Examples

To understand why the deprecation of MD5 is such a big deal, there's nothing like seeing it in action. We'll use Docker to set up a lab with two parallel instances of PostgreSQL 18: one configured to use the old and now-obsolete MD5 method, and another using the modern and secure SCRAM, which has been the recommended method for years. This way, you can see the security difference for yourself.

Requirements

To execute these examples you will need to install Docker.

Step 1: Set Up the Comparison Environment

Create a file named docker-compose.yml. Notice that we're defining the two databases (db_md5 and db_scram), the adminer web interface, and an extra container named pg_client that will act as our toolbox with psql pre-installed.

docker-compose.yml (MD5 vs. SCRAM Comparison)

services:
  db_md5:
    image: postgres:18
    container_name: postgres18_md5
    restart: always
    command: postgres -c password_encryption=md5 -c io_method=sync
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: testdb
    ports:
      - "5432:5432"
    volumes:
      - postgres_data_md5:/var/lib/postgresql/data

  db_scram:
    image: postgres:18
    container_name: postgres18_scram
    restart: always
    environment:
      POSTGRES_USER: user
      POSTGRES_PASSWORD: password
      POSTGRES_DB: testdb
    ports:
      - "5433:5432"
    volumes:
      - postgres_data_scram:/var/lib/postgresql/data

  pg_client:
    image: postgres:18
    container_name: pg_client
    # This command keeps the container running so we can exec into it
    command: tail -f /dev/null

  adminer:
    image: adminer
    container_name: postgres18_adminer
    restart: always
    ports:
      - "8080:8080"

volumes:
  postgres_data_md5:
  postgres_data_scram:

In a terminal, run docker-compose up -d or docker compose up -d. Your entire environment is now ready, with no need to install anything else on your machine.

Note: The password for the user in all connections that require it (psql, Adminer) is password, as defined in the docker-compose.yml file.

Step 2: Run the Examples and Compare

For the terminal examples, we'll use our pg_client container.

How to use the terminal:

Open a shell session inside the client container with this command:

   docker exec -it pg_client bash

Once inside (you'll see a prompt like root@...:/#), you can run psql commands against the databases using their service names (db_scram or db_md5).

Connect to the SCRAM (secure) instance:

Terminal: Inside the pg_client container, run:

  psql -h db_scram -U user -d testdb

Adminer (http://localhost:8080): Server: db_scram

Example 1: The new `uuidv7()`

-- Compare the results of the two UUID types
SELECT uuidv4(), uuidv7();

Run the query a few times. You'll notice that uuidv4() values are completely random, while uuidv7() values start with a similar sequence that changes slightly. That initial part is the timestamp, which allows the index to sort them efficiently!

testdb=# SELECT uuidv4(), uuidv7();
                uuidv4                |                uuidv7                
--------------------------------------+--------------------------------------
 a3c361d2-4aa2-49fe-84fd-247d249484e0 | 019999e7-70ce-7e41-ad73-97cd6e42f2a8
(1 row)

testdb=# SELECT uuidv4(), uuidv7();
                uuidv4                |                uuidv7                
--------------------------------------+--------------------------------------
 3c8115a7-8667-47e2-971c-b7ce61504572 | 019999e7-7713-75db-a7ff-e7c2ebbfb47f
(1 row)

testdb=# SELECT uuidv4(), uuidv7();
                uuidv4                |                uuidv7                
--------------------------------------+--------------------------------------
 1fc5216d-a874-418b-abcb-0fd389823abc | 019999e7-7c0f-7a0a-a364-6a3a536a0b6c
(1 row)

Example 2: Virtual Generated Columns

CREATE TABLE products (
    name TEXT,
    price_eur NUMERIC,
    price_usd NUMERIC GENERATED ALWAYS AS (price_eur * 1.07) VIRTUAL
);

INSERT INTO products (name, price_eur) VALUES ('Mechanical Keyboard', 80);

SELECT * FROM products;

The price_usd column doesn't take up disk space; it's calculated every time you query it.

testdb=# CREATE TABLE products (
    name TEXT,
    price_eur NUMERIC,
    price_usd NUMERIC GENERATED ALWAYS AS (price_eur * 1.07) VIRTUAL
);
CREATE TABLE
testdb=# INSERT INTO products (name, price_eur) VALUES ('Mechanical Keyboard', 80);
INSERT 0 1
testdb=# SELECT * FROM products;
        name         | price_eur | price_usd 
---------------------+-----------+-----------
 Mechanical Keyboard |        80 |     85.60
(1 row)

Example 3: `RETURNING` with `OLD` and `NEW` Values

CREATE TABLE price_audit (
    product_name TEXT,
    old_price NUMERIC,
    new_price NUMERIC,
    changed_at TIMESTAMPTZ DEFAULT now()
);

WITH updated AS (
    UPDATE products
    SET price_eur = 85
    WHERE name = 'Mechanical Keyboard'
    RETURNING OLD.name, OLD.price_eur AS old_price, NEW.price_eur AS new_price
)
INSERT INTO price_audit (product_name, old_price, new_price)
SELECT name, old_price, new_price FROM updated;

SELECT * FROM price_audit;

It's like magic! No complex triggers or double queries needed.

testdb=# CREATE TABLE price_audit (
    product_name TEXT,
    old_price NUMERIC,
    new_price NUMERIC,
    changed_at TIMESTAMPTZ DEFAULT now()
);
CREATE TABLE
testdb=# WITH updated AS (
    UPDATE products
    SET price_eur = 85
    WHERE name = 'Mechanical Keyboard'
    RETURNING OLD.name, OLD.price_eur AS old_price, NEW.price_eur AS new_price
)
INSERT INTO price_audit (product_name, old_price, new_price)
SELECT name, old_price, new_price FROM updated;
INSERT 0 1
testdb=# SELECT * FROM price_audit;
    product_name     | old_price | new_price |          changed_at           
---------------------+-----------+-----------+-------------------------------
 Mechanical Keyboard |        80 |        85 | 2025-09-30 09:16:50.260192+00
(1 row)

Step 3: Experimenting with Asynchronous I/O (AIO)

Demonstrating a performance improvement like AIO in a simple example is tricky, as it heavily depends on your hardware (especially your disk speed). However, we can set up a small lab for you to experiment and measure the impact on your own system.

With our Docker setup, we have the perfect lab: the db_md5 service starts with synchronous I/O (io_method=sync), and the db_scram service uses the PostgreSQL 18 default, which is with AIO enabled.

1. Prepare a Large Dataset

We'll use pgbench, a tool included with PostgreSQL, to create test data in both instances.

From your terminal, run these two commands. Each will take a couple of minutes to populate its respective database with ~1.5 GB of data:

  # Populate the database WITHOUT AIO (db_md5)
  docker exec pg_client bash -c "PGPASSWORD=password pgbench -i -s 100 -h db_md5 -U user testdb"

  # Populate the database WITH AIO (db_scram)
  docker exec pg_client bash -c "PGPASSWORD=password pgbench -i -s 100 -h db_scram -U user testdb"

2. Run the Tests and Compare

For a fair comparison, we'll first restart both containers to clear memory caches.

From your terminal, run:

  docker restart postgres18_md5 postgres18_scram

Wait a few seconds for the databases to start up.

Now, enter the client container to run the tests:

  docker exec -it pg_client bash

Test on the server WITHOUT AIO:

  # Connect to db_md5 and measure the time
  PGPASSWORD=password psql -h db_md5 -U user -d testdb -c "\timing on" -c "SELECT count(*) FROM pgbench_accounts;"

Take note of the time it returns.

  root@5dfdfaef5e1a:/# PGPASSWORD=password psql -h db_md5 -U user -d testdb -c "\timing on" -c "SELECT count(*) FROM pgbench_accounts;"
  Timing is on.
    count   
  ----------
   10000000
  (1 row)

  Time: 828.820 ms

Test on the server WITH AIO:

  # Connect to db_scram and measure the time
  PGPASSWORD=password psql -h db_scram -U user -d testdb -c "\timing on" -c "SELECT count(*) FROM pgbench_accounts;"

Take note of this second time.

  root@5dfdfaef5e1a:/# PGPASSWORD=password psql -h db_scram -U user -d testdb -c "\timing on" -c "SELECT count(*) FROM pgbench_accounts;"
  Timing is on.
    count   
  ----------
   10000000
  (1 row)

  Time: 539.800 ms

3. Analyze the Results

Compare the time from the second test (WITH AIO) with the first (WITHOUT AIO). On a system with fast disks (SSD/NVMe), you should see a noticeable reduction in execution time. In my case, the time dropped from 828.820 ms to 539.800 ms, an improvement of 34.87%.

Important: The improvement you see will depend heavily on your hardware, operating system, and Docker configuration. The goal of this experiment is to give you the tools to measure it in your own environment.

Step 4: The Definitive Authentication Comparison

Now, let's create a user on each database to see the crucial difference.

1. On the MD5 (insecure) instance:
Connect to it:

Terminal: Inside the pg_client container, run:

  psql -h db_md5 -U user -d testdb

Adminer: Server: db_md5

And run the following SQL:

CREATE USER test_md5_user WITH PASSWORD 'a_simple_password';
SELECT rolname, rolpassword FROM pg_authid WHERE rolname = 'test_md5_user';

The result will show the easily identifiable MD5 hash:

testdb=# CREATE USER test_md5_user WITH PASSWORD 'a_simple_password';
WARNING:  setting an MD5-encrypted password
DETAIL:  MD5 password support is deprecated and will be removed in a future release of PostgreSQL.
HINT:  Refer to the PostgreSQL documentation for details about migrating to another password type.
CREATE ROLE
testdb=# SELECT rolname, rolpassword FROM pg_authid WHERE rolname = 'test_md5_user';
    rolname    |             rolpassword             
---------------+-------------------------------------
 test_md5_user | md5fb0260dca3cede73533e7b3a2878807b
(1 row)

2. On the SCRAM (secure) instance:
Connect to it:

Terminal: Inside the pg_client container, run:

  psql -h db_scram -U user -d testdb

Adminer: Server: db_scram

And run this other SQL:

CREATE USER test_scram_user WITH PASSWORD 'a_better_password';
SELECT rolname, rolpassword FROM pg_authid WHERE rolname = 'test_scram_user';

The result is radically different and much more robust:

testdb=# CREATE USER test_scram_user WITH PASSWORD 'a_better_password';
CREATE ROLE
testdb=# SELECT rolname, rolpassword FROM pg_authid WHERE rolname = 'test_scram_user';
     rolname     |                                                              rolpassword                                                              
-----------------+---------------------------------------------------------------------------------------------------------------------------------------
 test_scram_user | SCRAM-SHA-256$4096:aZ2+SHpETCGDXKENOKupcA==$RlOpd+bI6rtWQmrqsQg69v7m1A1WPeL+tYqG1IUz9wk=:hJfldXgHIIhsZR35pzJ5EiGbp7MPGEKkljho2Ju2dxY=
(1 row)

This side-by-side comparison leaves no room for doubt. With a single docker-compose up command, we've created a perfect lab to visualize why the community has finally decided to pull the plug on MD5 and why SCRAM is the standard you should already be using.

Conclusion

PostgreSQL 18 is a mature and impactful release. It doesn't focus on adding hundreds of minor features but instead on solving fundamental problems at scale: I/O performance, the pain of upgrades, and efficiency in modern development patterns.

It's a statement of intent that solidifies PostgreSQL not just as a robust and reliable database, but as a high-performance data platform ready for the challenges of the future.

Now it's your turn. What feature are you most excited about? Are you going to start testing Asynchronous I/O? Let me know in the comments!

Source and Further Reading

Official Announcement: PostgreSQL 18 Released!

Don't Miss the Java 25 Launch Livestream Today!

David (ダビッド ) — Tue, 16 Sep 2025 07:50:23 +0000

Today is a big day for the Java community! The official launch livestream for Java 25 is happening, and the schedule is packed with deep dives into the new features and the future of the platform.

Here's everything you need to know to catch the event.

When: Today, September 16th, starting at 15:00 UTC.
Where to Watch: Official Event Page

Full Livestream Schedule (UTC)

15:00 - Welcome and Event Agenda 🗓️
15:05 - Performance Updates from Java 21 to 25 📈
15:15 - Method Timing & Tracing with JDK Flight Recorder ✈️
15:25 - Using Flexible Constructor Bodies 🤸
15:30 - Exploring Java's On-Ramp and Scripting Features 🧩
15:50 - Amber, OpenJDK, and Community 🌎
16:15 - Upgrading to Java 25 ⬆️
16:25 - Security Updates 🔐
16:40 - Scoped Values 🔬
16:50 - Stream Gatherers 🌊
17:10 - Evolution of Java AI Libraries 📚
17:20 - Ahead-of-Time In-Action 🏋️
17:25 - Beyond Java 21 at Netflix Scale 🍿
17:55 - API Updates Post-Java 21 🔌
18:10 - Java for AI 🤖
18:40 - Growing the Java Platform ☕️
18:55 - Closing 🏁

What About You?

Which talks are on your must-watch list? Are there any specific JEPs you've been following that are landing in Java 25?

Drop your thoughts in the comments below!

Designing APIs for the AI Era with Spring AI and MCP

David (ダビッド ) — Mon, 08 Sep 2025 08:59:32 +0000

Original post

As backend developers, we've been building robust REST APIs for years. We design them to be consumed by our UIs, mobile apps, or other microservices. It's a paradigm we've mastered. But what if I told you that with minimal effort, that same API could have a second interface—one that allows AI agents to interact with your business logic using natural language?

Today, thinking about artificial intelligence isn't an afterthought; it's a design strategy. It's not just about creating a service that responds to GET or POST requests, but about asking ourselves: how can an AI model consume my service to provide extra value?

For those of us developing with Java, thanks to Spring AI, this idea has shifted from a complex task to a simple extension of what we already do. In this post, we'll explore how incredibly easy it is to add an MCP (Model Context Protocol) Server to an existing Spring Boot application, using a real-world API for managing a product catalog as our example.

The Dual API Paradigm: REST for Machines, MCP for AI 🤖

A REST API is great for structured machine-to-machine communication. But an AI agent doesn't think in terms of JSON or endpoints.

This is where the MCP Server comes in. It acts as a translator, exposing your application's logic in a way that an LLM (Large Language Model) can understand and use. This allows you to have the best of both worlds:

Your traditional REST API, stable and reliable for your applications.
An MCP Server, offering a native interface for AI integration.

This approach forces you to design from the outset with the functions (Tools), data (Resources), and guides (Prompts) that an intelligent agent would need to operate autonomously within your domain.

What is the Model Context Protocol?

The Model Context Protocol (MCP) is the standard that defines how an AI model can discover and use your application's capabilities in a secure and structured way. It provides the AI with the necessary context about what actions it can perform and what information it can query.

This protocol is built on three pillars: Tools, Resources, and Prompts. If you want to dive deeper into how it works and what each of these concepts means, you can read my more detailed post: Model Context Protocol Exposed: The Power of Resources and Prompts Beyond Tools.

For this article, the key takeaway is seeing how easy it is to implement these three pillars with Spring AI.

From @RestController to MCP Server

To demonstrate this, I'll use my Product Catalog project.

Step 0: Build Your Traditional Spring Boot Service

I won't spend much time on this point because creating the foundation for a Spring Boot project is almost trivial using https://start.spring.io/. I'll also leave a link to their documentation if you want more details: Getting Started | Building an Application with Spring Boot.

Step 1: Configuration is a Breeze

Once you have your Spring Boot service, you just need to add the Spring AI dependency and enable the server. To manage versions centrally, we add the Spring AI "Bill of Materials" (BOM) to the <dependencyManagement> section of your pom.xml:

<dependencyManagement>  
    <dependencies>  
        <dependency>  
            <groupId>org.springframework.ai</groupId>  
            <artifactId>spring-ai-bom</artifactId>  
            <version>1.0.0</version>  
            <type>pom</type>  
            <scope>import</scope>  
        </dependency>  
    </dependencies>  
</dependencyManagement>

Next, in your <dependencies> section, you only need to add the MCP server starter, which in this case is spring-ai-starter-mcp-server-webmvc:

<dependencies>  
    <dependency>  
        <groupId>org.springframework.ai</groupId>  
        <artifactId>spring-ai-starter-mcp-server-webmvc</artifactId>  
    </dependency>  
</dependencies>

Finally, in your application.properties, you enable and configure the server. It's that simple:

# application.properties

# Enable the MCP server  
spring.ai.mcp.server.enabled=true  
spring.ai.mcp.server.name=product-catalog-mcp-server  
spring.ai.mcp.server.version=1.0.0

# Define general instructions for the AI  
spring.ai.mcp.server.instructions=A server for managing a product catalog with AI-powered tools, resources, and guides.

# Enable the capabilities you want to expose  
spring.ai.mcp.server.capabilities.tool=true  
spring.ai.mcp.server.capabilities.resource=true  
spring.ai.mcp.server.capabilities.prompt=true

With just these few lines, your application now has a functional MCP server.

Step 2: Implementing the MCP Features

Now that we have the Spring AI dependencies and the MCP starter, it's time to dive in.

2.1: Expose Your Services as Tools

You already have the business logic in your @Service classes. To expose a method as a tool for the AI, you just need one annotation: @Tool.

@Tool(
    description =
        "Creates a new product in the catalog with comprehensive validation and audit logging. Required fields: name, price, category, stockQuantity, minStockLevel. Optional fields: description, SKU (auto-generated if not provided), weight, dimensions, imageUrl. SKU must be globally unique if provided. Automatically creates audit log entry. Throws DuplicateSkuException for duplicate SKUs. Use this for adding new products to the inventory system.")
@Transactional
public Product createProduct(
    @ToolParam(
        description =
            "Product object with required fields: name, price, category, stockQuantity, minStockLevel. Optional: description, sku, weight, dimensions, imageUrl")
    Product product) {
...
}

And that's it! Your createProduct method is now a tool that any AI agent can invoke.

2.2: Expose Live Data with Resources

A Resource acts as a live data feed for the AI. Instead of having static data in a prompt, you can expose information that changes within your application, like a list of product categories.

To do this, we define a URI (e.g., categories://overview/all) and associate it with a function that returns the data.

public List<McpServerFeatures.SyncResourceSpecification> getResourceSpecifications() {
    return List.of(
            // All categories overview resource
            new McpServerFeatures.SyncResourceSpecification(
                    new McpSchema.Resource(
                            "categories://overview/all",
                            "All Categories Overview",
                            "Complete overview of all product categories with descriptions and guidelines",
                            "application/json",
                            null),
                    this::getAllCategoriesResource),
            ...
            );
}

private McpSchema.ReadResourceResult getAllCategoriesResource(
        McpSyncServerExchange exchange, McpSchema.ReadResourceRequest request) {
    try {
        List<Map<String, Object>> categoriesInfo =
                Arrays.stream(Category.values())
                        .map(this::createCategoryOverview)
                        .collect(Collectors.toList());

        String jsonContent =
                objectMapper.writeValueAsString(
                        Map.of(
                                "totalCategories",
                                Category.values().length,
                                "categories",
                                categoriesInfo,
                                "description",
                                "Complete catalog of product categories with their descriptions and key characteristics",
                                "lastUpdated",
                                Instant.now().toString()));

        return new McpSchema.ReadResourceResult(
                List.of(
                        new McpSchema.TextResourceContents(
                                request.uri(), "application/json", jsonContent)));
    } catch (Exception e) {
        log.error("Failed to get all categories resource", e);
        throw new RuntimeException("Failed to retrieve categories overview", e);
    }
}

2.3: Expose Your Workflows with Prompts

Prompts are structured guides that teach the AI how to perform complex, multi-step tasks. They are like pre-designed prompt templates that you can invoke, combining instructions, data from Resources, and Tools.

Imagine you want a guide for analyzing inventory. You could create a Prompt named inventory-analysis that instructs the AI to first fetch low-stock products (using a Tool) and then generate a report.

public List<McpServerFeatures.SyncPromptSpecification> getPromptSpecifications() {
    return List.of(
            ...

            // Inventory analysis prompt
            new McpServerFeatures.SyncPromptSpecification(
                    new McpSchema.Prompt(
                            "inventory-analysis",
                            "Inventory Analysis and Recommendations",
                            List.of(
                                    new McpSchema.PromptArgument(
                                            "analysisType",
                                            "Type of analysis (stock-health/reorder/turnover)",
                                            true),
                                    new McpSchema.PromptArgument(
                                            "category", "Focus on specific category", false))),
                    this::createInventoryAnalysisPrompt),

            ...
            );
}

private McpSchema.GetPromptResult createInventoryAnalysisPrompt(
        McpSyncServerExchange exchange, McpSchema.GetPromptRequest request) {
    try {
        String analysisType = (String) request.arguments().get("analysisType");
        String category = (String) request.arguments().getOrDefault("category", "ALL");

        String promptText = createInventoryAnalysisPromptText(analysisType, category);

        McpSchema.PromptMessage promptMessage =
                new McpSchema.PromptMessage(
                        McpSchema.Role.ASSISTANT, new McpSchema.TextContent(promptText));

        return new McpSchema.GetPromptResult(
                "Inventory analysis guidance for " + analysisType + " analysis",
                List.of(promptMessage));
    } catch (Exception e) {
        log.error("Failed to create inventory analysis prompt", e);
        throw new RuntimeException("Failed to generate inventory analysis prompt", e);
    }
}

private String createInventoryAnalysisPromptText(String analysisType, String category) {
    return switch (analysisType) {
        case "stock-health" -> """
            You are an inventory management specialist conducting a stock health analysis%s.

            ## Stock Health Analysis Framework

            ### Key Metrics to Evaluate:
            1. **Out of Stock Items** - Immediate attention required
            2. **Low Stock Warnings** - Items below minimum levels
            3. **Overstock Situations** - Items with excessive inventory
            4. **Stock Turnover Rates** - How quickly inventory moves
            5. **Dead Stock** - Items with no recent sales

            ### Analysis Process:
            1. Retrieve current inventory levels using available tools
            2. Compare against minimum stock thresholds
            3. Identify critical alerts requiring immediate action
            4. Calculate stock health scores by category
            5. Generate actionable recommendations

            ### Recommended Actions:
            - **Critical**: Immediate reorders for out-of-stock items
            - **Warning**: Schedule reorders for low-stock items
            - **Optimization**: Review slow-moving inventory for discounts
            - **Planning**: Adjust minimum stock levels based on trends

            Please conduct a comprehensive stock health analysis and provide prioritized recommendations.
            """
                .formatted(category.equals("ALL") ? "" : " for " + category + " category");

        case "reorder" -> """
            You are a procurement specialist developing reorder recommendations%s.

            ## Reorder Analysis Framework

            ### Reorder Triggers:
            1. Current stock ≤ minimum stock level
            2. Projected stockouts based on demand trends
            3. Lead time considerations
            4. Economic order quantities
            5. Seasonal demand adjustments

            ### Analysis Steps:
            1. Identify products below reorder points
            2. Calculate optimal order quantities
            3. Consider supplier minimums and volume discounts
            4. Factor in lead times and safety stock
            5. Prioritize based on sales velocity and margin

            ### Reorder Recommendations:
            - High priority: Fast-moving items near stockout
            - Medium priority: Steady sellers below minimum
            - Low priority: Slow movers with adequate runway

            Please generate a prioritized reorder plan with specific quantities and timing.
            """
                .formatted(category.equals("ALL") ? "" : " for " + category + " category");

        case "turnover" -> """
            You are a financial analyst evaluating inventory turnover performance%s.

            ## Inventory Turnover Analysis

            ### Key Calculations:
            1. **Turnover Ratio** = Cost of Goods Sold / Average Inventory Value
            2. **Days Sales Inventory** = 365 / Turnover Ratio
            3. **Stock Velocity** = Units Sold / Average Units in Stock
            4. **Carrying Cost Impact** = Average Inventory × Carrying Cost Rate

            ### Performance Benchmarks:
            - Electronics: 8-12 turns/year (Fast-moving technology)
            - Books: 3-5 turns/year (Diverse demand patterns)
            - Clothing: 4-6 turns/year (Seasonal collections)
            - General: 6-8 turns/year (Standard retail)

            ### Analysis Focus:
            1. Compare actual vs. target turnover rates
            2. Identify slow-moving inventory
            3. Calculate carrying cost implications
            4. Recommend optimization strategies

            Please analyze turnover performance and suggest improvements for capital efficiency.
            """
                .formatted(category.equals("ALL") ? "" : " for " + category + " category");

        default -> "Please specify analysis type: stock-health, reorder, or turnover.";
    };
}

Step 3: Configure the Beans to Expose Everything

Once you have all the pieces, exposing Tools, Resources, and Prompts is as simple as creating Spring Beans for them.

@SpringBootApplication
public class ProductCatalogSpringApplication {

    public static void main(String[] args) {
        SpringApplication.run(ProductCatalogSpringApplication.class, args);
    }

    @Bean
    public ToolCallbackProvider productCatalogTools(ProductService productService) {
        return MethodToolCallbackProvider.builder().toolObjects(productService).build();
    }

    @Bean
    public List<McpServerFeatures.SyncResourceSpecification> productCatalogResources() {
        List<McpServerFeatures.SyncResourceSpecification> productCatalogResources =
                new ArrayList<>();
        ...
        return productCatalogResources;
    }

    @Bean
    public List<McpServerFeatures.SyncPromptSpecification> productCatalogPrompts(
            ProductManagementPromptProvider productManagementPromptProvider) {
        return productManagementPromptProvider.getPromptSpecifications();
    }
}

With these simple steps, you've built a direct and secure bridge between your business logic and the world of AI.

Conclusion: The Next Natural Step for Your APIs

As we've seen, adding an MCP Server to your Spring Boot application isn't a Herculean task. It's the next logical step in the evolution of our services. Spring AI abstracts away all the complexity, allowing us to reuse the code we already have to open our applications to a universe of new possibilities with artificial intelligence.

Designing with AI in mind from the start is no longer an option—it's a competitive advantage.

What's Next? Your Turn to Act 🚀

I hope this post has inspired you to look at your APIs from a new perspective. Here are a few ideas to get you started:

Explore the source code: All the code from this example is available in my Product Catalog API GitHub repository. Clone it, run it with Docker, and experiment for yourself. The best way to learn is by doing!
Start small: You don't need a complex architecture. Pick a key method from one of your current Spring Boot applications and try exposing it as a @Tool. You'll see how simple it is.
Join the conversation: What do you think of this approach to AI-native APIs? What other use cases can you think of for an MCP Server in your projects?
Dive into the documentation: If you want to learn all the details, the official Spring AI documentation is the best place to keep learning.

Transform Project Management with Git and AI: backlog.md

David (ダビッド ) — Wed, 27 Aug 2025 09:51:20 +0000

Original post

In modern software development, project management usually lives separately from the code itself. Tools like JIRA, Asana, Monday, ClickUp, or Trello are the industry standard for managing tasks. However, this practice, while powerful, creates a disconnect from where the magic really happens: the code repository. It often forces developers to lose focus by context-switching.

What if you could stay focused and manage the entire project—tasks, documentation, and decisions—directly from the command line, using Markdown files and a Git-native approach?

Today, we're going to explore a tool that does just that. 🚀

Backlog.md: Git-Native Project Management

Backlog.md is an innovative command-line interface (CLI) tool that transforms any Git repository into a self-contained project board. Its approach is simple yet revolutionary: it uses Markdown files to manage everything, allowing project administration to live directly inside your code, versioned and accessible to anyone with access to the repository.

Principles and Architecture

Built with Bun and TypeScript, backlog.md is a zero-configuration npm package. All tasks, drafts, documents, and decisions are stored as Markdown files with YAML metadata in a backlog/ directory. This means every change to the project is a Git commit.

.
└── backlog
    ├── archive
    │   ├── drafts
    │   └── tasks
    ├── completed
    ├── config.yml
    ├── decisions
    ├── docs
    ├── drafts
    └── tasks

Its CLI, based on Commander.js, offers an intuitive set of commands for the entire project lifecycle, from backlog task create to backlog board view.

$ backlog --help
Usage: backlog [options] [command]

Backlog.md - Project management CLI

Options:
  -v, --version           display version number
  -h, --help              display help for command

Commands:
  init [options] [projectName]   initialize backlog project in the current repository
  task|tasks [options] [taskId]
  draft [options] [taskId]
  board [options]           display tasks in a Kanban board
  doc
  decision
  agents [options]          manage agent instruction files
  config
  cleanup                   move completed tasks to completed folder based on age
  browser [options]         open browser interface for task management (press Ctrl+C or Cmd+C to stop)
  overview                  display project statistics and metrics
  help [command]            display help for command

Key Features That Make a Difference

Hierarchical Task Management: Tasks are organized with a clear numbering system (e.g., task-42, task-42.1), facilitating parent-child relationships and the breakdown of complex problems.

$ backlog task create "Parent Test task" -d "This is the parent test task description" -l "test" --ac "ac1,ac2,ac3"
Created task task-1
File: /home/kratos/Development/the-dave-stack/social/backlog.md/backlog/tasks/task-1 - Parent-Test-task.md
$ backlog task create "Child Test task" -d "This is the child test task description" -l "test" --ac "ac1,ac2,ac3" -p "task-1"
Created task task-1.1
File: /home/kratos/Development/the-dave-stack/social/backlog.md/backlog/tasks/task-1.1 - Child-Test-task.md
$ tree -L 3 .
.
└── backlog
    ├── archive
    │   ├── drafts
    │   └── tasks
    ├── completed
    ├── config.yml
    ├── decisions
    ├── docs
    ├── drafts
    └── tasks
        ├── task-1.1 - Child-Test-task.md
        └── task-1 - Parent-Test-task.md

Focus on Outcomes: One of its best ideas is the distinction between Acceptance Criteria (the what must be achieved, in a measurable way) and Implementation Plans (the how it will be technically solved). This brings immense clarity to the process.

---
id: task-1
title: Parent Test task
status: To Do
assignee: []
created_date: '2025-08-23 14:20'
labels:
  - test
dependencies: []
---

## Description

This is the parent test task description

## Acceptance Criteria
- [ ] ac1
- [ ] ac2
- [ ] ac3

Designed for AI: backlog.md treats AI agents as first-class citizens. It provides structured plain-text outputs and even instruction files (AGENTS.md) to guide language models, preparing them for true collaboration.
Deep Git Integration: Every operation is an atomic and descriptive commit. Its ability to synchronize tasks between different branches is simply brilliant, intelligently resolving conflicts.
Web Interface: Although it's a CLI-first tool, it also features a React web interface that includes interactive Kanban boards, complementing the terminal experience.

Taking Backlog.md to the Next Level with AI: `mcp-backlog-md`

The AI-oriented design of backlog.md solves a major initial problem: it presents project information in a structured way. Thanks to this, an AI agent can easily understand the status of tasks. However, this doesn't solve the next challenge: how do we give that AI the ability to execute actions safely and in a standardized way? Historically, every tool that wanted to connect with an AI needed a unique, custom connector, resulting in a fragile and costly-to-maintain ecosystem of integrations.

To solve this, the Model Context Protocol (MCP) was born—an open standard aiming to be the "USB-C of AI." Just as USB-C unified peripheral connections, MCP standardizes how LLMs connect to external tools and data sources.

Instead of forcing the AI to parse CLI output, an MCP server offers it a catalog of capabilities (tools, resources, and prompts) that it understands natively. It's the difference between having to "read a manual" and plugging in a device that "just works."

This is exactly what I've built with mcp-backlog-md: an MCP server that exposes the functionalities of backlog.md as a set of native tools for AI. This eliminates the fragility of text parsing and adopts a robust, standard protocol, enabling much deeper and more reliable collaboration.

Full Integration via MCP Tools

My implementation exposes the entire functionality of backlog.md through a set of MCP tools, allowing an AI agent to:

Manage tasks: createTask, editTask, viewTask, listTasks.
Work with drafts and documents: createDraft, promoteDraft, createDoc.
Check the project status: exportBoard.
And much more...

Most importantly, mcp-backlog-md offers full feature parity with the original CLI, ensuring that the AI has the same power and flexibility as a human user.

Conclusion

In a world dominated by complex project management platforms that are often disconnected from our workflow, backlog.md emerges as a refreshing and powerful alternative. Its "Git-native" philosophy gives control back to the developer, integrating task management directly where the code is born. It offers an agile and transparent solution for teams and professionals who value simplicity and efficiency over overwhelming features.

And for those who, in addition to this simplicity, want to explore the frontier of AI collaboration, the ecosystem is ready. My project, mcp-backlog-md, acts as that precise connector, allowing an AI agent to safely integrate into this system to assist with management.

Thus, backlog.md is not only an excellent tool in itself but also a solid foundation on which to build advanced, AI-assisted workflows.

Want to try it out?

I invite you to explore both projects. You can find the original tool in its repository and my MCP server implementation in mine.

Backlog.md Repository: https://github.com/MrLesk/Backlog.md
My MCP Server mcp-backlog-md: https://github.com/The-Dave-Stack/mcp-backlog-md

I'd love to hear your thoughts in the comments! Do you think this "Git-native" approach has a future? What tasks would you delegate to an AI agent in your projects?

To learn more about the Model Context Protocol

If you want to dive deeper into the technology I've implemented in the server, this video offers an excellent explanation of MCP:

The Model Context Protocol (MCP) - YouTube

You can also find more information on how to use this protocol in my dedicated article about it.

Model Context Protocol Exposed: The Power of Resources and Prompts Beyond Tools

I Tested the 3 Major Terminal AI Agents—And This Is My Winner

David (ダビッド ) — Wed, 20 Aug 2025 11:22:51 +0000

In the world of software development, we're in a constant race to optimize our workflows. AI tools like GitHub Copilot were game-changers inside the editor, but the new frontier—the one that truly promises a quantum leap in productivity—is the terminal.

My motivation for diving into this ecosystem is clear: I want to boost my productivity as a developer. I see these tools as a "small army of junior developers" at my disposal, capable of handling repetitive tasks or generating boilerplate so I can focus on architecture, business logic, and complex problems.

With that mission in mind, I put the three major contenders of the moment to the test: Anthropic's Claude Code, the model-agnostic OpenCode, and Google's official Gemini CLI.

Getting Started: A Surprisingly Smooth Beginning

First things first: getting started with any of these three tools is incredibly simple. I used npm to install them, but they all offer other methods that get you up and running in your terminal in minutes. There's no fuss and no barrier to entry, which is always appreciated.

A Deep Dive: My Experience with Each Agent

This is where things get interesting, and the differences become night and day.

1. Claude Code: The Agent with "Magic" Under the Hood

I have to say it outright: of the three, Claude Code was the only one that truly amazed me. I don't know what magic they've baked into it, but it performs spectacularly well for virtually any task I've thrown at it.

Its greatest superpower is its workflow: first, it plans, then it acts. Having tested visual coding assistants—especially my favorite, Cline—I was quite skeptical about agents in the terminal, but this one completely blew me away right from the start.

Just as with Cline, which I covered in a previous post, instead of blindly starting to write code, Claude Code gives you the option to review a detailed plan. I strongly recommend you use this feature for any significant task. It outlines the steps it will take, the files it will create or modify, and the commands it will execute. You can discuss this plan, adjust it, and once you agree, give it the green light to get to work. This ability to collaborate on the strategy is, simply put, the best I've seen in a tool of this kind.

I've used it to create projects from scratch, giving it all the necessary context, and the experience has been fantastic. Obviously, you still need to review its work, but I consider that a normal and necessary step with any current AI. Furthermore, its integration with the Model Context Protocol (MCP) servers I use is flawless.

Of course, not all that glitters is gold. Claude Code works wonders, but one of the trade-offs is being tied to Anthropic's models. That said, it's not a huge downside, as their models are exceptional for coding.

Finally, if you're as thrilled with Claude Code as I am, here are a few links to help you enjoy it even more.

The classic "Awesome" repository with interesting resources.
- Awesome Claude Code
Several courses for more in-depth details on Claude Code.
- Claude Code: A Highly Agentic Coding Assistant
- Claude Code in Action

2. OpenCode: The Swiss Army Knife of Flexibility

If I had to pick a runner-up, it would be OpenCode. Its main advantage is one that no other contender has: it's model-agnostic.

This is its winning ticket. With OpenCode, you aren't tied to a single provider. You can use models from Anthropic, Google, OpenAI, or connect to OpenRouter for access to dozens of options. This versatility is a massive point in its favor, especially if you need to adapt to different projects and budgets.

I haven't used this agent extensively because its most notable weakness is its integration with MCP servers. For me, these are quite important as I use them heavily to enrich the working context. In my tests, this integration failed frequently and needs significant improvement.

3. Gemini CLI: The Power of a Giant Context Window

In the last place of my personal ranking is Gemini CLI. Although it never gave me a "wow" moment that left me speechless, it has an undeniable technical advantage: it uses Google's Gemini models, which offer the largest context window on the market (though that might change soon: https://www.anthropic.com/news/1m-context).

This is tremendously useful for tasks that require understanding a large amount of code or documentation. You can feed it entire codebases and trust that it will grasp the interconnections. It's a very strong selling point.

Unfortunately, like OpenCode, I found that its integration with MCP servers has a long way to go.

The Final Verdict: My Choice as a Developer

After several weeks of intensive testing, my final choice has a clear order:

First Place: Claude Code.
Second Place (Tie): OpenCode and Gemini CLI.

Right now, Claude Code is in a league of its own. Its ability to plan, collaborate, and reliably execute complex tasks makes it the ultimate AI assistant for the terminal. It's the leader of my "army of junior devs."

OpenCode and Gemini CLI are very capable tools, but for different reasons. OpenCode's flexibility is its biggest draw, while Gemini's massive context window gives it a unique edge for certain types of tasks. Both are excellent, but they need to polish their integrations to compete head-to-head with the user experience that Claude offers.

My final recommendation is:

If you're looking for the most powerful and polished tool on the market and don't mind being within a proprietary ecosystem, go for Claude Code without hesitation.
If you value freedom, control, and the ability to switch AI models based on your needs, OpenCode is your best ally.
If you work with very large projects and need the largest possible context window, or simply want a powerful entry point into the world of terminal agents, Gemini CLI is a fantastic option.

The AI revolution in the terminal is here, and it's here to stay.

What about you? Have you tried these agents? Which one is your favorite, or is there one you think I missed? Let me know in the comments or find me on social media!

P.S. A New Contender on the Radar: Cursor CLI

Cursor – Overview

The world of AI tools moves at breakneck speed. Just as I was finishing this post, I came across another project that deserves a special mention: Cursor CLI.

For those unfamiliar, Cursor is a very popular "AI-first" code editor, and this is its command-line version. The promise is very appealing: the ability to use all the intelligence and context of your codebase that the editor already has, but directly from the terminal.

Looking at its documentation, I was particularly struck by its cursor --edit command, which allows for "agentic" edits on files—something along the lines of what I loved so much about Claude Code.

I haven't tested it thoroughly yet, but I'm adding it to my to-do list. It definitely seems like a competitor to watch in this space.

Have you tried it? I'd love to hear your thoughts in the comments.

March 2025 AI Roundup: What Top Labs Published Last Month

David (ダビッド ) — Mon, 07 Apr 2025 19:25:16 +0000

Hey Community!

If you’re trying to keep up with everything the major AI labs are doing — but don’t have hours to dig through blog posts and papers — I’ve got you covered.

In my latest post on The Dave Stack, I curated a March 2025 roundup of the most relevant updates from top AI research labs including:

OpenAI – Latest insights and model updates
Anthropic – Research on alignment and Claude’s evolution
DeepMind – New papers and applied AI use cases
Mistral – Open-source activity and big releases
Other key players pushing the boundaries of LLMs and agents

It’s a fast way to catch up and stay sharp in a rapidly moving field.

Read the full post here:
March 2025 AI Roundup – The Dave Stack

Let me know if I missed something great from March — I’d love to include it in April’s edition.

Exploring GPT-4o's Latest Enhancements

David (ダビッド ) — Wed, 02 Apr 2025 12:35:01 +0000

🚀 Exploring GPT-4o's Latest Enhancements

OpenAI's GPT-4o has recently received a significant update, rolled out on March 27, 2025, bringing major improvements to its capabilities:

✅ Smarter instruction adherence

✅ Cleaner and more efficient coding assistance

✅ More natural and concise communication

✅ Native image generation capabilities

✅ And now ranked #2 in the Chatbot Arena LLM Leaderboard!

These enhancements make GPT-4o an even more powerful tool for developers, creators, and AI enthusiasts.

I’ve written an in-depth analysis of these updates and what they mean for the future of AI interaction on my tech blog The Dave Stack:

👉 Read the full article here

I’d love to hear your thoughts! Have you tried the new GPT-4o experience? What improvements have you noticed?

The Nx Dev Tool for Monorepos

David (ダビッド ) — Fri, 21 Aug 2020 14:45:33 +0000

Original Post

In JavaScript world, we already know the battles to be the most popular framework or library in the community. There are lots of these creating awesome sites to attract developers for its documentation and usability, showing how easy is to create an application using them, etc.

Over time, some of these frameworks / libraries achieved this popularity but not alone and instead of talking about only frameworks or libraries, we started to listen the JavaScript Stacks.

These JavaScript Stacks are just a selection of some of those popular frameworks / libraries to build the different parts of an application. The popular known stacks are:

As you can see, all of these stacks are nearly the same but the frontend framework, and all of them are also valid to build whatever web application you want.

Enterprises are adopting this JavaScript Stacks to build its web applications even its backend as well. Due to their amount of applications and/or libraries, they have necessities not to only solve what JavaScript Stack to choose, they want to know how to organize the code, architecture patterns to build a scalable application and share components or libraries between their applications as well. In this case, the Nx Dev Tools it is the evolution of this JavaScript Stacks to choose.

The Nx Dev Tools

Nx Dev Tools, as its website says, is a set of extensible dev tools for monorepos, which helps you develop like Google, Facebook, and Microsoft and was created in Nrwl.io, founded by two ex-Googlers, Victor Savkin & Jeff Cross.

In the current version, Nx workspace has different options to build projects with the following stacks:

Frameworks to build FRONTEND applications
Framework to build BACKEND applications
- NestJS
- Nextjs
- Express

In the current version there is no support for Vue.js but you can find some comments talking about its support here.

As you can see, Nx Dev Tools is an awesome resource thought to help developers and enterprises to build whatever they want.

Nx Dev Tools - Resources

Besides its core features, Nx Dev Tools also has a CLI that helps you setup, develop, build, and maintain applications and more and more Plugins, build by their own or by the community, that contain schematics and builders to extend a Nx workspace.

How to Start

At this stage, you should want to know how to start using it, shouldn't it? To start, you can check the above links or if you want to get to work, then you can check its Angular tutorial in the following link:

Tutorial: Step 1: Create Application

Angular and NestJS are my prefered options to build applications 🤓

Conclusion

If you are thinking to start a big, medium or small project, I recommend you to take a look its Getting Started Page to see how this tool can help you to organize your entire project.

In next posts I will show you examples using this Nx Dev Tools 🙂.

DEV Community: David (ダビッド )

The Four Engineerings of AI

The ladder: prompt → context → harness → loop

Arize: "agents don't fail because of prompts, they fail because of context"

Factory: the multi-agent architecture that actually ships software

Where my plugin fits

The honest divergence: serial vs parallel

The line I don't cross

Why the convergence matters to me

finally { }: and still, someone has to read the code

Nx vs. Turborepo: Integrated Ecosystem or High-Speed Task Runner? The Key Decision for Your Monorepo

Introduction: The Monorepo "Problem"

The Fundamental Question: What Are You Buying?

🚀 Option A: Turborepo (The F1 Engine)

✅ The Good: The Speed Argument

⛔ The Critique: Speed Without Direction

🛠️ Option B: Nx (The Construction Kit)

✅ The Good: The Architecture Argument

⛔ The Critique: The Price of an Opinion

Quick Comparison: Nx vs. Turborepo

The Verdict: What Should You Choose?

➡️ You should choose Turborepo if...

➡️ You should choose Nx if...

Conclusion (The Dave Stack's Take)

DeepSeek Does It Again: From MoE to DSA, The New Era of LLM Efficiency

Introduction: The Invisible Wall of LLMs

The Core Problem: The Tyranny of Quadratic Complexity ($O(L^2)$)

The Solution: DeepSeek Sparse Attention (DSA)

The Results: Radical Efficiency Without Sacrificing Performance

What This Means for the Future

Your Website Speaks to Humans, But Does AI Understand It? A Deep Dive into the Dual Web Strategy

The Diagnosis: Why AI Gets Lost on Your Website

The Proposed Solution: "Dual Web"

This Isn't Theory, It's Happening Now: The Market is Moving

A Critical Look: It's Not That Simple

Conclusion: The Next Step in Digital Evolution

PostgreSQL 18 Uncovered: Asynchronous I/O, UUIDv7, and Pain-Free Upgrades

The Key New Features in PostgreSQL 18

🚀 The Headliner: Asynchronous I/O (AIO) for a Massive Performance Boost

😌 Upgrades Are Finally Pain-Free

💻 Developer Gems You'll Love

🛡️ Authentication, Security, and Important Changes to Note

My Critical Perspective: What This Means for Your Projects

🛠️ Hands-On: Test PostgreSQL 18 with Docker and Examples

Requirements

Step 1: Set Up the Comparison Environment

Step 2: Run the Examples and Compare

Example 1: The new uuidv7()

Example 2: Virtual Generated Columns

Example 3: RETURNING with OLD and NEW Values

Step 3: Experimenting with Asynchronous I/O (AIO)

1. Prepare a Large Dataset

2. Run the Tests and Compare

3. Analyze the Results

Step 4: The Definitive Authentication Comparison

Conclusion

Source and Further Reading

Don't Miss the Java 25 Launch Livestream Today!

Full Livestream Schedule (UTC)

What About You?

Designing APIs for the AI Era with Spring AI and MCP

The Dual API Paradigm: REST for Machines, MCP for AI 🤖

What is the Model Context Protocol?

From @RestController to MCP Server

Step 0: Build Your Traditional Spring Boot Service

Step 1: Configuration is a Breeze

Step 2: Implementing the MCP Features

2.1: Expose Your Services as Tools

2.2: Expose Live Data with Resources

2.3: Expose Your Workflows with Prompts

Step 3: Configure the Beans to Expose Everything

Conclusion: The Next Natural Step for Your APIs

What's Next? Your Turn to Act 🚀

Further Reading

Transform Project Management with Git and AI: backlog.md

Backlog.md: Git-Native Project Management

Principles and Architecture

Key Features That Make a Difference

Taking Backlog.md to the Next Level with AI: mcp-backlog-md

Full Integration via MCP Tools

`finally { }`: and still, someone has to read the code

Example 1: The new `uuidv7()`

Example 3: `RETURNING` with `OLD` and `NEW` Values

Taking Backlog.md to the Next Level with AI: `mcp-backlog-md`