I'm not a developer; notes from three AI experiments

I am not a developer. I am testing how far I can go by combining what I have learned over the years in finance, investing and sport with AI tools. In recent months this curiosity has produced three concrete results: CourtScribe, which extracts basketball statistics from game video; Angel Lens, an analysis tool for angel investors; and VisemIQ, which tries to read lips from silent video.

None of the three is a finished product; all three are experiments. But each has taught me something about the question “who can do what with AI?”

CourtScribe: domain knowledge matters more than code

In amateur and youth basketball, statistics are often not kept at all, or are kept by hand and incompletely. My goal was simple: give the system a game video and get back a player-by-player table of points, rebounds, assists, steals, blocks, turnovers and fouls.

The system is made of parts that find players and the ball in the image, track players from frame to frame, read shirt numbers and turn the commentator’s words into text. It is now on its fourteenth version. The first lesson along the way was that the version that tried to do everything in a single pass failed: players were lost and ball detection collapsed. What worked was solving one problem per version, and separating player tracking from ball detection.

The second lesson was more surprising. The dictionary I built to correct errors in Turkish basketball commentary worked when it was built from errors in real transcripts rather than from assumptions. Here, knowing basketball mattered more than the code. The person who knows which word is “rebound” and which is “block” can also see what the model misheard.

The third lesson was accepting the limit. On wide-angle, moving amateur footage, fully automatic analysis is not yet reliable. So I tried a parallel path: a simple app that turns spoken commentary, recorded while watching the game, into a statistics table. Sometimes the right solution is to put the human back in the loop.

Angel Lens: teaching the model to say “I’m not sure”

I wanted to turn the evaluation discipline I used for years in venture capital into a tool that angel investors could use too. Angel Lens takes a start-up’s pitch deck and produces a structured analysis that resembles an institutional investment committee memo: market, competition, team, financial profile, valuation scenarios, a risk matrix and questions to ask in the meeting.

The most important lesson here came from an unexpected place. The model was giving a score of zero to criteria where data was missing. That is technically “correct” but misleading from an investment point of view: an absence of information is not the same as a bad result. I changed the instructions so that, where data is missing, the model gives a provisional score with low confidence. The lesson was that you have to teach a model not only what to do, but also how to say it is not sure. It is exactly what we expect from a good analyst.

The other lessons were more practical. Extracting the text in the browser, rather than sending large PDFs as they are, cut the data sent from megabytes to kilobytes. Adding live web search ran into rate limits, so I removed that feature. And grounding the evaluation framework in a real investment memo and set of criteria made the output noticeably more consistent.

VisemIQ: accepting that a hard problem is hard

VisemIQ takes its name from the project’s core difficulty. In lip reading, the same lip movement (a viseme) can correspond to more than one sound. That makes reading speech from images a much harder problem than recognising spoken audio. The first version reads English speech from lip movements; Turkish lip reading is the next research stage.

The most promising observation so far is that placing the raw output in context with a language model improves readability. Next comes a closed demo with a small number of users.

Notes from three experiments

1. Domain knowledge is still the most valuable input. AI makes writing code easier. It does not make it easier to be the person who knows what is right.
2. One problem per version. Progress comes from small, measurable steps, not big leaps.
3. Uncertainty has to be designed. A good system is one that can say what it does not know.
4. Knowing the limit of automation is also a solution. Sometimes the best product is not one that leaves people out, but one that makes their work easier.
5. Costs and limits are part of the design. Rate limits and API costs directly shape which features stay and whether a demo can be public.

I will keep sharing the details of these experiments in the AI Lab. I would also be glad to compare notes with other “non-developers” experimenting in this field.