jtWMS

What it is

jtWMS is a warehouse management system: the software that knows what’s in a building, where it is, and what has to happen to it next. It covers the core of a real warehouse operation:

• Inbound. Purchase orders, advance ship notices, receiving and putaway.
• Inventory. Stock positions, a movement ledger, license plates, holds and allocation.
• Outbound. Orders, waves, picking, packing and shipping.
• Routing. Conveyor routing, divert decisions, ship sortation and dock assignment.
• Resolution. One place for every exception: short picks, damaged stock, mismatched counts.

It is multi-tenant from the start and API-first. Everything the web app does goes through the same public API, and there is a webhook service so other systems can react to warehouse events.

Why build it

Warehouse software is a good stress test for AI-assisted development. It isn’t glamorous, the domain rules are strict, and mistakes show up as missing stock rather than as a slightly wrong UI. If agents can build this well, they can build most business software.

How AI was used

Almost all of the code was written by AI agents. A person owns the product direction, the priorities and the final say on architecture. The agents do the rest:

• Planning. Epics are broken into small, independently shippable stories.
• Implementation. An agent picks up a story, writes the code and tests, and opens a pull request.
• Review. Other agents review the PR for correctness and conventions before a person looks at it.
• Documentation. Architecture notes, API conventions and a user guide are kept in the repository and updated with the code, because they are also the agents’ context.

The repository ended up with over 2,000 commits in its first seven months.

Architecture, briefly

The system is split into about a dozen ASP.NET Core services: identity, catalog, inventory, inbound, outbound, routing, resolution, webhooks and a simulator, behind a single API gateway. Services share one PostgreSQL schema with tenant isolation enforced by global query filters, and talk to each other through domain events on RabbitMQ. The web front end is a React single-page app, and there is a separate documentation portal for users and API consumers.

The simulator service deserves a mention. It drives realistic warehouse flows against the public API, which gives the agents a way to check their work against something closer to real use than unit tests.

What worked

• Written conventions compound. Every documented convention, from API shape to EF Core migrations to messaging, removed a class of mistakes from future sessions.
• Small services suit agents. A bounded service with clear contracts fits in an agent’s context. Changes rarely spill into places the agent didn’t read.
• Tests as the contract. Contract tests between services caught breaking changes that a human reviewer would have missed.

What didn’t

• CI can hurt production. Running heavy CI on the same hardware as production once took the production machine down with it. CI now runs on separate hardware with resource limits.
• Generated code has quirks. Tooling-generated files, such as database migrations, don’t always match the formatter’s expectations. Small hooks that fix them automatically saved a lot of failed builds.