How attending an international AI summer school shifted my understanding from theoretical AI capabilities to practical implementation constraints, plus what happens when students and companies collaborate on real automation problems instead of hypothetical case studies.

Core insights:

JUST READ THE POST WITH THE MAIN POINTS →

There is a particular quality to September mornings in Skopje. The summer heat has not quite released its hold, but something in the air suggests it will. I walked into the Faculty of Economics carrying a notebook I had convinced myself I would fill, and a quiet suspicion that this week would be different from the conferences I had attended before.

The 14th International Summer School carried a subtitle that told you everything about its intentions: Students and Companies Co-creating the Future. I had grown cautious of words like co-creating. They appear on agendas and partnership announcements with such frequency that they begin to mean nothing at all. But this time, the word proved accurate.

Company representatives sat among us from the first morning. Not positioned behind podiums delivering rehearsed insights, but at the same tables, carrying the same uncertainty about what the week would produce. They had come with problems. Real ones. The kind that do not resolve themselves through slide decks.

Magdalena Mitreva from EXO Service Solutions became our collaborator. Her company builds software. Our task was to design an AI tool that could automate essential workflows within their operations.

I will tell you what that sentence does not contain: the hours spent understanding why their processes existed in the first place. Software companies accumulate decisions the way old houses accumulate layers of paint. Each one made sense at the time. Each one responded to a constraint that may or may not still exist. Why does this approval require three signatures. Why is this data copied manually between systems every Thursday. Why does this report take half a day to compile when the underlying information already lives in six different databases.

The answers, I learned, are almost never technical. They are organizational. Historical. Sometimes political. A process exists because a client once requested it. A manual step remains because the person who understood the automated alternative left two years ago and no one has revisited the workflow since.

Designing automation for a living company means understanding all of this before writing a single prompt. The AI implementation is often the simplest part. The archaeology that precedes it is where most projects fail.

We covered AI tool creation, data analysis applications, and something the program called AI co-leadership. That phrase stayed with me. It suggests a relationship rather than a replacement. It acknowledges that humans and AI systems each carry capabilities the other lacks, and that the craft lies in understanding where one ends and the other begins.

Mijalche Santa guided the program with an approach I have since borrowed for my own work. Do not begin with what the technology can do, he told us. Begin with what the organization actually needs. Work backward from there.

This inversion changes everything. Most AI enthusiasm starts with capability and searches for application. Most successful AI implementation starts with friction and searches for resolution. The difference sounds subtle. In practice, it determines whether a project survives contact with reality.

I returned to my work at Omnilyst carrying something I had not expected: a framework. Not a template or a checklist, but a way of seeing automation problems that I had not possessed before.

The tools we explored during those four days became reference points. Not because they could be copied directly into different contexts, but because they demonstrated an approach. Start with the process. Understand why it exists. Identify where humans spend time on tasks that do not require human judgment. Only then consider which AI capabilities might address those specific moments.

This sounds obvious when written plainly. It is not obvious when you are surrounded by demonstrations of impressive capabilities and begin to believe that the technology itself will find its applications.

The Faculty of Economics has been running these international summer schools for fourteen years. The AI focus is newer, but the format of bringing students and practitioners together carries institutional memory. There is something in how they structure the days that allows genuine collaboration rather than performance.

What most AI education misses is the implementation gap. The distance between understanding that something is possible and understanding how to make it work within specific constraints, for specific people, who have specific ways of doing things that they may not even recognise as choices anymore.

That gap is where projects go to die. Not because the technology fails, but because the translation was never done with sufficient care.

The summer school did not eliminate that gap. Nothing can. But it made the gap visible in a way that changes how you approach every project afterward. You stop asking what can AI do. You start asking what does this organization actually need, and which parts of that need can AI address without creating more problems than it solves.

Until next time,