The Trip#
Engestofte Gods is the country estate on Lolland that my partner and I have spent the last two weeks building a system for, the way I described in the last post. We started with a guided tour of the estate. Until then, the case had been a presentation in a classroom and a set of interview notes, so it helped to see the place we are building for.
Then we showed the prototype. It went well, and the feedback was good.
What We Showed#
The system gives each wedding one place, so nothing has to be typed in twice. Around that, we showed:
- Inquiries and free dates. An inquiry comes in, and the staff can see which dates are still free.
- Follow-up reminders, so no inquiry is forgotten. These came straight from the interview.
- Personal contact. Customers can still call or write, because that contact is a big part of why people choose the estate.
- A portal for the couple, where they manage their guests and allergies and make a seating plan drawn from the estate’s real rooms. The seating plan was our own idea.
- A CMS (content management system), where the staff edit the estate’s website themselves.
AI Where It Was Safe#
For a course about AI, there is surprisingly little AI in the product. The only part is translation in the CMS. When the staff change a Danish text, the CMS can suggest English and German versions, and a staff member approves every translation before it goes live. Translation was a known pain point, since the translations on the old site had drifted away from the Danish texts, and with a human approving every one, the risk is small.
We held back on AI that reads the inquiry emails or drafts offers, and we did it on purpose. We never got the chance to pin down exactly what the event manager needed there, and he worried about losing the personal contact. Holding back also fits what I wrote in the first post about deciding how often I call a model and picking the smallest one that does the job.
The Unsaid#
At the start of the project, we had an interview of over an hour with the event manager. My partner and I agree that it is very important to understand the customer’s domain in a project like this, and it is what we focused on.
Even so, when the event manager saw the workflow we had built for him, there were features he would like to work differently, and some he would like added. None of it came up in the interview. I don’t think he held anything back. He knows his workday so well that some of it never gets said, and we didn’t know enough to ask.
This is Naur again. In the Specs post, I wrote that the theory behind a program is the developer’s understanding of how it fits the real world it serves. Before we can build that theory, the customer has to share his own. The course’s page on Naur notes that documentation can’t say everything, and I think the same goes for an interview. Much of what the event manager knows is tacit, and he uses it every day without having to put it into words.
So a big part of the job is stating the unsaid: getting what the customer knows but doesn’t say out into the open, and into the spec. The prototype brought some of it out. When something is in front of him, he can react to it instead of describing his workday from memory.
The grilling in our workflow doesn’t solve this either. The agent can grill me about the plan, but it can only work with what I know, and it can’t grill the event manager.
The Work That Wasn’t Code#
A lot of the work on this project wasn’t code. We interviewed the customer and tried to understand how the business works. We turned a workday into requirements we could actually build. We designed screens that can be used between two phone calls, and we planned the databases and the SEO for the new site.
This is where the education showed its value for me. An AI can write code fast, but it can’t judge whether we are building the right thing.
Conclusion#
On Friday we had our class on MCP, the Model Context Protocol, which is a standard way to connect tools and data to an AI assistant. The next post is about building a small MCP server, and it ends the series with my verdict on the providers we used.
- Daniel