This is the second article in a series that tries to put a number on the value of Plinth's AI-native development workflow for Java. The Part 1 article showed the benchmark results across 4 scenarios:
ScenarioWhat the agent gets
scenario1A minimal README only — baseline, sparsest possible brief
scenario2A full functional-requirements package: user story, Gherkin, OpenAPI, ADRs
scenario3An OpenSp...
[Read More]
What's new in Plinth 0.18.0?
Plinth is an AI-native engineering toolkit for modern Java enterprise SDLC, built around reusable Commands, Agents, Skills, and MCP Servers.
This release focuses on two things. First, Plinth now treats specification as two explicit phases — Functional and Technical — with new commands and skills that turn a raw issue into agreed requirements and an approved design before any code gets written. Seco...
[Read More]
Why Functional and Technical Specifications Matter for AI-Assisted Development
The gap AI agents fall into
When you ask an AI agent to "add rate limiting to the API" and it will produce something. It might even compile, pass a quick test, and look complete in the diff.
But what does "rate limiting" mean here? Per user, per API key, per IP? What happens when the limit is hit — a 429, a queue, a silent drop? Is this a business rule with a specific number att...
[Read More]
Validating hypotheses about Plinth workflow with a Benchmark Part 1
The questions behind the benchmark
During the last months, the project has evolved from a complete Skills folder for Java to provide an AI-native development workflow for Java, more or less this project lives in the Third generation (Systemp prompts -> Skills -> AI-Native development Workflow). During this time, any inquisitive user could ask for evidences about what is the real value using t...
[Read More]