For the second year in a row, I attended the University of Tartu’s Data Science Seminar as part of Tallinn Data Week. The thought that stayed with me most came from the closing panel: managers have always described what they want other people to build. Now we can give a computer instructions in much the same way. Have managers been vibe coding all along?
We reached that comparison towards the end of the evening. Before that, the discussion covered how to build AI systems that keep working when a model changes, when data cannot move freely, or when an experiment needs to become an everyday tool.
The University of Tartu Institute of Computer Science seminar “Data and AI: what, where and how?” took place on 20 October 2026 at Ülemiste Community House. Getting there was just as convenient as last year: a bus from the university in Tartu to Tallinn and back afterwards. There was no need to arrange separate transport.
Jaak Vilo: where does an AI agent actually run?
As last year, Jaak Vilo opened the evening. His introduction included a useful diagram of the different parts of an AI agent: some on your computer, some in the cloud, with requests, tool calls and results passing between them.
That is worth pausing over. Running an AI application on your own computer does not necessarily mean all the processing happens there. You need to understand what each component does and where the data goes. I have covered the tool-connection side of this in my article on what an MCP connection is.
Allan Bernard: what happens if the model disappears tomorrow?
Allan Bernard, Head of Engineering at Nortal Estonia, addressed something worth considering when you build your first solution. A company’s workflow should not depend so heavily on one particular AI model that losing access means rebuilding everything.
I remembered Allan’s example of Fable 5. There is public background to it too: he discussed model availability in his article “The sovereign off-switch”. According to Anthropic’s announcement, access to Fable 5 was suspended on 12 June 2026 and restored on 1 July. A company using the model had no control over that interruption.
For me, the practical question is this: if our current model stops responding tomorrow, what happens to our work? Can we use another model, continue part of the process manually, or does everything stop?
Changing models is not necessarily as simple as changing a name in the settings. Instructions, tools and output quality still need to be checked with the replacement. But you can prepare for that. Replacing a component is a different task from rebuilding the whole system during an interruption.
Gamal Elkoumy: bringing AI and sensitive data together carefully
Veriff data engineer Gamal Elkoumy spoke about AI agents inside a regulated data platform. What interested me was the idea of bringing data and AI capabilities together in a controlled environment, rather than sending data to another new destination for every task.
Listening to the talk, I understood it this way: sometimes the processing environment itself needs to be reorganised so that AI can work with data where that processing is permitted. Their solution was much more complex than a single sentence can convey. A server’s location alone does not tell you who has access or what they are allowed to do with the data.
Gamal also has a research background in this area. His doctoral thesis at the University of Tartu examined privacy-preserving process mining. In simpler terms, it explored how to learn useful things from business process data without exposing people’s private information. That helps explain why the boundaries around data use matter in his work.
Heili Aavola: private hardware gives you control, but requires resources
Heili Aavola, a Junior Research Fellow in Machine Learning at the University of Tartu, discussed running agents on private hardware. I liked that the presentation covered the practical difficulties too: speed, computing resources and how to assess the result from a user’s perspective.
Running an open model in your own environment can give you more control. You also need hardware, a configured system and realistic expectations of its performance. The talk was a reminder of how much work can sit behind a seemingly simple chat window.
In the user test of the first version shown on her slide, six out of seven people said they would use the system again. Seven respondents is a small sample, but I found it useful to see the question framed around whether the answers were good enough for the user’s work. A general model leaderboard cannot decide that on its own.
Heili’s master’s thesis also concerned evaluating model reliability, specifically probability calibration in binary classification. That asks how closely a model’s expressed confidence matches the results it actually achieves.
Bolt: let people build, then assess what is useful
After the break, Toomas Römer, Bolt’s Vice President of Engineering, took the stage. His presentation showed how many different uses for AI can exist within one company.
Boltable particularly caught my attention. When employees want to build small tools for their own work, it makes sense to give them an internal environment for doing so. They can try an idea where access and use are already organised.
In Römer’s own public description of Boltable, it is a hosting environment for small internal tools, with access controls included. He also sets boundaries: no customer-facing applications, personal or financial data, or systems carrying the company’s core business.
Those boundaries are part of what makes the example interesting to me. Employees get a way to build, while every experiment does not automatically become a core company system. When someone in the audience asked about a particularly big breakthrough, my recollection of the answer was that there was no single silver bullet to point to yet. A small helper can still make someone’s weekly work easier.
Another useful part was model evaluation. The slide compared measures including accuracy, cost and response latency. My takeaway was simple: test a new model on your own task. A newer name does not tell you whether it will do that particular job better.
Sander Kütisaar and SAPU: an option for sensitive business data
Sander Kütisaar, a system administrator at the University of Tartu HPC Center, introduced SAPU. Its Estonian name stands for a private research environment for sensitive data.
According to the HPC Center’s service description, a project receives an isolated virtual machine in a data centre in Estonia. Internet access is disabled, user activity is logged, and the data owner controls transfers into and out of the environment.
This is useful for businesses to know as well. The SAPU user guide covers data owners both inside and outside the university. A company can therefore ask whether the service fits its project. It is a paid service, and the work, software, access arrangements and cost need to be agreed with the centre.
I like knowing that options like this exist. A company does not have to design every complex data-processing environment from scratch on its own.
Have managers been vibe coding all along?
The panel also turned to vibe coding and jobs. Does AI now do everything? Are more people still needed?
What I remember from Allan’s and Toomas’s answers is that they are still looking for people. The value is in someone who can understand a problem, propose solutions and take responsibility. Writing code to a supplied specification is only one part of that.
I also took away from both speakers that engineering review remains important for software going into production. Using AI at different stages of development does not remove the company’s responsibility to understand what it is putting into use.
Allan’s comparison with managers was the most memorable part for me. Here is the idea as I remember it: a manager describes the desired outcome in a meeting, draws on a whiteboard and explains what is needed. The team works out how to implement it. The manager does not have to perform every technical step personally.
With vibe coding, we also describe an intended result in natural language, with AI handling part of the implementation. In that sense, a way of working familiar to managers with their own teams is becoming available to many more people. It is an analogy, of course, rather than a claim that managing people and programming with AI are the same activity.
I like that perspective. You can start and test more ideas yourself. You still need to explain what is needed and decide whether the result is suitable. I have explored the possibilities and limits in more detail in “What is vibe coding?”.
On the journey back from Tallinn, several ideas stayed with me: models need to be replaceable, data needs a carefully designed processing environment, and the ability to build needs to come with the ability to evaluate the result. Above all, I kept thinking about how much still depends on explaining the task clearly.
That is something worth practising both individually and as a team. If you want to start using AI with your company’s own tasks, see the options for AI team training. One useful starting point is to take a task currently done manually and work through which part AI could help you do better.