About Lars
I came to AI through work.
I’m Lars Köhler, an electrical engineer with more than twenty years in industry. I care about what happens after the AI demo ends and the result has to survive a normal working day.
The Short Version
I like tools. I trust the process around them.
I have spent most of my working life around technical systems. In that world, a good idea still needs a reliable input, clear ownership, a check, and a plan for failure. People have to understand what the system is doing well enough to use it and notice when it changes.
AI brought back the excitement I felt when I first learned what computers could do. It also brought a familiar problem. A polished demonstration makes the tool look like the entire solution. The hard work appears later, when inputs vary, exceptions arrive, and somebody has to decide whether the answer is safe to use.
That gap is where I work and where I want this site to be useful.
Why I Started Publishing
I wanted the missing pages of the manual.
There is plenty of AI content. I kept finding the same gap: the useful example ended exactly where my questions began. What did the input look like? How long did checking take? Which parts were rewritten? What happened the second time? Did another person understand the handoff?
I am not interested in pretending every test produces a breakthrough. Sometimes the answer is that a plain checklist works better. Sometimes the AI saves an hour but creates a new review task. Sometimes a workflow becomes useful only after the source material is cleaned up. Those outcomes deserve a place in the article.
AI with Lars is my way of keeping a public notebook with enough structure that another person can use it. The writing is for people who want to learn AI by doing real work, including readers who have no interest in becoming developers or following every model release.
What Experience Changes
I ask who owns the next step.
Engineering taught me to look beyond the component in front of me. A sensor can work perfectly while the wider system fails because the signal goes nowhere. An AI answer can be accurate while the workflow fails because nobody knows who should read it, approve it, or act on it.
So I start with ordinary questions. What job are we trying to finish? Which information counts as the source? What is the cost of being wrong? Who notices an exception? Where does feedback go? The model matters, but these questions often change the result more than another round of prompt polishing.
I also care about language. New tools arrive wrapped in terms that make basic ideas sound more complicated than they are. I will use the technical name when it helps. Then I will explain what it means in the work.
If I cannot explain what a workflow does without hiding behind jargon, I do not understand it well enough to recommend it.
My Rules for This Site
Specific work. Honest limits.
These rules are here to keep the library useful as it grows.
I publish after the work
A proposed test can be interesting, but it is not a result. I will separate what I have done from what I still plan to try.
I name the conditions
Tools change. Plans differ. A result from September 2026 may need another check later. Dates and sources make that visible.
I count the repair
Review, corrections, formatting, and exception handling belong in the workload. Leaving them out turns documentation into advertising.
I keep the useful material free
A guide should make sense without forcing you into a course, membership, or email sequence to get the missing instruction.
Talk to Me
Give me something worth testing.
If you have a task, recurring frustration, or AI claim you want examined, send it through the form. I read the submissions myself.