Development on David Parry

🖥️ You Don't Need a Frontier Model. You Need a Spec.

Fri, 14 Aug 2026 15:00:00 -0500

You do not need a frontier model to build professional software. You need a spec, a test bar, and a workflow that will not let anyone — human or model — skip either. Frontier models are what you reach for when you want day-zero results: something that compiles this afternoon and looks finished until you have to live with it. A responsible solution is slower in the screenshot and faster over the life of the system. The surprise of the last year, for me, is that this path is now cheap enough to run on a laptop.

I already wrote that spec-first was always right, and that agents finally made it fast . That post was the argument. This one is what I learned once I stopped treating the hosted model as the product and started treating a local model as one tool inside a spec-driven loop. The working proof is the bdd CLI that grew out of that workshop — one native binary, Ollama by default, no cloud calls, no token meter.

The CLI is the discipline, compiled

The workshop needed an MCP server so an agent could not wander. The CLI is that same loop as a program you run yourself. The command manual is the full surface; the idea is one sentence:

The requirements spec is the source of truth, and the discipline is enforced by tooling, not by convention.

Everything else follows from that. The spec is machine-validated (bdd spec validate) and its wording is quality-gated (bdd spec refine) before any scenario or line of production code exists. A valid-but-vague requirement is caught and reworded first. Behavior flows downhill from the approved spec: Gherkin scenarios tagged with requirement ids, step definitions, unit tests, and only then production code. The Red/Green/Refactor cycle is a state machine, not a suggestion — start_refactor is refused on a red bar, and a requirement is only marked implemented behind a green one.

Agents get no escape hatches. No arbitrary file writes, no shell, no “just install this for me.” Every mutation goes through a typed, validated tool, lands in staging (.bdd-staged/), and waits for a human to review it. The same tools serve a person at a prompt and an agent over MCP. The LLM is local, discovered rather than assumed, and generation falls back to deterministic templates when Ollama is down or empty. Nothing is ever installed for you.

Run bare bdd and you get the loop, the version, and whatever local model is already on the machine:

$ bdd

  ╭──────────────────────────────────╮
  │                                  ▼
  │    > bdd  v0.2.4                 │
  │    spec → RED → GREEN → REFACTOR │
  ▲                                  │
  ╰──────────────────────────────────╯

Model set for this session: qwen3-coder-next:q4_K_M (not saved - keep it with: bdd model use qwen3-coder-next:q4_K_M).
bdd>

From an empty directory, bdd greenfield runs the whole creation order with exactly two human gates: the wording of the driving spec, and the review of generated tests before they are committed. From an existing project, you drive the same phases yourself — spec draft, spec validate, spec refine, test, implement, refactor — and bdd status names the one next step that actually moves the loop forward.

The model is not sitting above this process. It is boxed inside a few commands: drafting a requirement from plain words, polishing step definitions and unit tests, attempting an implementation against a recorded RED bar. test, state, and refactor never call it. That is not a prompt instruction. It is the architecture.

What I actually learned about local models

The lesson is not “an 8B model beats Opus.” The lesson is: once you move the deterministic work out of the model, a local model becomes enough.

I measured a version of that claim in Skills vs MCP . For one workload, putting the business rules in code instead of in the model’s head cut hosted cost by 32% on Claude Opus 4.8 and 76% on GPT-5. The same implementation on qwen3:30b, served locally through Ollama on an Apple M4 Max, cost nothing and dropped mean latency from 43.4 seconds (instruction-only Skill) and 54.4 seconds (prompt only) to 10.8 seconds with the tool. There is no per-token invoice to blame on that last comparison. Generating fewer tokens still consumed less wall-clock time on my hardware.

The CLI takes that architecture and applies it to the development loop itself. Spec validation is code. Wording critique is code. The TDD state machine is code. Gherkin parsing is code. Test execution is Maven, cucumber-js, dotnet test, or cargo test — the project’s own runner, not a model’s impression of a runner. The model is asked to propose, not to be the system of record. When it proposes a step definition, the CLI prefers that output only if it validates; otherwise the deterministic template ships. That is why qwen3-coder-next:q4_K_M is a reasonable default on this tool, and why qwen3:30b is a luxury rather than a requirement.

Open-weight coding models have also closed enough of the raw-capability gap that this is no longer a thought experiment. Alibaba’s Qwen3-Coder reports state-of-the-art results among open models on SWE-Bench Verified without test-time scaling, and describes the 480B variant as comparable to Claude Sonnet 4 on agentic coding. You can argue with any one leaderboard. You cannot argue with the direction: the model you can run next to the repo is no longer a toy, and the remaining gap is exactly where unconstrained agent loops still fall down — long-horizon, multi-file, “figure out what I meant” work. Spec-driven development is how you stop asking the model to do that work.

METR’s early-2025 randomized trial is the other data point I keep coming back to. Experienced open-source developers working on their own mature repositories, using frontier tools of the day (primarily Cursor with Claude), took 19% longer when AI was allowed. They expected a 24% speedup. After living through the slowdown, they still believed they had been sped up by 20%. Perception and the clock disagreed. METR was careful about what that does not prove. They said, explicitly, that they do not provide evidence “there are not ways of using existing AI systems more effectively” — scaffolding, prompting, repository-specific context. Their later 2026 follow-up ran into a different problem: too many developers now refuse to work without AI, so the experiment can no longer see the tasks where people expect the biggest lift. I read both results the same way. Unconstrained generation on a real codebase is not the same activity as a gated spec-to-green loop. The first can feel fast and still be slow. The second is slower to start and cheaper to finish, and it does not require the most expensive model on the market.

Day-zero is a product. Professional software is a process.

I will say this as cleanly as I can. Frontier models are extraordinary at day-zero. You describe a thing, files appear, a demo boots, a screenshot looks like a product. That is a real capability, and it is the capability the labs demo, because it is the capability that converts. If what you wanted was a prototype before lunch, pay for the tokens. I do that too.

Professional software is a different shape. Someone has to write down what “done” means in a form that can be checked. Tests have to fail for the right reason before they pass for the right reason. The code has to be the simplest thing that makes that true, and then it has to be reviewed. Edge cases have to be found on purpose, not stumbled into in production. That work has been preached at us for as long as I have been doing this — test-first, behavior-first, requirements-first. Cucumber and Gherkin were the first tools that let the requirement itself become executable, and I never went back. What changed is not the advice. What changed is that an agent will now execute the advice if you put it in a tool instead of a slide.

GitClear’s 2025 look at 211 million changed lines — Google, Microsoft, Meta, and enterprise C-corps, 2020 through 2024 — is what day-zero looks like when it becomes the default. Lines associated with refactoring fell from 25% of changed code in 2021 to less than 10% in 2024. Copy/pasted lines rose from 8.3% to 12.3% in the same window, and 2024 was the first year in their dataset where copy/paste exceeded moved (refactored) code. Assistants do beget more lines. Senior developers, asked what would unlock their team, do not answer “more lines.” They answer reuse, tests, and the courage to change old code. Those are the habits a day-zero loop does not practice, because they do not show up in the demo.

GitHub putting a name and a toolkit on this — Spec Kit , “define what to build before building it” — is the industry catching up to a sentence some of us have been repeating for twenty years. I am glad it exists. Specs that live as markdown for an agent to interpret are still a step up from a vibe. They are not the same as a spec that is structurally validated, wording-gated, and tied to a real Cucumber suite and a TDD state machine that will refuse to refactor on red. That difference is why bdd exists. The closest tools I know of each do part of this. None of them combine a machine-validated spec, a wording gate, real Cucumber across Java, JavaScript/TypeScript, .NET, and Rust, an enforced test-state machine, typed mutations with no shell escape hatch, an embedded MCP server, and a local-only LLM, in one binary.

It does not behoove them to teach you this

I want to be as careful here as I was in the token-bill post. This is an incentive, not a conspiracy. Model providers have good reasons to make models more capable, and customers are free to buy that capability. Still, the bill is not subtle. On the two hosted models I priced, output tokens cost five to eight times input tokens. When a model does more work, customers usually buy more inference.

It does not behoove a frontier lab to teach you a workflow in which an 8B local model drafts a requirement, a validator rejects the sloppy wording, a test runner produces a red bar, and the model is only then allowed to attempt the smallest patch that turns it green. That workflow spends its calories in code you already own. It does not spend them on a metered API. The labs need the habit: open the chat, describe a feeling, accept a tree of files, come back when it breaks. Addiction is an ugly word for a pricing model, but the loop is the same shape. You stay because the first screenshot was free in time and expensive in everything that came after.

I do not think the models are the enemy. I think the missing guidance is the enemy, and the missing guidance is the same guidance we have had since before any of this: write the spec, write the test, write the code last, keep all three in sync. Frontier models do not ship with that. A CLI can.

The rehire articles are a symptom. They are not the point.

I have seen the articles, and the videos, about companies hiring people back after betting that AI would replace them. Some of that reporting is looser than it sounds. The number that is actually sourced is not “developers,” and I am not going to pretend it is.

Gartner’s February 2026 forecast is about customer service. By 2027, they say, 50% of companies that attributed headcount reduction to AI will rehire staff to perform similar functions, under different job titles. Their own October 2025 survey of 321 customer service and support leaders found that only 20% had actually reduced agent staffing because of AI. Kathy Ross, a Gartner analyst on that practice, said most recent workforce reductions were influenced by broader economic conditions rather than automation alone. Emily Potosky, in the same release: “AI simply isn’t mature enough to fully replace the expertise, empathy, and judgment that human agents provide.”

Klarna is the case everyone uses, and it is also customer service. In May 2025, CEO Sebastian Siemiatkowski told Bloomberg that cost had been too predominant a factor, and that what you end up with is lower quality. He started recruiting so customers could always speak to a person. That is not “AI failed, delete the chatbot.” It is “we over-indexed on the demo, and the demo was not the job.”

IBM is moving the other direction on purpose. CHRO Nickle LaMoreaux said the company plans to triple US entry-level hiring in 2026 , across software and the rest of the business, because “if we don’t continue to invest in entry-level hires, what happens in 3–5 years? There’s no pipeline; the well simply dries up.” That is not a rehire of the old org chart. It is an admission that if you delete the bottom of the profession, you do not get a more efficient profession. You get a cliff.

The engineering version of this story is not a Gartner headcount number I can cite. It is the GitClear chart: more lines, less reuse, more churn, code that is written to be shipped today and expensive to touch tomorrow. Companies that staffed for day-zero generation and starved the people who can tell a spec from a vibe will hire some of those people back. Of course they will.

If anyone who knows me is watching that wave, I hope what comes back is only the 30%. I hope the 70% are now out of the equation. I am going to leave the 70–20–9–1 split to another post. Trust me, it will offend a lot of people. It is not meant to. It is about priorities, and about other aspects of life, and about whether filling a seat was ever the right use of someone’s years. If this era does one decent thing, it will be to stop asking the 70% to occupy a spot they were never going to love, and to let them go explore the rest of a life. That is only possible if the 20% take the AI and use it for good — not to manufacture day-zero code, and not to skip the techniques that have been taught for as long as I have been doing this. The 20% have to keep the spec, the tests, and the code in sync. Nobody else is going to do that for them. The frontier model will not. It is not in its interest.

Try it on the machine you already have

Clone the repo , or install bdd from the latest release . Install Ollama if you do not have it, pull something small, and point the CLI at it:

ollama pull qwen3-coder-next:q4_K_M
bdd model use qwen3-coder-next:q4_K_M
mkdir calculator && cd calculator
bdd greenfield

Describe a calculator in a sentence. Watch a local model split that sentence into a requirement. Watch validate_spec and refine_requirement refuse the sloppy wording. Approve the spec when it is actually the behavior you want. Watch the bar go RED, then GREEN. You will not have called a frontier API. You will have practiced the same discipline I have been arguing for for twenty years, at the speed an agent can finally sustain.

To learn more about Spec-Driven Development — the workshop, the CLI, the talk, and how the loop actually runs — start at davidparry.github.io/tdd-bdd-agentic .

That is the whole claim. Frontier models are optional. The spec is not. Day-zero is a screenshot. Software is what is still true after the screenshot.

🔺 Spec-First Was Always Right — Agents Just Made It Fast

Fri, 07 Aug 2026 16:00:00 -0500

For twenty years I have argued that requirements, tests, and code are the same information at three altitudes, and that the job is to keep them in sync. The argument has not changed — the economics finally have. The correct way was always to nail the spec first, but that was the slower way, and when a human sits down at a keyboard there has always been an unspoken rule that whatever they type had better be code. Spec-writing looked like stalling. So teams typed the code, and the spec — if it ever existed — drifted into fiction. That trade-off is now dead. With an agent doing the transformation from requirement to test to implementation, the spec-first path is no longer the slow path. Getting it right is now faster than winging it, because a well-captured requirement is the thing an agent can actually execute against, and a vague one is the thing you pay for in review, rework, and slop.

I recently decided to polish my TDD talk, TDD in the Agentic Era, with exactly this in mind. The talk always rested on having the spec; the revision makes the spec mandatory. The workflow now begins at the requirement and refuses to move without one — the agent cannot write a test or a line of implementation until it has pulled the spec and turned its acceptance criteria into an executable scenario. In the 60-minute hands-on version, every artifact is real, runnable code — an MCP server, a client agent, a requirements backlog, Gherkin scenarios, and a Red/Green/Refactor state machine that refuses to let anyone, human or AI, refactor on a red bar. It is public in the tdd-bdd-agentic repository , and I use it through this post as the working proof of the argument. But the workshop is the demonstration, not the point. The point is that my old conviction is holding true, and the time to do this — and get it right — is now: why this style finally pays for itself, and why this exact idea, spec-driven development as a triangle, is the reason I joined CodiumAI. I chose them for Itamar’s vision — a vision that was not completely deliverable at the time, given where the models were, but was spot on about where this was all going. That company is the one you now know as Qodo.

What we accomplish in the hour

Everyone has watched an agent demo. Almost nobody has driven the workflow underneath one. That is the gap the workshop closes — and deliberately not by building plumbing. The MCP server and client come completed in the repo (Java, stdio transport, tested to 100% coverage); MCP gets about seven minutes as the standard way to feed your tools into whatever agent you use — Cursor, Claude Desktop, or the bundled CLI client, which narrates the handshake, discovery, and invocation that every IDE does under the hood. The rest of the hour, with 35 of the 60 minutes at your keyboard instead of looking at mine, every attendee:

Drafts and refines a requirement with an agent. You describe the intent in a sentence; the agent writes the requirement into the backlog; and then the spec iterates through two server feedback loops. First structure: validate_spec reports every issue — a criterion missing its Then, a duplicate id, broken JSON — and the agent fixes and re-validates until the spec is valid. Then wording: refine_requirement critiques the draft — “‘quickly’ is ambiguous,” “the story is missing its why,” “only happy paths, add an edge case” — and the LLM rewords against that deterministic feedback until the critique comes back clean. The agent drafts, the server arbitrates, the human approves the final wording.
Drives the full spec-to-green loop. A real LLM agent validates the spec, picks up a pending requirement through the seven workflow tools (list_requirements, get_requirement, validate_spec, refine_requirement, run_tests, get_tdd_state, start_refactor), writes the Gherkin scenario for its acceptance criteria, runs the tests to show RED, implements the simplest code to reach GREEN, and then — only then — refactors.

The kata under all of this is deliberately boring: the String Calculator. The point was never the calculator. The point is the workflow wrapped around it.

Three altitudes, one discipline

The center of the talk is a slide I call the three altitudes. It is not “just TDD.” It composes the three spec-first methodologies, each pinning the system at a different height, and the agent works across all of them:

Methodology	Pins	Canonical artifact
SDD (spec-driven)	the feature	a versioned spec with acceptance criteria — in the repo, `requirements/requirements.json`
BDD (behavior-driven)	one behavior	a Gherkin scenario, executed by Cucumber
TDD (test-driven)	one unit	a failing JUnit test

The flow is spec-down. The agent reads a requirement (SDD), turns its acceptance criteria into a tagged Gherkin scenario (BDD), adds unit tests where useful (TDD), and the run_tests tool runs Cucumber and JUnit together — one bar, one color. Tests are generated from the spec, not reverse-engineered from the code afterward. That direction is the entire spec-driven claim.

Here is what the agent actually produces during the spec-to-green exercise, for a requirement whose acceptance criteria were already phrased Given/When/Then in the spec:

  @REQ-003
  Scenario: Two numbers separated by a comma are summed
    Given a string calculator
    When I add "1,2"
    Then the result is 3

And here is the prompt the audience pastes into their agent — notice how much of it is workflow, not code:

Using the tdd-workflow tools: validate the spec first, then find the next pending requirement, add a Gherkin scenario for its acceptance criteria to the feature file (tag it with the requirement id), reuse or add step definitions, run the tests to show RED, then implement the simplest code to reach GREEN, then refactor. Ask me before each phase change.

There are two hard human checkpoints in the loop. The first is a spec review: when the agent writes the scenario, the room stops and reads it aloud — is this the behavior we want? The second is diff approval after GREEN. The agent turns the crank; the human steers. And the discipline is not a suggestion living in a prompt — it lives in the tool. Ask the server to start_refactor while the bar is red and it refuses. Guardrails belong in code, not in vibes.

Twenty years a convert

I have been a convert to this style for twenty years. Test-first, behavior-first, and above all requirements-first — the conviction that you cannot build the right thing until someone has written down, in a form that can be checked, what the right thing is. I lived through the era when the spec was a Word document that was obsolete before the first sprint ended. Cucumber and Gherkin were the first tools that let the requirement itself become executable, and I never went back.

But I should be honest: being a convert and getting to practice it were two different things. The conviction was mostly private, because in most places I worked the requirement either did not exist at all or arrived from someone outside engineering — a product owner, a stakeholder, a business analyst — who was never equipped to turn what they wanted into a technical requirement or a PRD an engineer could build against. What came across was rarely close. That was not their failing. They knew the business cold; they simply were not trained to interrogate a request the way it needs to be interrogated — to dig for the edge cases and the unstated assumptions, to ask the questions that actually need asking, and to pin the answers down in a form that can be checked. So I spent twenty years believing in requirements-first while working in organizations that rarely produced a requirement worth the name.

Which is the whole point, because it tells you where the scarce skill always lived. It was never typing the code. It was extracting what is actually needed — from the ticket, from the stakeholder, from the silence between what they said and what they meant — and pinning it down in a testable form. That is why the agentic era feels like vindication rather than disruption to me. An agent is a phenomenal crank-turner, but it can only turn the crank on requirements someone captured well — and if that skill was scarce when a human wrote the code, it is scarcer and more valuable now that an agent will faithfully execute whatever you hand it, good spec or bad. Which leads me to believe the developer’s real emerging role is requirements gatherer for the agent — but that is another post, and I intend to write it.

The triangle that made me join

In July 2024 I was deciding whether to join a startup called CodiumAI. Plenty of companies were pitching AI code generation; what convinced me was that the CEO, Itamar Friedman , was saying the same thing I had spent twenty years believing — and he had drawn it as a triangle: spec, tests, code, kept in sync. He lays it out most explicitly in his Gen 3.5 framing , where agents collaborate around three core artifacts, Specs → Code → Tests, improving the spec, transforming it into code, generating and executing tests, and keeping all three tightly aligned as each evolves. I was not joining a company that bolted testing onto generation as an afterthought; I was joining one whose founding thesis was that the three corners are the same information at different altitudes and the job of AI is to keep them aligned. When I joined, that vision was ahead of what the models could deliver. Reading it now, with the workshop in this post running exactly that loop on my laptop, we are close — if not already there.

The workshop is the triangle, running

Look back at the workshop with the triangle in mind and the mapping is one-to-one:

Spec corner: requirements.json, versioned, with acceptance criteria — drafted with the agent, held structurally valid by validate_spec and iterated to clean wording by refine_requirement, and the source of truth the agent implements from.
Tests corner: the Gherkin feature file and the JUnit tests, generated from the spec, executed together as one bar.
Code corner: StringCalculator.java, written last, as the simplest thing that makes the bar green.

The MCP server is the connective tissue — the standard way for an agent to discover your workflow tools and respect your discipline. The human sits at the two checkpoints where judgment lives: is this the right spec? and is this the right code? Everything between those checkpoints is crank-turning, and the crank no longer needs to be turned by hand.

Twenty years ago, keeping the three corners in sync was a manual discipline that most teams abandoned under deadline pressure. The spec drifted, the tests decayed, and the code became the only truth — unreadable, unverifiable truth. What the agentic era changes is the cost of the discipline. The alignment work that teams always skipped is exactly the work agents are good at.

The talk ends with homework: on trunk — the exact starting point the class clones — requirements REQ-004 through REQ-006 are still pending, and the requirement the room drafted in Exercise 1 is waiting to be taken to green. Clone the repo , point your agent at the tools, and finish the kata on the plane home. Watch the bar go RED, then GREEN. And if you want the answer key, the complete branch is the kata fully driven through the loop — every requirement implemented, every scenario tagged and green — with CI telling the story on both branches: trunk deliberately fails a class-completeness check because the work is still ahead of you; complete passes everything. Then ask yourself who really wrote the requirement — because that person, not the agent, decided what got built. That’s the next post.

☕ Java at Thirty: Still One of the Strongest Bets in the Enterprise

Sat, 18 Jul 2026 11:00:00 -0500

Three decades after its release, Java is still solving the problems that matter most to enterprise software. That staying power is easy to dismiss as inertia. I don’t think it is. I think it’s the predictable result of a platform that optimized for the things large organizations actually care about — and kept investing in them long after the hype cycle moved on.

Let me be careful about the claim I’m making, though.

The honest version of the claim

I’m not going to tell you Java is the optimal language. That’s an opinion dressed up as a fact, and it falls apart the moment you change the context — Java is not my first reach for a data-science notebook, a systems kernel, or a quick shell script.

Here’s the claim I’ll actually defend: Java remains one of the strongest choices for enterprise software where long-term maintainability, stability, and operational reliability are the dominant concerns. That’s a narrower statement, and it’s a stronger one, because it names the conditions under which it’s true.

For most organizations, success is rarely about using the newest language. It’s about delivering reliable systems, controlling operational risk, hiring engineers at scale, and maintaining software for a decade or more. Judge Java against those goals and its longevity stops looking like nostalgia and starts looking like fit.

Backward compatibility is a feature, not a limitation

The thing developers complain about — Java’s conservatism — is exactly what enterprises are buying.

Code written years ago still compiles and runs. Upgrades are usually boring, and boring is the point. When a platform breaks compatibility casually, every upgrade becomes a migration project, and migration projects are where budgets and timelines go to die. Java’s discipline here means a large codebase can move forward without being rewritten, and that compounds over the lifespan of a system.

Predictable releases you can plan around

Since the six-month release cadence and the Long-Term Support (LTS) model, Java gives organizations something they can actually build a roadmap on. LTS releases give you a stable target with years of support; the interim releases let the language keep evolving without forcing everyone onto the treadmill. You choose your pace. For a business planning multi-year investments, predictability like that is worth more than raw novelty.

The platform is still being invested in

Java isn’t coasting. Recent years have brought genuinely significant work to the platform — virtual threads reshaping how the JVM handles concurrency at scale, ongoing improvements to startup time and memory footprint, pattern matching and records modernizing the language itself, and continued GC advances. This is a thirty-year-old platform still receiving serious, well-funded engineering. That matters when you’re betting a decade of software on it.

A mature ecosystem and a deep talent pool

Two of the most underrated enterprise concerns are “what do I build on?” and “who will maintain it?”

On the first, the JVM ecosystem is vast and battle-tested — Spring and Spring Boot alone cover an enormous surface of what enterprises need, with libraries, tooling, observability, and integration patterns refined over many years of production use.

On the second, the Java talent pool is one of the largest in the industry. You can hire for it, you can staff teams at scale, and you can find engineers who’ve operated Java systems in production for years. That’s not a glamorous advantage, but it’s a decisive one when you’re maintaining critical systems over a long horizon.

Operational reliability is where it earns its keep

None of the above would matter if the runtime fell over under load. It doesn’t. The JVM’s observability, profiling, and tuning story is deep, and the operational patterns for running Java in production are extremely well understood. When something goes wrong at 2 a.m., “well understood” is exactly the property you want.

Where Java isn’t the answer

Being honest about the boundaries is what makes the rest credible. If your problem is a small script, a latency-critical systems component, data science and ML research, or a lean startup optimizing for the fastest possible time-to-first-feature, Java is often not the best tool — and you should reach for something that fits. The claim is about a context, not a coronation.

Why this is on my mind

I spend most of my time now building agentic systems on the JVM, and this is precisely why. The interesting, fast-moving part — the reasoning, the model calls, the orchestration — sits on top of a platform I can trust to still be maintainable, staffable, and operable years from now. New capability on a stable foundation is a good trade. It lets me chase what’s genuinely new without gambling the boring, load-bearing parts of the system.

The takeaway

Thirty years in, Java’s relevance isn’t an accident and it isn’t sentiment. It’s the payoff of a platform that consistently optimized for maintainability, stability, backward compatibility, predictable evolution, a deep ecosystem, and a large talent pool — the exact concerns that dominate enterprise software.

That doesn’t make it the best language for everything. It makes it one of the strongest bets you can place when you need systems to run, and keep running, for a very long time.

🤖 From Prompting to Planning: What Embabel Taught Me About Agents

Thu, 16 Jul 2026 09:00:00 -0500

I first ran into Embabel at DevNexus and have been quietly using it ever since, but it wasn’t until a recent class — going deep with Dashaun — that it really hit home. I spent the last stretch working through an Embabel workshop — building a bounded “digital worker” that responds to production incidents — and it reorganized how I think about agents on the JVM. Most of the agent content I read treats the LLM as the brain: you write a clever prompt, hand the model some tools, and hope it strings them together. Embabel pushes the intelligence somewhere far more boring and far more trustworthy: into Java types, into a planner, and into policy that a compiler and a test suite can see. This post is my attempt to write down what I actually learned, how I’d classify Embabel, and why I’m setting aside my own platform, AgentFabric, and starting to use Embabel instead.

The one-sentence reframe

The line from the workshop that stuck with me was: the worker chooses the path, your code defines the world. That is the whole shift. In a normal service you write a method that calls four collaborators in a fixed order. In Embabel you declare the capabilities and the desired outcome, and a planner discovers the order at runtime from the current state. You stop writing the sequence and start describing the world the sequence lives in.

What Embabel actually is

If I had to classify Embabel in one phrase, I’d call it a neuro-symbolic, planning-first agent framework for the JVM. Let me unpack why, because each word is doing work.

It’s symbolic because the core engine is Goal-Oriented Action Planning (GOAP) — the same technique game AI has used for years. GOAP starts from the goal and reasons about which declared actions, given the current state, can reach it. The planner is deterministic. It is not the LLM. This is the part people miss: Embabel does not ask a model “what should I do next?” It computes the plan from types.

It’s neural because an individual action is free to call a model. The LLM lives inside a step, boxed in by the types around it, not sitting above the whole process pulling levers.

It’s planning-first because the mental model is OODA — Observe, Orient, Decide, Act — running as a loop. After every action produces a result (or fails), the planner re-observes the world and reassesses what is now possible. Failure isn’t an exception to swallow; it’s new information that changes the next plan.

And it’s JVM-native because Spring still owns everything. Embabel is a Kotlin framework with clean Java authoring, and your agent is still an ordinary @Component. Constructor injection, interfaces, mocks, tests, observability — none of it changes. Embabel just adds planning metadata on top of methods you’d have written anyway.

Types are preconditions and effects

Here’s the idea that made it click for me. Consider four action signatures from the incident worker:

ServiceObservation observeServices(IncidentRequest request)

RunbookAssessment applyRunbook(
    IncidentRequest request, ServiceObservation observation)

IncidentResponseReport analyzeIncident(
    IncidentRequest request,
    ServiceObservation observation,
    RunbookAssessment assessment)

IncidentWorkflowReport prepareReport(
    IncidentRequest request,
    ServiceObservation observation,
    RunbookAssessment assessment,
    IncidentResponseReport response)

Nobody writes the orchestration. The parameters are the preconditions and the return type is the effect. An action is applicable only when every parameter type already exists on the blackboard; running it deposits its return type, which unlocks the next action. So the plan isn’t authored — it falls out of the data flow:

IncidentRequest
   └─ observeServices ─→ ServiceObservation
        └─ applyRunbook ─→ RunbookAssessment
             └─ analyzeIncident ─→ IncidentResponseReport
                  └─ prepareReport ─→ IncidentWorkflowReport  (GOAL)

At the start only IncidentRequest exists, so only observeServices can fire. Each result makes exactly one more action eligible. I checked this against the workshop’s tiny planner, and the mechanism really is that literal: it filters methods whose parameter types are all present, picks the lowest-cost one, invokes it, and puts the result back on the blackboard. That’s it.

The blackboard is typed working memory

There’s no JSON router and no stringly-typed state machine. State is a set of domain objects — IncidentRequest, ServiceObservation, RunbookAssessment — that the debugger, the compiler, the tests, the logs, and the planner all see identically. When I’ve built agent-ish things in the past, the “state” was usually a bag of strings passed through prompts, and it was untestable by construction. Making state a typed blackboard means the invariants live in Java, not in prose I’m begging a model to respect.

DICE: context is a domain model, not a prompt

The workshop calls this DICE — Domain-Integrated Context Engineering — and it’s the philosophical core. Instead of stuffing everything into a prompt, you encode organizational knowledge as executable, testable Java first, then hand the model only the facts it needs to reason inside those boundaries.

The clearest example is approval. The runbook, in plain Java, decides whether a proposed production change requires human sign-off:

return switch (request.incidentType()) {
    case OUT_OF_MEMORY -> new RunbookAssessment(
        "Heap pressure is consistent with an OutOfMemory failure.",
        evidence,
        "Capture a heap dump, roll back the latest risky change, "
            + "then validate with a canary.",
        true);   // requiresApproval — always
    case HIGH_LATENCY -> new RunbookAssessment(
        "Database timeouts and cache misses indicate dependency saturation.",
        evidence,
        "Check database and cache health, then use an approved "
            + "rollback or scale-out.",
        true);
};

The model never sees a requiresApproval field it could flip. It can’t. The model’s output type doesn’t contain that field, and the goal step copies the deterministic value straight from the runbook. Policy is the compiler’s job; interpretation is the model’s job. That separation is the whole point.

Where Spring AI comes in

Spring AI is the thing doing the actual model call inside an action, and it’s exactly where I’ve spent most of my own time. The pattern is small and lovely:

return chatClient.prompt().user("""
    You are an SRE following a production runbook.

    Incident: %s
    Metrics: %s
    Logs: %s
    Runbook diagnosis: %s
    Approved strategy: %s

    Return concise analysis, diagnosis, and recommendation.
    Keep the recommendation inside the approved strategy.
    """.formatted(/* domain facts */))
    .call()
    .entity(IncidentResponseReport.class);

.entity(IncidentResponseReport.class) is the part I lean on constantly: the model reasons, but Java owns the schema. The reply comes back as a typed object or the action fails — and because it can fail, the plan needs a way to recover.

Failure is just another node in the graph

This was my favorite lesson, and it’s where planning earns its keep. The model call is the preferred path (low cost). If it throws — Ollama cold, provider down, invalid output — the planner doesn’t retry the same prompt and it doesn’t ask the model to improvise. It re-observes the blackboard, notices the request and runbook assessment are still true, and selects a different declared capability with the same effect type:

@Action(description = "Fall back to deterministic runbook output",
        readOnly = true, cost = 10.0)
public IncidentResponseReport fallBackToRunbook(
        IncidentRequest request, RunbookAssessment assessment) {
    return new IncidentResponseReport(
        "The model was unavailable; deterministic policy was retained.",
        assessment.diagnosis(),
        assessment.recommendedAction());
}

Two actions, same return type. Cost expresses preference (1.0 for the model, 10.0 for the fallback) without a hand-written if/else route. The blackboard makes the fallback applicable only after the preferred path fails. Plan repair, expressed as data rather than control flow. And the whole run explains itself afterward: a PlanExecution record lists completed actions, failed actions, and whether the goal was achieved — an audit trail of decisions and outcomes, not a dump of private chain-of-thought.

Autonomy only means anything inside boundaries

The worker is allowed to observe Compose, apply the runbook, ask the model, fall back, and prepare a report. It is not allowed to invent shell commands, restart production, bypass approval, or run forever. Two guardrails enforce the last one: actions are FIRE_ONCE by default (no silent re-running) and the planner has a hard step limit. A read-only worker that stops at human approval is still autonomous — autonomy is goal-directed selection inside a capability boundary, not unrestricted mutation. That framing alone is worth the price of admission.

Why I’m putting AgentFabric down and picking up Embabel

The reason all of this landed so hard is that I’ve spent a long time building AgentFabric — my own durable JVM agent platform on the Spring AI substrate — and Embabel put a name to the philosophy I’d been reaching for by feel. Having seen it done properly, I’m going to stop investing in AgentFabric and start using Embabel instead.

AgentFabric was my attempt to run agents in production, durably, across service boundaries. It stands on:

Spring AI as the model and tool layer — ChatClient, structured-output binding, and MCP tool calling wired through a ToolCallbackProvider.
LangGraph4j for stateful graph topology — nodes that call the model, routers that branch on conditions, and verification loops that re-prompt until output passes a quality gate.
Temporal for durable execution — every graph run is a workflow, so a crashed agent resumes from the last completed node instead of replaying LLM calls.
A2A and MCP as the wire protocols — agent-to-agent messaging and agent-to-tool calls.
PostgreSQL as the source of truth for configuration, checkpoints, and token accounting.

It works. But being honest with myself, most of that is orchestration plumbing I wrote so I could get to the actual agent — and the hardest, most valuable part, the deliberation, is the part I did worst. In AgentFabric I describe the graph — nodes, edges, routers — as declarative topology, which means I’m still hand-authoring the sequence and then maintaining it forever. Embabel’s whole point is that I shouldn’t be doing that at all: declare capabilities as typed actions and a goal, and the planner derives the topology from data flow. The centerpiece of my platform turns out to be a worse version of something a maintained framework already gives me for free.

What convinced me isn’t that Embabel is different — it’s that everything I got right in AgentFabric, I got right by accidentally reinventing Embabel, badly:

My LangGraph4j state channels are a home-grown blackboard — except in Embabel the presence of a type is what makes the next step applicable, so I stop drawing edges entirely.
My verifier loop plus deterministic fallback is hand-wired plan repair — Embabel does it with a second declared action at a higher cost, selected automatically when the model action fails. No re-prompt path to maintain.
My completeAs(Class<T>) calls are just Embabel’s .entity(...) — both are Spring AI underneath, so this is the one place there’s genuinely nothing to migrate; it’s the same call.
My budget guard router is a clumsier cost-based action preference.
My guarded write tools (dry-run unless apply=true) are the same instinct as keeping requiresApproval in Java, never the model — one thing I’ll happily carry over as a habit rather than a codebase.
Even the durability I reached for Temporal to get is largely native: Embabel’s blackboard persists through a pluggable AgentProcessRepository — in-memory by default, but back it with PostgreSQL or MongoDB and a process survives a restart. And human-in-the-loop pause/resume is built in via awaitables: a process returns WAITING with a processId and you resume it later through /continue. I wrote a Temporal integration to get exactly these two things.

There’s a real cost to admitting this — AgentFabric is a lot of my work — but continuing to maintain a bespoke orchestration engine to avoid adopting a better, supported one is just ego with a build file. Embabel gives me the planner; Spring gives me the beans; Spring AI gives me the model calls I already knew; a persistent repository gives me durable state and pause/resume.

So do I still need Temporal? Almost never. The only case that would pull it back in is when I need guarantees Embabel’s step-level persistence doesn’t offer: deterministic replay with exactly-once activities (the JVM dies mid-LLM-call and must resume without re-invoking the model), durable timers (“wait three days, then continue”), or distributed orchestration across a worker fleet with guaranteed delivery and backoff. For a single-process agent that plans, calls a model, and pauses for human approval — which is most of what I actually build — none of that applies. So AgentFabric goes on the shelf, and my next agent starts as an Embabel @Agent.

And with the recent news that Embabel is heading for a 1.0.0 release, whatever hesitation I had about betting on it is gone. I’m all in.

What I’m taking away

The move Embabel names is the move from calling APIs to building workers. A worker navigates a typed domain, invokes real Spring-managed services, plans from preconditions and effects, stops at an explicit goal, repairs a failed path, preserves human approval, and leaves an audit trail. None of that requires trusting a model with the steering wheel. It requires giving the model a small, well-lit room to think in — and letting typed code define everything outside the door. That’s the bet I’m making by setting my own platform down and building on Embabel instead.

If you’re on the JVM and you’ve been building agents by growing ever-larger prompts, I’d genuinely recommend sitting with GOAP for an afternoon. It reframes the problem from “how do I make the model behave” to “what world am I asking it to operate in” — and the second question is one your compiler can help you answer.

📱 My Mobile Applications

Sun, 19 May 2024 08:00:00 -0500

GitHub Projects

David Widgets an Android Library of UI Widgets

Example Android Project showing how to use the widgets from the DavidWidgets Library

App Store Listings

PlayStore

App Store

📝 Why Choose Hugo for Static Content?

Sat, 18 May 2024 16:00:00 -0500

As a developer, my primary focus is on solving unique and challenging problems that have not yet been addressed. Writing my own static content generation system might seem appealing, but it would consume a significant amount of time and effort that could be better spent on more complex tasks. Hugo is a mature, robust, and well-supported static site generator that allows me to focus on what truly matters: innovating and solving new problems.

Hugo provides a highly efficient and flexible framework for creating static content. It is designed to handle a wide range of scenarios with ease, offering features such as Markdown support, custom templates, and shortcodes. These capabilities allow me to quickly and efficiently generate static content without having to reinvent the wheel. By leveraging Hugo, I can avoid the pitfalls of maintaining a custom-built system and instead rely on a proven solution that is constantly being improved by a large community of developers.

My requirements for static content generation are straightforward and do not warrant the development of a custom system. Hugo excels in delivering exactly what I need with minimal configuration and setup. It enables rapid deployment, supports a variety of content types, and integrates seamlessly with modern development workflows. By choosing Hugo, I ensure that my static content generation process is reliable, maintainable, and future-proof, freeing me to tackle the more complex and unique challenges in my projects.

👨‍💻 Codebase Resurrection: Given at JavaMUG

Tue, 10 Oct 2023 19:00:00 -0500

Welcome to this Java conference session, where we delve into the transformative power of AI in refactoring and improving codebases. If your codebase is in dire need of a revamp and you’re grappling with complex, tangled code, this session is tailored for you. We’ll explore how Codium.AI can serve as your secret weapon, helping you tackle subpar code effectively.

Understanding Code Health:

Analyzing Code Health:

We demonstrated how Codium.AI can assess the current state of your codebase, identifying areas that need improvement. This involves evaluating code complexity, detecting code smells, and highlighting technical debt. Visualizing Code Issues: Codium.AI provides detailed reports and visualizations, making it easier to understand the intricacies of your code and prioritize refactoring efforts.

AI-Powered Testing:

Automated Testing:

We showcased Codium.AI’s capability to generate and run AI-driven tests, ensuring comprehensive coverage and identifying potential bugs before they become issues. Confidence in Refactoring: By leveraging AI-powered testing, developers can refactor code with confidence, knowing that the AI will catch any unintended side effects or bugs introduced during the process. Precision Refactoring:

Expert-Recommended Refactorings:

Codium.AI incorporates best practices from industry experts, suggesting precise refactorings to simplify complex code structures and enhance maintainability. Step-by-Step Guidance: The tool provides step-by-step guidance on applying refactorings, ensuring that developers can implement changes efficiently and accurately. Measuring Success:

Evaluating Impact:

We discussed how to use Codium.AI to measure the impact of refactorings, tracking improvements in code quality, performance, and maintainability. Continuous Improvement: The tool supports continuous monitoring and improvement, helping teams maintain high standards of code quality over time.

Interactive Session:

The session was highly interactive, with over 30 attendees actively participating. Attendees asked insightful questions about the practical application of Codium.AI in various scenarios, and we provided detailed answers and demonstrations.

Case Study:

We shared a real-world example from our team, highlighting how Codium.AI worked like a charm in revitalizing a particularly challenging codebase. The tool’s AI-driven insights and recommendations proved invaluable, making the refactoring process efficient and effective.

Conclusion:

By the end of the session, attendees were equipped with the knowledge and tools to harness the power of Codium.AI, transforming their codebases into efficient, robust, and future-proof systems. The positive feedback and high level of engagement reflected the value and potential of integrating AI into coding practices.

💻 Redefining Error Monitoring: Breaking Free from Brittle Logs

Sat, 18 Mar 2023 16:00:00 -0500

In recent years, the landscape of error monitoring has undergone a significant transformation. Traditional log-based approaches, while invaluable for root cause analysis, have shown their brittleness in the face of evolving software applications. However, the good news is that it’s now easier than ever to break free from the shackles of brittle logs and adopt a more reliable error monitoring strategy. This transformation has been made possible by tools like Micrometer, a powerful metrics collection library, and AWS EventBridge, a versatile event bus, each offering distinct approaches to error monitoring.

Micrometer has emerged as a game-changer in the world of error monitoring by providing developers with a simple and consistent way to emit custom metrics and events from their applications. Spring Boot, a popular framework in the Java ecosystem, has seamlessly integrated with Micrometer, making it incredibly easy for developers to harness its capabilities. By leveraging Micrometer, you can emit distinct error events, separate from your regular logs, that are designed to be stable and reliable. These events serve as beacons, allowing your monitoring and alerting systems to pinpoint critical issues, even as your application evolves.

On the other hand, AWS EventBridge offers an alternative approach to error monitoring. It acts as a centralized event bus that seamlessly connects various AWS services and third-party tools. By emitting error events to EventBridge, you can effortlessly integrate with a wide range of monitoring and alerting tools, such as AWS CloudWatch, Datadog, or even custom applications. This means that not only can you reliably capture errors, but you can also set up sophisticated workflows and responses based on these events. The result is a monitoring ecosystem that’s both robust and flexible, adapting to your specific needs and evolving alongside your application.

In conclusion, the days of relying solely on brittle logs for error monitoring are behind us. Thanks to tools like Micrometer and AWS EventBridge, error monitoring has become more accessible and reliable than ever. Whether you choose the integrated simplicity of Micrometer with Spring Boot or the versatility of AWS EventBridge, you can ensure that your application’s critical issues are detected and acted upon, regardless of how your application evolves. It’s a transformation that empowers developers to build more resilient and responsive software systems while gaining deeper insights into application behavior.