On 7 October, Erhvervsakademi København published a news article about our Engestofte project: Datamatikerstuderende satte AI til at arbejde for gods på Lolland. It describes what my teammate and I built for Engestofte Gods, how we used AI to build it, and what Johan and lecturer Jon Bertelsen think of the result.
It’s a good place to end this series. The article covers most of what I’ve written about here since August, seen from the outside.
What the article describes#
The article starts where Johan’s interview started: a wedding currently lives in several places at once. The inquiry arrives by email, the agreement and invoice are in the accounting system, and the staff tasks are on a Trello board. When something changes, Johan has to remember to update it everywhere.
It then describes the administration system that brings that together, with an overview of inquiries, available dates and customers waiting for a reply. The finance part updates automatically whenever something changes, and there are statistics on all inquiries and events. It also describes the couple’s own page, where they register guests and allergies and build the seating plan. The plan is drawn to the room they’ve chosen, so a table can’t be placed in front of a door, and the couple can set rules for who should or shouldn’t sit together. The kitchen gets an overview of allergies at each table.
The article also points out that the seating plan wasn’t Engestofte’s idea. We suggested it ourselves, because seating plans are often changed many times before a wedding, and today it’s usually Engestofte doing that work. I wrote about that choice in the post about the visit, where Lise asked whether she could see the guests’ allergies and we could already show her.
What Johan said#
The part I read most carefully was Johan’s. He told the school:
“Jeg er dybt imponeret over de foreløbige løsninger og hvor teknisk dygtige, de er.”
I’m deeply impressed by the solutions so far, and by how technically skilled they are.
He also explained why the collaboration matters to a business of their size:
“Vi har hverken tid eller råd til selv at udvikle nye systemer eller AI-løsninger.”
We have neither the time nor the money to develop new systems or AI solutions ourselves.
That connects to something from the interview: it’s hard to find time to develop the business when you’re busy running it. Any system we built had to save Johan time, not give him another place to update.
Asked whether they would use the solutions once they’re finished, he answered: “Så kommer vi helt sikkert til at bruge dem” (then we’ll definitely use them). It’s a conditional yes, and the condition is ours to meet. In the project-start post, I wrote that the most exciting part would be finding out whether Johan could see himself using the application. Reading that answer was the closest I’ve come to finding out.
The line I would keep#
The article quotes my teammate and me on what AI can and can’t do in development:
“Den kan ikke afgøre, om det er det rigtige, der bliver bygget, eller om koden holder. Den vurdering skal vi selv kunne lave, og det er det, vi har lært på studiet.”
It can’t decide whether the right thing is being built, or whether the code holds up. We have to be able to make that judgment ourselves, and that’s what we’ve learned in our studies.
Jon Bertelsen made a similar point from the teaching side. He pointed to the architecture, the quality assurance and the ongoing documentation as the reasons the work holds up, and explained why he chose to teach AI in a customer-centred setting:
“Det er for at synliggøre, at AI kun hjælper, hvis man forstår en kundes behov.”
It’s to make it visible that AI only helps if you understand a customer’s needs.
The article mentions the speed: around 300 task descriptions, several AI agents working in parallel, and a website, an administration system and a couple’s page built in about two weeks. The speed is real, but it depended on the slower work that came first: the interview, the shared context, and grilling each feature before any agent started on it. Without that, the agents would have built something quickly, and it might not have been the right thing.
Looking back at the elective#
That idea runs through the whole series, even though the projects were very different.
The first post was about a RAG chatbot that made up numbers from its own training data until I told it to answer only from the document. The chatbot on this site taught me that what gets indexed matters as much as the model answering. With the rubric grader, I designed the prompts before writing code and then built validation gates because a fabricated quote is worse than no quote. In the post on spec-driven development, I wrote that a spec can’t replace the understanding the developers carry in their heads.
Engestofte brought all of that into one real project. We started with Johan’s interview, turned it into a shared plan, and worked in parallel with agents on separate tickets. We decided what the agents and an LLM should be allowed to see, showed the result to Johan and Lise, and looked at MCP as a possible next step that we chose to leave for later.
In each case, the useful work was deciding what the model should do, what it shouldn’t, and how to check its output. However fast the code got written, that part of the job stayed with us.
What comes next#
The project isn’t finished. The exam is still ahead, and as the article says, the Christmas market should become part of the system too. Johan estimated around a thousand emails with stallholders every year, and a large share of them could be automated. That’s the same problem as the weddings: the same information handled by hand in too many places.
Johan’s answer also raises a question we haven’t settled: what it would take to run this for real. Jon said in the article that the work “faktisk kan sættes i drift” (can actually be put into production), and that’s what we’ve aimed for. But production means more than working code. Someone has to host and maintain the system after the exam and fix it when something breaks, and Engestofte would need an agreement about how their customers’ data is handled. Those are conversations to have with Johan before we call it a finished product.
For this elective, though, this is where the series ends. It started with a chatbot that made up numbers and ends with a business saying they’d use what we built. Getting from one to the other was mostly about understanding the problem and checking the work.
This is the twelfth and final part of my posts on this semester’s AI-driven applications elective.