Where AI actually helped inside a program, and where it made things worse
I co-created an accelerator and run a monthly meetup and a community of over a thousand people. AI changed parts of that work and quietly damaged others. Both lists are short and specific.

Most writing about AI in innovation programs is about what a program could do. This is about what happened in mine. I co-created an accelerator, run a monthly practitioner meetup, and built a community past a thousand members in six months. Those are operations, and operations are where you find out whether a tool is real.
Where it clearly helped, in order of impact. First, reading applications. A cohort call generates a pile of forms where three quarters of every answer is filler. Asking for each application to be reduced to what the team does, who pays them today, what the ask is, and what is missing turned a two-day task into an afternoon and made the comparison between teams fair, because everyone got summarised against the same four questions instead of against my patience at that hour.
Second, preparation for mentor sessions. A mentor gets one hour with a founder. Before that hour, a one-page brief of the company, the obvious objections, and the two questions nobody has asked yet raises the quality of the session more than any additional mentor would. Third, program content. Curriculum drafts, session outlines, worksheet questions, follow-up emails, all in a first version I then cut in half. Fourth, research that used to be too expensive to do: mapping startups and formats across the region, which is how a piece of my ecosystem work exists at all.
Now where it made things worse, which is the part programs do not publish. Selection. The moment summaries drive the decision instead of informing it, you start selecting for teams who write clearly, which correlates with education and English, not with the ability to build a company. The founders I have been most wrong about in a good way were the ones who wrote badly and executed brutally. I now read every shortlisted application in the original form, no exceptions.
Second, founder communication. Generated updates and generated feedback are recognisable, and when a founder feels processed, they stop telling you the truth. A program lives on founders admitting what is not working, and that is a trust asset you can spend very quickly for a small saving in typing. Anything a founder receives from me personally, I write.
Third, the illusion of coverage. It is easy to produce a 40-page program document, a beautiful curriculum, a full mentor matrix, and mistake the artefact for the work. The work is a specific human in Belgrade who will take a call in December. No amount of generated structure creates that.
The rule I ended up with is one line: AI handles what nobody will remember receiving, and never the parts people remember. Summaries, drafts, briefs, research, internal structure, all fine. Selection, feedback, a difficult conversation, a partner relationship, all mine.
One more thing I did not expect. The biggest gain was not efficiency, it was that I could keep the program small. Small programs die from operational load, not from lack of ambition. Being able to run intake, briefs and reporting without a coordinator meant the program stayed close to the founders instead of growing a layer of administration to survive. That is the version of AI adoption I would argue for in any institution here: not more output, less scaffolding between you and the person you are supposed to help.
If you run a program or are designing one and want a blunt read on which parts of it should stay human, write to me. It is usually three or four tasks, and they are not the ones people expect.
Reply
If any of this is wrong, or right in a way you can add to, I would rather hear it. Write to antanaskoviczarko@gmail.com or find me on LinkedIn.