Project start in AIDA means teams form, and an AI-driven application gets kicked off from a company case. The official output is a project description and a system sketch, and we handed in neither. Instead, my teammate and I talked through what an MVP would need and let a “grill me” session turn that talk into a spec. Not my most formal deliverable, but an honest one.
The part of that spec I’ve thought about most is the stuff that isn’t in it.
The case#
The company runs a Christmas market on its estate every year, the first weekend of December. Roughly 6,000-8,000 guests over two days and about 110 stalls. The market itself runs fine. It’s everything before it that hurts:
invitation → PDF application → reminders → collecting missing info → review → stand plan → approval → price → invoice
In practice that means PDF forms people can’t fill in, phone calls to talk them through it, an estimated 1,000 emails, a stand plan built by hand, and invoices created manually in e-conomic. Lots of manual work, lots of room for errors, and a lot riding on one person’s head.
Why the market#
The transcript had plenty of other candidates: weddings, a CRM, conferences, inventory, the website. I picked the market for three reasons.
It’s the most manual process, and the most error-prone one. It also doesn’t need the personal touch that weddings do. Wedding customers spend a lot of money and bring a lot of emotion, and that’s not where I want an automated email. And it’s contained. Trello works reasonably well for running the event and touches many external systems, so replacing it would drag me into half the company. The market’s needs are much smaller: a form, a database, and email.
Saying “no personal touch” isn’t quite right, though. The personal touch stays where it matters. More on that below.
The first spec#
I gave the AI the transcript summary, told it everything I’d noticed, and we refined from there. It’s the same lesson as in my spec-driven development post: leave gaps and the AI fills them with assumptions, and they’re not always the ones you had in mind. My plan was always SMTP for email. The spec came back with a replaceable email provider interface instead. Fine, arguably better, but not what I meant.
The spec has a public application form with no login, mobile friendly, and an administrator interface behind it. A few decisions I care about:
- Every application is a snapshot. If a stallholder changes their phone number next year, last year’s application still shows what was submitted.
- Accepting is not the same as placing. An application can be accepted without having a stand, and one accepted application can get several stand spots (double stands exist).
- Every email has a history. Sent, failed, retried. Nothing disappears silently.
- Prices are optional. Pricing stays in e-conomic. The system can store a manually entered price, but nothing depends on it.
The first slice is deliberately thin: an applicant submits the form, the system validates and stores it, and a confirmation email goes out. It touches every layer, but it’s small. It’s also my first real foray into agentic development, so I wanted to start somewhere I could see what the agent was actually doing, and where a mistake wouldn’t be a spectacular one.
What I left out on purpose#
The out-of-scope list is long, and the item that really mattered was automatic placement.
The AI would happily have done it. It’s fast, it sounds practical, and it would look great in a demo. But the stand plan lives mostly in the head of Lise, who runs the market. Three stallholders selling Christmas decorations? Are they all angels and baubles, or do they complement each other? Two selling alcohol? Beer and gin are not the same thing. That context is exactly what an automated placement would lose.
I’ll admit this isn’t a strict case of Naur’s theory building, which is about programmers’ understanding of a program. But the point carries over: the knowledge is in a person’s head, not in a document I can hand to an agent. A spec can hold a rule. It can’t hold Lise’s judgement.
And Lise is clear that she decides where you stand. Convincing her to trust an algorithm over her own eye would be a lot of work for very little value.
So the system helps without deciding. It shows an applicant’s preferences next to the placement controls, and it warns when similar product categories end up close to each other. That’s a reminder, not a verdict, and Lise can overrule it. It will misfire sometimes, because categories are crude. That’s fine for a reminder. It wouldn’t be fine for a decision.
Same logic for the rest of the list: no automatic acceptance or rejection, no direct e-conomic integration, no Trello replacement. Acceptance, rejection and assignment emails only go out when an administrator explicitly triggers them.
Spring Boot, and who owns what#
The spec says Spring Boot, and that was my decision, not the AI’s. Partly because AI models have been trained on far more Spring Boot code, so I expect better results. Partly because I’ll be working in Spring Boot soon, and when the project is done I want to read the code and see how it’s written. I know the domain and how the design was reasoned out, which gives me an anchor.
The trade-off is obvious: I won’t “own” the code the way I would if I had typed every line. I will own the decisions, and it’s my job to understand what’s happening before this goes anywhere near production.
What worries me#
Not the agent, actually. Two things:
- Scope creep. The out-of-scope list is my main defence, and I’m the one who has to keep respecting it.
- Building something nobody wants. The application has to work for stallholders who aren’t tech-savvy and for Lise, who will use it every day. A neat design that isn’t what they wanted is still a failure. That’s why the form needs no login and works on a phone, and why the stand plan stays in her hands.
I’ll find out soon enough whether I got it right.