DEV Community: DynoKore

We're building an invoicing system with AI agents, in public

DynoKore — Sat, 24 Oct 2026 04:25:35 +0000

DynoInvoice is an e-invoicing and GST compliance platform for Singapore, and AI coding agents are writing it. Its source is now on GitHub at github.com/dynokore/DynoInvoice. The mirror syncs every hour, so you can watch the agents' commits land while they work. Development is ongoing, and incomplete features are expected.

The source is published for study only. It's licensed under PolyForm Strict 1.0.0, which allows reading and running it for non-commercial purposes, and nothing else. We don't accept contributions. It isn't open source in the OSI sense, and we don't call it that.

What DynoInvoice is

Singapore is moving GST invoicing onto InvoiceNow, the national e-invoicing network built on Peppol. GST-registered businesses will have to send their invoice data to IRAS through it, using an InvoiceNow-Ready solution and an accredited Access Point.

DynoInvoice sits beside the systems a business already runs (ERP, billing, point of sale, expenses) rather than replacing them. It handles what the InvoiceNow requirement asks of a GST-registered business:

deciding which transactions are in scope, and mapping internal tax codes to IRAS GST categories;
building and validating the invoice data IRAS requires, and working out when each submission is due;
submitting it to IRAS through an accredited Access Point, and handling resubmissions and credit notes;
keeping the evidence, and reconciling what was submitted against what was filed in the GST return.

Accounting firms and tax agents can act for their clients, with each client's consent for each entity. It runs as a multi-tenant service or as a single-tenant private deployment, from the same code. It doesn't run its own Access Point, prepare GST returns, or replace accounts receivable and payable.

The foundations are in place: organisation structure, access control (including acting on a client's behalf) and the shared contracts between services. Document handling, submission and reconciliation are still being built.

Why we're building it

The requirement already applies to new voluntary GST registrations, and IRAS has set dates to bring in most other GST-registered businesses in phases through April 2031, so most businesses will need something between their existing systems and the network.

We're building DynoInvoice for two reasons. It's a product we intend to bring to market when it's ready. And it's the hardest test we could find for DynoKore Keel. Invoicing has tenants that must never see each other's data, rules that come from regulation rather than taste, and an audit trail someone will eventually ask for. If agents can build that under governance, the method should hold for less demanding software.

How it's designed

DynoInvoice is designed the way a regulated, multi-tenant system has to be. The diagram shows the design; dashed parts aren't built yet.

Solid boxes have code on main and are still in progress; dashed boxes are designed but not built yet.

One domain per service, one schema per service. Each service owns its own database schema and can't read another's tables. Services talk through contracts published from one place and checked automatically: a few synchronous APIs where the caller needs an answer, and events everywhere else, delivered at least once to consumers that must handle repeats.
Tenant isolation in the database. Every table carries the tenant, and isolation is enforced by the database rather than by application filters. A private deployment runs the same multi-tenant code with a single tenant.
Submissions keep flowing. Tokens are checked offline at the gateway, and evidence, reconciliation and notifications consume events without holding up the pipeline.
Evidence you can verify. Receipts, decisions and audit logs go to an append-only store kept apart from operational data, with integrity checks.
Rules as signed data. Tax rules are versioned data in signed rule packs, so the same date and input give the same result. The control plane that signs them runs only at the operator, never receives tenant data, and isn't needed at run time: a private deployment can run fully offline, without new rule packs until it reconnects or loads one.

How the agents are governed

The agents work under DynoKore Keel, which we built for ourselves first.

One chain, end to end. Requirements, acceptance criteria and tasks are versioned records in Keel, and every change traces back to them. Before a coding agent starts, the server checks the task's requirement and design readiness and lists each missing item; a task that fails stays blocked.

The author doesn't grade its own work. By rule, the agent that drafts a requirement or decision change submits it, and a separate examiner agent approves and publishes it. Every merge request must pass the repository's automated gates and an independent reviewer agent's check against the project's written engineering standards, including any change to tests (documentation-only changes run text checks only).

Done is decided by the server, not the coder. Tests must prove acceptance criteria held in Keel. The coding agent can't change those criteria, and a rule forbids weakening a check to get green. A coding task is marked done by the server from the merged change and its CI verdict, not by an agent, and a change to a task's acceptance criteria sends it back for review.

People answer the questions that matter. Questions about functionality, direction, exemptions or relaxing a check are answered by a person, and the answer is recorded in Keel with who decided. Loosening a check is never an agent's call. When an agent reaches one of these questions, that task waits and the agents carry on with other work; once the person answers, it picks up again. Most other approvals are made by agents under a delegation from that person, and the record shows which is which.

Credentials stay out of the agents' reach. A hook blocks agents from reading credential files; tools read credentials in their own process and never print them. Before every sync, the published history is scanned for credentials and internal identifiers, and any finding stops the sync.

What went wrong

Agents fail in ways that look like success. A few things we caught, and what we changed:

Green, but not done. A coding agent reported a task complete with a green pipeline. It had pushed only scripts and fixtures; the main change was never committed. Coding agents are now required to have a clean working tree, with a diff covering every file the task names, before reporting done, and independent review checks the diff against the task.
A looser reading to get through. An agent decided on its own that part of a requirement didn't apply, which made the task easy to pass. It was sent back. A coding agent that hits a gap is instructed to stop and report it; it may not pick a looser reading of the task.
A test that passed on review day. A test hard-coded a moment in time while the SQL used the database clock. It was green when reviewed, then turned main red a couple of days later and blocked every merge request. Review now looks for time literals, and time-sensitive tests run with both the application and database clocks shifted.
A scan that saw nothing. A licence scan with no findings was cited as evidence, but it had scanned the source tree and never saw the built artifacts. Before a green scan counts as evidence, we check that it actually saw what it claims to cover.
A quotation nobody wrote. An agent drafting a decision included a quotation that didn't exist in its source. The independent examiner caught it before publication. Quotations must now be exact and cite the version they come from.
Agents waiting on each other. One agent was allowed to dispatch another. When every slot was full, each waited on a slot the other held. Agents no longer dispatch other agents; the coordinator does, and a script caps how many run at once.

What's next

We're building a public view of the record, where you'll be able to pick a commit and follow it back to its task, requirement and review.

DynoInvoice is still being built. If you want to ask how the agents built something, the repository's Discussions are open.

We're also opening Keel to a small group of design partners: engineering teams already using coding agents who need to answer to an auditor, a client or a regulator. Apply at dynokore.ai.

If you find something to criticise in the code, that's the point. Tell us.

Originally published at dynokore.com. Written by the DynoKore team with AI assistance.

From vibe coding to governed development

DynoKore — Fri, 23 Oct 2026 20:08:05 +0000

In 1957, John Backus and his team at IBM presented a paper called The FORTRAN Automatic Coding System. The promise was in the name: you would describe the computation, and the machine would do the programming. It didn't end programming. It created far more of it — because the people writing FORTRAN no longer had to think in registers.

Every step up the ladder has looked like that. Machine code gave way to assembly, assembly to high-level languages. Each step let people write less about how and more about what. And each step moved the source of truth up a level: once compilers could be trusted, nobody maintained the assembly. They maintained the source.

Coding agents are the next step. What you hand an agent is, at bottom, a requirement: what the system should do. So it's tempting to conclude that programming is becoming natural language, and that the code is turning into an intermediate artefact nobody reads.

We think the direction is right. The conclusion is premature, and the reason why matters.

An agent is not a compiler

A compiler translates a formal language deterministically, and it preserves meaning. Compile the same source a hundred times and you get the same behaviour. That guarantee is why we stopped reading assembly.

An agent translates natural language probabilistically, and nothing guarantees it preserves meaning. Natural language is ambiguous to begin with. Give the same request twice and you can get two different programs, both of which pass their own tests.

In the late 1970s, Dijkstra wrote a short note called On the foolishness of "natural language programming". His point was that the value of a formal notation is its precision. He was right. And that's the problem teams are now living with.

What's breaking

We went through about 7,000 Hacker News comments from the past year about working with coding agents, with agents doing the first pass, and kept the 178 in which an engineer described something that actually went wrong for them. The most common complaints:

Code that works today and nobody can change tomorrow. Logic duplicated at the wrong layer, the repo's design ignored, a feature another team had to rewrite before it fit. This was the single most frequent theme.
Review that can't keep up. Agents produce more than people can read, and review turns into a bottleneck or a rubber stamp.
Someone else's AI output landing on you. Large generated changes from colleagues, which you're expected to review, fix or own.
Losing your grip on your own codebase. You merged it, but you no longer hold a mental model of it.
"It passes" isn't "it does what was asked." The code compiles, the tests are green, and it solves a slightly different problem.

None of these is fixed by better prompts. They're what happens when the source of truth moves up a level but nothing guarantees the translation.

Requirements become the source code

If requirements are where intent now lives, they need everything source code has needed for fifty years:

Versioning. Every change to a requirement is a recorded revision, not an edit to a chat history.
Review. A change to what the system should do is checked before anyone builds on it.
Tests. Each requirement carries acceptance criteria precise enough to check, not adjectives.
Traceability. Every line of code can answer: which requirement am I for?

That isn't "write a long spec, then generate". Heavy specs have their own failure mode. One engineer in our sample described a thirty-minute fix that turned into a 37-page AI planning document and a week of process. Governance is not more paperwork. It's making intent precise, keeping it in one place, and checking every output against it.

How we do it

We built DynoKore Keel around three ideas.

One source of truth. Requirements, acceptance criteria, tasks and decisions are versioned records in Keel, and every change traces back to them. Changes to requirements go through an independent examiner agent before they're published. When a question needs a person — how a feature should behave, whether an exemption is acceptable, whether a check may be relaxed — the answer is recorded, with who decided.

Controlled execution. Coding agents work under the project's written engineering standards; for example, library modules may only depend downward, enforced by architecture checks in CI. They can't change the acceptance criteria their tests must prove, and a rule forbids weakening a check to get green. A separate reviewer agent checks every merge request, test changes included. The agent that wrote the code never reviews it.

Verifiable outcomes. A task can't be marked done until its requirement chain exists and passes Keel's readiness check, and no code change merges until the automated checks pass. Routine approvals are delegated to agents, and the record shows which decisions a person made.

Notice what isn't in that list: a person reading every line. We couldn't, and neither can you. The work is in making that safe.

What we got wrong

We learned the hard way that a sentence in a prompt is not a control. We told our agents never to print credentials. Three times, a credential fragment still ended up in an agent's output. The fix wasn't a better prompt. It was mechanism: tools that need credentials read them in their own process and never print them, and a hook now blocks reading credential files at all.

That lesson generalises. In a governed system, a mistake that happens twice gets a mechanism, not a reminder.

And we should be honest about scope. DynoInvoice, the system we've built this way, is weeks old, not years. We can show you how it's structured and how every change was checked. We can't yet show you what it looks like after five years of maintenance. Nobody can, for agent-built systems. That's exactly why the structure matters now.

Where this goes

Will code eventually disappear from view, the way assembly did? Maybe, but only once checking an agent's output becomes as trustworthy as a compiler. Until then, the job isn't to stop engineering. It's to move engineering up a level, to the requirements, and keep the checks underneath honest.

If your team is already shipping agent-written code into a system you'll maintain for years, three things you can start tomorrow:

Write down what "done" means before the agent starts, in terms a test can check.
Never let the agent that wrote a change be the one that approves it.
When a mistake happens twice, replace the reminder with a mechanism.

Vibe coding is a fine way to build a prototype. A system you'll run for years needs something else: governed development.

Every requirement. Every decision. Every proof.

We're opening Keel to a small group of design partners: engineering teams already building with agents who need to answer for what they ship. dynokore.ai

When a colleague's AI-generated pull request lands on you

DynoKore — Fri, 23 Oct 2026 20:05:27 +0000

When a colleague uses an agent to write a large change and asks you to review it, the cost of that change moves to you. Engineers describe huge pull requests, intent that doesn't match the business, and authors who can't explain their own code. Stricter review alone doesn't fix it; the review needs something fixed to check against, and a limit on what can be submitted.

What we found

We went through about 7,000 Hacker News comments from the past year about working with coding agents, and kept 178 in which an engineer described something that actually went wrong for them. In 23 of those, the problem wasn't their own agent. It was AI-generated work from someone else (a teammate, a contractor, a manager or an open-source contributor) that they were expected to review, fix or take over. We rated 6 of those 23 as high severity, more than any other theme in the sample.

The same patterns came up again and again:

Size. Pull requests of thousands of lines, every day. One engineer spent hours on a single 3,800-line shell-script change from a contractor who couldn't answer basic questions about the system. (source)
The wrong problem, solved confidently. Teammates fed half-finished code to a model and sent back versions that got the business requirements wrong. (source)
Work that doesn't fit. A feature from another team had to be stripped down and redesigned for more than a week before it fit the main API. The engineer who did the fixing was the one who looked slow. (source)
Proof that isn't proof. Scripts that print what the author expects to happen, instead of demonstrating that it does. (source)
Debt merged under deadline. A lead let contractors' fast AI code through to hit a budget, and is still cleaning it up. (source)

Open-source maintainers described the same thing at larger scale: a flood of generated pull requests acting like a denial-of-service attack on their attention. (source)

What people tried

Most responses fell into three groups:

Review harder. Raise the bar, reject "AI slop", read every line. It works until the volume grows, and it makes the strict reviewer unpopular.
Restrict who can use agents. New hires limited to planning mode until they understand the codebase. Some engineers stopped using agents altogether.
Remove the source. One lead let the contractors go.

Each of these puts the whole load on the reviewer's judgement, at the end of the process, after the work is done. None of them changes what arrives for review.

What actually helps

The common thread in these stories is that the reviewer has nothing fixed to check against. They have a diff and a description, both written by the same person (or the same agent), and they have to work out what the change was supposed to do before they can decide whether it does it. These are the changes that help, whatever tools you use:

No pull request without a stated requirement. Before work starts, write down what the change is for and how you'll know it works, precisely enough that a test can check it. The reviewer then checks the change against that, not against a guess.
The author can't move the target. If the acceptance criteria live somewhere the author (or their agent) can't edit, nobody can make a change pass by quietly redefining "done".
Proof means running checks. A test that exercises the behaviour, in CI. Not a script that prints a success message, and not the author's say-so.
Cap the size. A change too big to review isn't reviewed, whoever or whatever wrote it. Split it, or send it back.
The same gate for everyone. Human-written, agent-written, contractor or senior engineer: one set of checks. Then the argument stops being about who used AI, and becomes about whether the change does what was asked.

How we handle it

At DynoKore most of our code is written by agents, so "someone else's AI output" is our normal day. We built DynoKore Keel so that what arrives for review is already anchored. Requirements, acceptance criteria and tasks are versioned records, and every change traces back to them. Tests must prove those acceptance criteria, and the coding agent can't change them. An independent reviewer agent checks every merge request, including any change to tests. A task can't be marked done until its requirement chain exists and passes Keel's readiness check.

We're a small team, and our "colleagues" are mostly agents. We haven't yet seen how this holds up across a large organisation with many human authors. That's what our design partners are for.

The short version

If AI-generated work keeps landing on you, the fix isn't reading harder. Agree what "done" means before the work starts, keep that definition out of the author's reach, and send back anything that doesn't prove it.

This is part of What Breaks, our series on what actually goes wrong when teams build with coding agents. If this matches what you're seeing, or doesn't, tell us at hello@dynokore.com. We're opening DynoKore Keel to a small group of design partners: dynokore.ai.