What Happens When You Bring 25 Years of Experience to Vibe Coding

Wieloagentowa redakcja. Proaktywny domowy towarzysz AI. Gra multiplayer zbudowana w 5 godzin. Trzy projekty, jedno pytanie: gdzie dokładnie kończy się człowiek, a zaczyna AI?

Chcę opowiedzieć wam o mojej przygodzie z AI i vibe codingiem (choć wolałbym to nazywać AI Engineeringiem) - i o tym, co się dzieje, gdy wnosisz do tego prawdziwe doświadczenie, a nie tylko prompty.

Trochę tła

Gdy byłem w 7. klasie, koledzy mieli komputery z procesorami Pentium. A ja miałem Commodore 64. Rok później przesiadłem się na 286 - już o pokolenie przestarzały. Dysk twardy mi padł, więc pracowałem na około 30 dyskietkach: jedna do uruchomienia DOS-a, druga do załadowania QBasica, kolejna do załadowania moich projektów. Każda sesja zaczynała się od 10-minutowego rytuału wymiany dyskietek, żeby w ogóle móc pisać kod.

Budowałem interfejsy paneli sterowania ze Star Treka. Komputer pokładowy z Enterprise - ten, który rozumie kontekst, przewiduje potrzeby, odzywa się, gdy ma do powiedzenia coś wartościowego - to było to, co chciałem urzeczywistnić, zaczynając od fajnego UI i animacji.

Kilka lat później, gdy Microsoft wypuścił Visual Studio, zrobiłem coś, co przeraziło moich rodziców. Miałem jakieś 14 lat. Napisałem do Microsoftu maila z prośbą o studencką wersję VS. Trzy tygodnie później ze Stanów Zjednoczonych przyszła wielka paczka. Pełny pakiet Visual Studio, podręcznik do programowania na 1000+ stron, gadżety, vouchery na kursy. Mama wpadła w panikę - była przekonana, że będziemy musieli za to wszystko zapłacić.

Nie musieliśmy. Po prostu się uczyłem. Dniami i nocami, kiedy tylko miałem wolną chwilę. Najpierw Visual Basic, potem PHP, bo chciałem budować strony, potem Flash i ActionScript, potem C#. Wszystkiego sam. Nie dlatego, że kochałem kod dla samego kodu - dlatego, że kod był narzędziem, które pozwalało mi rozwiązywać problemy, jakie widziałem wokół siebie. Problemy, których nikt inny nie rozwiązałby tak, jak ja chciałem (oczywiście w oparciu o rozmowy z innymi). Musiałem nauczyć się robić to sam.

Ten napęd przeprowadził mnie od programisty przez architekta systemów do CTO - a potem ostro skręciłem. Zrozumiałem, że nie chcę projektować backendów. Chciałem projektować to, czego użytkownicy naprawdę dotykają. Programowanie zawsze było moim narzędziem do rozwiązywania prawdziwych ludzkich problemów. Więc przeszedłem do UX. Nie odchodząc od rozwiązywania problemów - bliżej ludzi, dla których je rozwiązywałem.

25 lat później wciąż robię to samo. Narzędzia się zmieniły - od QBasica na dyskietkach do Claude Code w terminalu. Ambicja nie.

Trzy projekty, nad którymi teraz pracuję, testują to samo pytanie z różnych stron: jak naprawdę wygląda skuteczna współpraca człowieka z AI, gdy wyjdziesz poza demo?

Oto, co odkryłem i co może was zaskoczyć.

Ballywood - Gdy 6-latka zostaje product ownerem ;-)

Zaczęło się od eksperymentu. Siedziałem z kolegą (pozdro, Mateusz), rozmawialiśmy o Claude Code i powiedziałem: "Pokażę ci, jakie rzeczy można zbudować." Wymyśliłem pomysł na prostą grę, otworzyłem terminal i zacząłem.

5 godzin później mieliśmy 10 000+ linii kodu. Pełną izometryczną grę przeglądarkową multiplayer - proceduralnie generowane nieskończone mapy z biomami, cyklami dnia i nocy, AI zombie, fizyką ognia, systemem pogody. Czysty HTML5 Canvas i JavaScript, zero frameworków, zero bundlerów. Po prostu node server.js i grasz.

Możecie sprawdzić sami tutaj (sorry, ale tylko Desktop): https://digitalmindnews.com/kabareton/

Najbardziej zaskoczyła mnie nie prędkość. To, jak zadziałała współpraca z AI - dawanie mu otwartych pytań i "wolnej woli". Było wiele przykładów funkcjonalności, które wyłoniły się z tego, co wymyślaliśmy razem. Rąbiesz drewno. Podpalasz je. W nocy pojawiają się zombie. Zombie boją się ognia. Deszcz gasi ogień. Nagle podejmujesz prawdziwe taktyczne decyzje - bronisz się ogniem czy uciekasz? To wyłoniło się z rozmów, ze współpracy między moim kolegą, mną i Claude Code.

Było też wiele drobiazgów, które przychodziły mi do głowy, i dzięki precyzyjnym promptom mogłem szybko dodawać ukryte przedmioty, mini gry, opisywać, jak piłka ma się animować, żeby była płynniejsza. Również pełne rozwiązania UX i UI stanowiły ogromny % mojej pracy. Ale to prowadzi do innego tematu:

Vibe coding to nie "AI robi wszystko za mnie". Animacja chmur była doskonałym przykładem. Claude Code nie potrafił zrozumieć, jak mają się animować nad izometryczną mapą. Spędziłem sporo czasu na prompt engineeringu - starannie tłumacząc zasady renderowania, kolejność warstw, wzorce ruchu. Gdy natrafiliśmy na poważny błąd renderowania, musiałem napisać 15+ zdań niezwykle precyzyjnego opisu technicznego, uwzględniającego sortowanie głębi, kotwiczenie kafelków, viewport culling. Piętnaście minut później zadziałało. Wniosek: im lepiej sam rozumiesz technologię, tym lepiej komunikujesz intencje AI, tym szybciej osiągasz wyniki. Twoja wiedza techniczna nie staje się przestarzała - staje się twoim interfejsem.

Potem przyszła najlepsza część. Moja 6-letnia córka pograła w grę przez kilka minut i wróciła z prośbami o nowe funkcje. Rzeczy, które chciała dodać. W ciągu 30 minut jej pomysły były zaimplementowane i działały. Było to bardzo zabawne, a dla mnie też trochę abstrakcyjne, że możemy tak pracować - że moja córka od razu zaczęła wyobrażać sobie kreatywne rzeczy.

Ścieżka od pogaduszek z przyjaciółmi i budowania gier zaczęła się zmieniać. Dziecko coś sobie wyobraża. Mówi tacie. Tata mówi AI. To istnieje. Ta ścieżka - od wyobraźni dziecka do działającego oprogramowania w pół godziny - tak właśnie wygląda demokratyzacja tworzenia oprogramowania. Nie marketingowy slogan. Wtorkowy wieczór.

PressGarden - Redakcja, w której 80% kodu nie dotyczy pisania

PressGarden to wieloagentowy system, który prowadzi wirtualną redakcję. Scrapuje ~30 źródeł (TechCrunch, Wired, SecurityWeek, Dark Reading...), grupuje artykuły w podtematy za pomocą NLP, a następnie redaktorzy AI - sześciu fikcyjnych dziennikarzy o odrębnych specjalizacjach i stylach pisania (wszystkich przygotowałem ja, w oparciu o research z czołowych redakcji jak Washington Post, NYT itd.) - syntetyzują oryginalne artykuły. Tytuły, tagi, SEO, zdjęcia główne z Pexels, linkowanie wewnętrzne. Pełna ścieżka: RSS/Web -> Scraping -> Klastrowanie -> Synteza AI -> Publikacja na WordPress.

Zacząłem to ponad rok temu, zanim fala "agentic AI" miała nazwę. Napisałem rozbudowaną specyfikację funkcjonalną (przez rozbudowaną mam na myśli 20+ stron), zaprojektowałem persony redakcyjne (osobne pliki dla każdej persony), zmapowałem całą ścieżkę. Zbudowałem działający prototyp, postawiłem WordPressa, kupiłem serwer. A potem trafiłem na ścianę - jakość treści generowanych przez AI była niewystarczająca. Zbyt wiele błędów, zbyt wiele przypadków brzegowych. Zrozumiałem, że technologia nie jest jeszcze gotowa, i odłożyłem projekt na 9 miesięcy. Ale i tak - udało mi się zbudować coś działającego, co - patrząc na moje doświadczenie - kazałoby mi studiować programowanie, API itd. Pod kątem wiedzy to świetne; pod kątem szybszego prototypowania, możliwości skupienia się na rozwiązaniu problemu, dążenia prosto do celu - byłyby to miesiące nieustannej frustracji.

Trochę newsów możecie poczytać tutaj: https://digitalmindnews.com/ :-)

Gdy Anthropic wypuścił nową wersję Claude Code, wszystko się zmieniło. Ta sama baza kodu, która tonęła w bugach, nagle dostała współpracownika, który potrafił rozumować o logice, znajdować problemy strukturalne i pomagać mi systematycznie refaktoryzować. Podnieśliśmy skuteczność ścieżki z 14% do 79% w jednym sprincie. I tak - to jest coś, co z mojego doświadczenia trzeba ustawić: KPI, co liczy się jako sukces. Bez tego trudno przejść przez cały kod i sprawdzić, czy działa dobrze. Myślę też, że na tym poziomie abstrakcji nie chcę mikrozarządzać Claude Code - raczej walidować kluczowe KPI.

A oto wniosek, który zaskoczył mnie najbardziej: wygenerowanie artykułu to jedno wywołanie API. Upewnienie się, że artykuł jest naprawdę dobry - to 80% bazy kodu. Walidatory artykułów. Syntezator treści (walidacja i czyszczenie). Zakazane słowa w tytułach ("revolutionizing", "game-changing" itd.). Punktacja SEO. Cztery warstwy deduplikacji - oparta na hashach dla opublikowanych artykułów, nakładanie się słów kluczowych przed syntezą, podobieństwo tytułów w ramach cyklu, nakładanie się tematów z historią. Każda warstwa wyłapuje coś innego.

Kolejna lekcja: architektura mikroserwisowa, którą zaprojektowałem na etapie prototypu, nigdy nie zadziałała na produkcji. Wszystkie te osobne serwisy ze wspólnym messagingiem - piękne na papierze (Same fundamenty zajęły prawie 2 tygodnie - architektura techniczna, badanie, jak naprawdę działają prawdziwe redakcje, przemyślenie przypadków brzegowych, zanim napisałem choć jedną linijkę kodu), bezużyteczne w praktyce. Wróciliśmy do monolitu. I to ten monolit faktycznie dostarcza 15 artykułów w jednym przebiegu do digitalmindnews.com, z prawdziwymi użytkownikami wracającymi po treści. Jak to interpretuję? Za bardzo wszedłem w mikrozarządzanie.

Zelda - Budowa komputera ze Star Treka, naprawdę

Narzędzie konsolowe do rozpoznawania głosu Zeldy

Pamiętacie panele sterowania ze Star Treka, które budowałem na tym zepsutym 286? Przez lata wracałem do tego pomysłu - wersje w Visual Basicu, eksperymenty webowe, prototypy koncepcyjne. Przygotowałem nawet projekt w C do animowania interfejsów konsolowych (te pomarańczowe okrągłe linie itd.). Marzenie o komputerze pokładowym, który rozumie kontekst i odzywa się, gdy ma do powiedzenia coś wartościowego, nigdy nie zniknęło.

Teraz remontuję dom. I zdecydowałem, że to czas, by go naprawdę zbudować.

Zelda będzie proaktywnym domowym towarzyszem AI (przynajmniej to chcę osiągnąć). Nie chatbotem. Nie Alexą. Kluczowa różnica: Zelda nie będzie czekać na pytania. Będzie monitorować domowe czujniki - temperaturę, ruch, kalendarz (mam nadzieję, że w następnym kroku spróbujemy podłączyć kamery z mojego lokalnego systemu bezpieczeństwa, by uzyskać więcej informacji o tym, co dzieje się w domu) - będzie słuchać, kto mówi w pokoju, i sama decydować, kiedy zainterweniować.

Teraz mam PoC na moim komputerze, rozpoznawanie głosu wielu mówców, framework dla pamięci, proaktywne zachowanie itd. Architektura opiera się na 6 pracach naukowych: CoALA dla trójpoziomowej pamięci, PROPER dla kalibracji proaktywności, ProUtt dla drzew intencji z kompromisem eksploracja/eksploatacja - to prace, które znalazłem podczas researchu przy przygotowywaniu specyfikacji promptów. Poza tym... to nie są dekoracyjne odniesienia - kształtują faktyczną strukturę kodu: 4 typy wyzwalaczy (czas, zdarzenie, stan, luka epistemiczna), 3 poziomy pamięci, pętla postrzegaj-planuj-działaj-refleksja.

Choć pisałem o pewnych rzeczach technicznych, to, na co poświęcam najwięcej czasu przy promptowaniu (dyskusjach z Claude), to interakcje człowiek-AI. Najtrudniejszy problem koncepcyjny: kiedy AI powinno się odezwać, a kiedy zachować milczenie? Zbyt wiele interwencji - irytujące. Zbyt mało - bezużyteczne. No i wiecie - nie chcę mieć w domu "Kasandry" ;-) Każda iteracja, każdy przypadek brzegowy to kwestia doświadczenia, pain pointów, sytuacji z prawdziwego życia. Nie ma mowy, żebym wyliczył je wszystkie, ale odkryłem, że potrafię uogólnić te zachowania, które muszą być obecne. Inni mogą wykorzystać tę ogólną wiedzę i dostosować - albo poprosić o pomoc prawdziwych ludzi. Widzicie, jak to pomaga skupić się na rozwiązaniach, otoczeniu, doświadczeniu zamiast na tworzeniu programów, które da się rozwijać (piekło MVP)?

Co do prędkości, oto kolejny ciekawy wniosek: kompletny silnik proaktywności został zbudowany i przetestowany w 1 dzień. Pamięć, percepcja, podejmowanie decyzji, integracja z LLM, orkiestracja, i18n, działające przykłady - 2 dni. Inne nudne rzeczy ;-) zajęły jakieś 6-7 dni. Od pustego katalogu do PoC, który słucha, myśli i decyduje, kiedy się odezwać, w około 10 dni. Wciąż sporo do zrobienia, trochę bugów, testy, walidacje, zwiększanie wydajności (zaraz kupię trochę mocy obliczeniowej z RunPod), ale... 10 dni... WOW.

A dla tych, którzy zastanawiają się, dlaczego "Zelda" - nazwa pochodzi od mojej ulubionej postaci z dzieciństwa z czasów Nintendo. Niektóre obsesje nie znikają. Po prostu czekają, aż technologia je dogoni :-)

Podsumowanie

Trzy różne projekty. Ten sam wzorzec pod spodem każdego z nich.

Ballywood nauczyło mnie, że współpraca z AI działa najlepiej, gdy człowiek wnosi precyzję, a AI wnosi prędkość - i że magia dzieje się w rozmowie między nimi. Prośba 6-latki o funkcję zaimplementowana w 30 minut. Błąd animacji chmur naprawiony 15 zdaniami starannego opisu technicznego. Człowiek nie staje się przestarzały. Człowiek staje się interfejsem, mostem.

PressGarden nauczyło mnie, że generowanie treści przez AI to problem jakości inżynierskiej, a nie problem generowania. Model pisze z łatwością. Wszystko wokół modelu - pozyskiwanie źródeł, walidacja, deduplikacja, KPI, wiedza kiedy mikrozarządzać, a kiedy odpuścić - to tu mieszka prawdziwa praca.

Zelda nauczyła mnie, że najtrudniejsze problemy w AI nie są obliczeniowe. Są relacyjne. Kiedy AI powinno się odezwać? Jak projektować zaufanie do maszyny, która mieszka w twoim domu? Jak odpowiedzialnie obchodzić się z najbardziej intymnymi danymi?

Żaden z tych problemów nie mieszka wewnątrz modelu. Wszystkie mieszkają w przestrzeni między systemem a człowiekiem.

Dzieciak z 30 dyskietkami piszący maile do Microsoftu nie uczył się tylko kodować. Szukał sposobów na rozwiązanie problemów, które były dla niego ważne - i uczył się wszystkiego, czego musiał, by tam dotrzeć.

25 lat później narzędzia są nie do poznania lepsze. Misja jest dokładnie ta sama: uczynić ludzkie życie trochę lepszym, jedno rozwiązanie naraz.

P.S. Obecnie eksploruję, co dalej. Jeśli twój zespół rozwiązuje trudne problemy na styku AI, UX i myślenia systemowego - pogadajmy. Najlepiej pracuję tam, gdzie liczy się precyzja, a ludzie wciąż są w pętli.

P.P.S. Anthropic Tak tylko macham ręką, może zadziała jak z Microsoftem

A multi-agent newsroom. A proactive home AI companion. A multiplayer game built in 5 hours. Three projects, one question: where exactly does the human end and the AI begin?

I want to tell you about my adventure with AI and vibe coding (alto I would rather name it AI Engineering) - and what happens when you bring real experience to the table, not just prompts.

Some background

When I was in 7th grade, my classmates had computers with Pentium processors. While I had a Commodore 64 A year later I upgraded to a 286 - already outdated by a generation. My hard drive broke, so I worked off around 30 floppy disks: one to boot DOS, another to load QBasic, another to load my projects. Every session started with a 10-minute disk-swapping ritual just to write code.

I was building Star Trek control panel interfaces. The onboard computer from the Enterprise - the one that understands context, anticipates needs, speaks when it has something valuable to say - that was the thing I wanted to make real, starting with some cool UI and animations.

A couple of years later, when Microsoft released Visual Studio, I did something that terrified my parents. I was maybe 14y. I wrote Microsoft an email asking for a VS student edition. Three weeks later, a large package arrived from the United States. Full Visual Studio suite, a 1,000+ page programming textbook, gadgets, course vouchers. My mother panicked - she was convinced we'd have to pay for all of it.

We didn't. I just studied. Days and nights whenever I had free time. Visual Basic first, then PHP because I wanted to build websites, then Flash and ActionScript, then C#. Everything self-taught. Not because I loved code for its own sake - because code was the tool that let me solve problems I saw around me. Problems nobody else would solve the way I wanted (of course, based on discussions with others). I had to learn to do it myself.

That drive pushed me from developer to system architect to CTO - and then I made a sharp turn. I realized I didn't want to architect backends. I wanted to design what users actually touch. Programming had always been my tool for solving real human problems. So I moved to UX. Not away from problem-solving - closer to the people I was solving problems for.

25 years later, I'm still doing the same thing. The tools changed - from QBasic on floppies to Claude Code in the terminal. The ambition didn't.

Three projects I'm working on right now test the same question from different angles: what does effective human-AI collaboration actually look like when you push past the demo?

Here's what I've found and might supprise you.

Ballywood - When a 6-year-old becomes a product owner ;-)

Screen from the Ballywood game — Screen from the game

It started as an experiment. I was sitting with a friend (greetings, Mateusz), talking about Claude Code, and said: "Let me show you what kind of things you can build." I came up with an idea for a basic game, opened the terminal, and started.

5 hours later we had 10,000+ lines of code. A full multiplayer isometric browser game - procedurally generated infinite maps with biomes, day/night cycles, zombie AI, fire physics, a weather system. Pure HTML5 Canvas and JavaScript, zero frameworks, zero bundlers. Just node server.js and you play.

You can check it out yourself here (sorry but Desktop only): https://digitalmindnews.com/kabareton/

What surprised me most wasn't the speed. It was how collaboration with AI - giving it open questions and "free will" - worked. There were many examples of emerged functionalities that we came up with together. You chop wood. You light it on fire. Zombies appear at night. Zombies are afraid of fire. Rain puts out fire. Suddenly you're making real tactical decisions - protect yourself with fire or run? It emerged from discussions, from collaboration between my friend, me, and Claude Code.

There where also many small things that came to my mind, and with precise prompts I was able to quickly add hidden items, mini games, describe how ball needs to animate to be more fluid. Also full UX and UI solutions was a huge % of my work. But that points to another topic:

Vibe coding isn't "AI does everything for me." Animation of the clouds was a perfect example. Claude Code couldn't understand how they should animate over the isometric map. I spent significant time on prompt engineering - carefully explaining the rendering rules, the layer ordering, the movement patterns. When we hit a serious rendering bug, I had to write 15+ sentences of extremely precise technical description, accounting for the depth sorting, the tile anchoring, the viewport culling. Fifteen minutes later, it worked. The insight: the better you understand the technology yourself, the better you communicate intent to AI, the faster you get results. Your technical knowledge doesn't become obsolete - it becomes your interface.

Then came the best part. My 6-year-old daughter played the game for a few minutes and reported back with feature requests. Things she wanted added. Within 30 minutes, her ideas were implemented and running. It was so fun, and also a bit abstract to me that we can work that way - that my daughter immediately started to imagine creative things.

The pipeline from small talk with friends and building some games started to change. A child imagines something. Tells her father. Father tells AI. It exists. That pipeline - from a kid's imagination to working software in half an hour - that's what democratization of software creation actually looks like. Not a marketing phrase. A Tuesday evening.

PressGarden - The newsroom where 80% of the code isn't about writing

Screen from the digitalmindnews.com website

PressGarden is a multi-agent system that runs a virtual newsroom. It scrapes ~30 sources (TechCrunch, Wired, SecurityWeek, Dark Reading...), clusters articles into subtopics using NLP, then AI editors - six fictional journalists with distinct specializations and writing styles (all prepared by me base ond research from top newsrooms like Washington Post, NYT etc.) - synthesize original articles. Titles, tags, SEO, featured images from Pexels, internal linking. Full pipeline: RSS/Web -> Scraping -> Clustering -> AI Synthesis -> WordPress publishing.

I started this over a year ago, before the "agentic AI" wave had a name. I wrote an extensive functional spec (by extensive I mean 20+ page), designed editorial personas (separate files for each persona), mapped the entire pipeline. Built a working prototype, set up WordPress, bought a server. And then hit a wall - the AI-generated content quality wasn't good enough. Too many errors, too many edge cases. I realized the technology wasn't ready yet and shelved the project for 9 months. But still - I was able to build something working that, looking at my past experience, would have led me to study programming, APIs, etc. In terms of knowledge that's great; in terms of faster prototyping, being able to focus on solving the problem, going straight to the target - it would have been months of constant frustration.

You can read some news here: https://digitalmindnews.com/ :-)

When Anthropic launched a new version of Claude Code, everything changed. The same codebase that was drowning in bugs suddenly had a collaborator that could reason about logic, find structural issues, and help me refactor systematically. We took the pipeline success rate from 14% to 79% in one sprint. And yeah - that is something that from my experience needs to be set up: KPIs, what counts as success. Without that it's hard to go through all of the code and see if it works fine. I also think that at this level of abstraction I don't want to micromanage Claude Code - rather validate crucial KPIs.

And here's the insight that surprised me most: generating an article is one API call. Making sure the article is actually good - that's 80% of the codebase. Article validators. Content synthesizer (validation and cleanup). Banned title words ("revolutionizing," "game-changing" etc.). SEO scoring. Four layers of deduplication - hash-based for published articles, keyword overlap before synthesis, title similarity per cycle, topic overlap with history. Each layer catches something different.

Another lesson: the microservice architecture I designed in the prototype phase never worked in production. All those separate services with shared messaging - beautiful on paper (Almost 2 weeks went into the groundwork alone - technical architecture, researching how real newsrooms actually work, thinking through corner cases before writing a single line of code), useless in practice We went back to a monolith. And that monolith is what actually ships 15 articles in a single run to digitalmindnews.com, with real users coming back to consume the content. How do I interpret this? I was too into micromanagement.

Zelda - Building Star Trek's computer, for real

Console tool for Zelda voice recognition

Remember the Star Trek control panels I was building on that broken 286? Over the years, I kept iterating on that idea - Visual Basic versions, web experiments, concept prototypes. I even prepared a C project for animating console interfaces (those orange round lines, etc.). The dream of an onboard computer that understands context and speaks when it has something valuable to say never went away.

Now I'm renovating my house. And I decided it's time to actually build it.

Zelda will be a proactive AI home companion (at least is what I want to achieve). Not a chatbot. Not Alexa. The key difference: Zelda won't wait for questions. She will monitor home sensors - temperature, motion, calendar (hopefully next we will try to connect to cameras from my local security system, to get some more information about what is going on in the house) - will listens to who's speaking in the room, and decides on her own when to intervene.

Right now i have a PoC on my computer, a voice recognition across many speakers, a framework for memory, proactive behaviour etc. The architecture is grounded in 6 academic papers: CoALA for three-level memory, PROPER for proactive calibration, ProUtt for intent trees with exploration/exploitation tradeoffs - those are the papers that I found during my research for preparing prompt specyfication. Also... these aren't decorative references - they shape the actual code structure: 4 trigger types (time, event, state, epistemic gap), 3 memory levels, a perceive-plan-act-reflect loop.

Although I wrote about some technical things, what I spend most time prompting (discussing with Claude) are the human-AI interactions. The hardest conceptual problem: when should an AI speak, and when should it stay silent? Too many interventions - annoying. Too few - useless. Also, you know - I don't want to have a "Cassandra" in my house ;-) Each iteration, each corner case is about experience, pain points, real-life situations. There is no way I can list all of them, but I found I can generalize those behaviors that need to be present. Others can use that general knowledge and adjust - or ask real humans for help. Can you see how this helps focus on solutions, surroundings, experience insted of making programs that can be developed (MVP hell)?

Regarding speed, here's also an interesting insight: the complete proactive engine was built and tested in 1 day. Memory, perception, decision making, LLM integration, orchestration, i18n, working examples - 2 days. Other boring things ;-) lasted about 6-7 days. From empty directory to a PoC that listens, thinks, and decides when to speak in around 10 days. Still plenty to do, some bugs, tests, validations, increasing performance (I'm about to buy some computing power from RunPod) but... 10 days... WOW.

And for those who are wondering why "Zelda" - it's named after my favourite character from childhood Nintendo days. Some obsessions don't go away. They just wait for the technology to catch up :-)

Summary

Three different projects. Same pattern underneath all of them.

Ballywood taught me that AI collaboration works best when the human brings precision and the AI brings speed - and that the magic happens in the conversation between the two. A 6-year-old's feature request implemented in 30 minutes. A cloud animation bug fixed by 15 sentences of careful technical writing. The human doesn't become obsolete. The human becomes the interface, a bridge.

PressGarden taught me that AI content generation is an engineering quality problem, not a generation problem. The model writes easily. Everything around the model - sourcing, validation, deduplication, KPIs, knowing when to micromanage and when to let go - that's where the actual work lives.

Zelda taught me that the hardest problems in AI aren't computational. They're relational. When should an AI speak? How do you design trust with a machine that lives in your house? How do you handle the most intimate data responsibly?

None of these problems live inside the model. They all live in the space between the system and the person.

A kid with 30 floppy disks writing emails to Microsoft wasn't just learning to code. He was looking for ways to solve problems that mattered to him - and learning whatever he had to learn to get there.

25 years later, the tools are unrecognizably better. The mission is exactly the same: make people's lives a little better, one solution at a time.

P.S. I'm currently exploring what's next. If your team is solving hard problems at the intersection of AI, UX, and systems thinking - let's talk. I work best where precision matters and humans are still in the loop.

P.P.S. Anthropic Just waving my hand, maybe it will work like with Microsoft