chore: initial commit of vault before dashboard work

raw/notes/Ideas for webinar.md

@@ -0,0 +1,37 @@
+#webinar #ai #ideas
+
+TRON - themed presentation
+
+- not every programmer can be a manager
+- ~~in future programmers will become a separate 1-man business, handling multiple clients~~
+- become your own boss - imagine that you have been split in 2 persons: one is more skillfull that you in terms of PM, the other is less skillfull than you in terms of code.
+- harness is the future. each developer would have his own set of methods and approaches that are not sharable. like company's know how
+- at some point we will just provide access to our harness to do certain job
+
+- connections are everything
+
+- we need not to write waterfalls, as Daniel suggests, but describe problems
+
+- frontend is dead. you can regenerate everything in minutes
+- UX is good enough and this is exactly what most of the clients want
+
+- code is throwaway. we are not looking at asm anymore
+- Integration AI into business
+- AI economy. Online shops are obsolete. - Tell the story about printer
+
+
+Topics:
+- Claude + Obsidian
+- Claude for mortals
+- Become your own boss
+
+Тезисы:
+HR, у вас в контактах есть нужные кандидаты. Вы просто их не видите.(Сделать демо по поиску HR)
+
+
+Идеи для визуализации:
+https://www.youtube.com/watch?v=YjkteijEyzQ
+
+https://youtu.be/_u21l21qTMM?t=194 - слои
+
+https://www.skool.com/ai-automation-network-plus/about - возможно, стоит чекнуть

raw/notes/introduction.md

@@ -0,0 +1,12 @@
+Каждый из нас делает ручной, рутинный труд и даже не осознаёт это.
+
+Мы считаем это нормой и делать по-другому нам кажется неоправданно трудозатратно, менее эффективно или даже глупо. 
+
+Это в природе человека и существует с нами всю историю. Люди выбирают то, что привычнее:
+
+**Чемодан на колёсиках.** Колесо — тысячи лет, чемодан — век, а соединили их только в 1970-м (Бернард Садоу), а удобный вариант с выдвижной ручкой — в 1987-м (Роберт Плат, пилот). До этого миллионы людей просто носили тяжести в руках и считали это нормой.
+
+
+
+IPhone... Apple - это один из якрих представителей, которые использовали "привычнось" в дизайне. Скевоморфизм. Этот стиль использует изображение знакомых предметов для обозначения функции: компас, книга, трубка телефона.
+А такие вещи как кнопка и дискета в качестве символа сохранения уже на столько привычны, что нам тяжело предстравить как может быть по-другому.

raw/notes/my theses.md

@@ -0,0 +1,6 @@
+- AI can become more than just chat box.
+- How AI is able to conquer humanity(or do something useful at all)?
+- How to cure AI amnesia?
+- Would you be able to become your own boss?
+- Why you should treat yourself as a company, not a single person.
+- Programmer is the one who understands, not who writes.

raw/sources/Agentic Engineering, explained by a 10x developer.md

@@ -0,0 +1,265 @@
+# Conclusions
+
+**Source:** https://www.youtube.com/watch?v=FU5_kpTAVDo
+**Title:** Agentic Engineering, explained by a 10x developer
+**Duration:** 42:33
+**Speaker:** Thorsten Ball — founding engineer at AMP (Sourcegraph), author of the "Writing an Interpreter in Go" / "Writing a Compiler in Go" books
+**Interviewer:** David Andre
+
+---
+
+## Core thesis
+
+**The whole shape of software work has changed.** Models are now so capable that the interesting variables are no longer "which model" or "how do I read every line of code", but:
+1. **Where does the information live** that the agent needs?
+2. **How agent-friendly is your codebase / workflow?**
+3. **What do you actually want to build** (not how to build it)?
+
+The winners will "shed weight" — kill features, kill IDE plugins, kill local dev, kill CI-that-repeats-the-agent's-tests — anything that only made sense before agents. **99% of AMP itself is now written by AI.** Slop is a human-taste problem, not an AI problem.
+
+> "You will get a button with which you can spawn a John Carmack that writes the code for you."
+
+---
+
+## AMP's operating principle: stay on the frontier, shed weight
+
+- Bet from day one: **don't optimize for what looks safe today, optimize for the ability to move fast tomorrow.**
+- Could have made a lot of money in 2025 by building "single agent in a VS Code sidebar with enterprise permission system + per-line attribution" — but the whole model would have been obsolete in a year.
+- Instead: aggressive killing of own features on `ampcode.com/news`.
+  - Killed VS Code extension → "who has the editor open anymore?"
+  - Willing to break users out of their comfort zone; some churn, but customers who stay respect the pushing.
+  - Company officially: "AMP Frontier Corporation."
+- **Customer question they get most:** "guys, what's the meta? What model, what prompt?" — because customers are paying for the research decisions, not just the software.
+
+---
+
+## Model choice: stop tweaking, focus on getting stuff done
+
+- Once you have Fable 5 / GPT-5.6 Sol / equivalent, **diminishing returns on which one you pick.**
+- If you're mad your model doesn't use camelCase, **rethink your software engineering**, not the model.
+- The dominant variable in output quality is now **the information you put in**, not the specific model or the level ("medium" vs "high" vs "ultra").
+- Default recommendation: pick a good model, focus on the work. Fiddling with GLM 5.2 vs Fable in your free time is fine as a hobby but not where value comes from.
+
+---
+
+## Kill the backlog
+
+**Old world:** bug reported → put in backlog → weeks later someone decides it's worth doing → estimate → maybe fix.
+
+**New world:** *"Why don't you optimistically spawn these agents and have them parked somewhere, then go through them and look at the bug fixes?"*
+
+You no longer need to estimate whether a bug is worth fixing if the fix is running while you sleep. Backlogs are an artifact of expensive humans.
+
+---
+
+## Kill CI that just re-runs what the agent already ran
+
+- The agent is already in an isolated sandbox.
+- It's already running the tests.
+- Then you push and let CI run the same tests for another 10 minutes?
+- **Rethink from first principles.** A lot of pre-agent process is now waste motion.
+
+---
+
+## Slop comes from humans
+
+- "Most of slop comes from humans not having good product. With AI they can just build trash products faster."
+- AMP internally: Thorsten polled the team on how much code they write by hand. Options were 99%+, 90-99%, and <90%. He didn't even think anyone would be under 80%. One engineer (Camden) said "I still write a bunch by hand." When pushed: "OK, probably 95%."
+- Thorsten's use of AI for the orb icon: had AI generate **15 different versions in different colors** (Braille characters, different styles, 18 palettes). He picked the one he liked. That's "human taste at AI speed" — not slop.
+- Same pattern for AMP news posts: him + Tim + Brad going turn-by-turn in Midjourney, reading Moby Dick, "combining Moby Dick and orb in my head."
+- **Slop = lack of ideas, lack of playfulness, lack of knowing what you want to exist.** Not an AI defect.
+
+---
+
+## Building an AI startup today
+
+Same question, same answer as before AI: **what's the market, who's the customer, how do you serve them, how do you sell?**
+
+- Software as "the thing itself" is less valuable now — code is cheap, open-source contribution graphs are worth almost nothing.
+- The lucky overlap of the last 20-30 years — "the guy who loves Haskell on weekends is also the guy who models the finance backend well" — is disappearing. Fable is good at that stuff now.
+- What senior engineers used to hand-teach in 2-3 years (e.g. the safe multi-step column-drop migration) is now a 30-second model output.
+- So the question shifts up: **what do you want to get done?**
+
+---
+
+## Build for the agent, not the human (a new product philosophy)
+
+- If starting a new product on the frontier: **no human should have to fill out forms.**
+- Anything a human can do on your site, they should be able to have an agent do.
+- Ideally: **bring your own agent** — nobody wants to use your shitty built-in agent.
+
+### The admin panel that dies
+
+Thorsten built a food-ordering app in an "orb" at a local club (menu photo → working app → shared URL, 3 × 5 min iterations).
+
+- The agent also built an admin interface to edit menu prices and spellings.
+- Thorsten: *"I'm never going to open that. I'll just send another photo and say 'fix the pricing.'"*
+- **A lot of admin UI existed only so no code had to change** — now it's easier to just change the code.
+- Same for WordPress-style dashboards: "here's my draft, add this header image, publish, spell-check" — one sentence, no clicking.
+
+---
+
+## The Emacsification of software
+
+He references a blog post about "the Emacsification of software" — Emacs users historically fork plugins, rewrite them for their config, never contribute back.
+
+Same is happening now:
+- Thorsten forked a diff viewer called **hunk**, pointed AMP at it, said: "add Gruvbox dark hard theme, add file-checkoff in sidebar, compile, drop it in `~/bin`." Two minutes of agent time.
+- No reason to upstream — the change is bespoke to him.
+- Prediction: much more of this. Not just individuals — teams and companies will remix mid-sized software (his example: "I want Riverside but audio-only" or "video-only").
+- The blast radius will keep expanding.
+
+---
+
+## Explosion of internal software
+
+- Before: internal software = one Excel file, one wiki page, one hacky script.
+- Now: at his club (20 people), he encoded the ordering process in software in ~2 hours of phone-typing.
+- **When people realize they can do this in companies, it replaces the Excel/wiki/hack layer.**
+- Two variables that will separate winners from losers:
+    1. Knowing how to use agents.
+    2. Having the token budget to do it.
+
+> "You cannot take a programmer who doesn't use AI, they're going to get crushed by a mediocre programmer with AI."
+
+---
+
+## First-principles thinking becomes the top skill
+
+Anti-example from Sunday's club:
+
+- Someone: "Can you build an app so a tablet prints a paper receipt the kitchen picks up?"
+- Thorsten's push-back: *"Why do you need a printer? Why not a second tablet?"*
+- The real skill: seeing the workflow underneath the request. Everyone becomes an architect; the value is **knowing solutions from other industries and having the right idea** for this problem.
+
+---
+
+## Don't compare yourself to the 1%
+
+- Online debates always cite Mitchell Hashimoto (Ghostty) as "AI still isn't good enough for him."
+- Yes — but Mitchell is one of the best programmers alive, working on a GPU-accelerated terminal emulator. That's not most software.
+- Most software is CRUD apps, "MySQL and something-something." **Agents handle it fine.**
+
+---
+
+## AMP's setup — what it looks like today
+
+- **Install:** `ampcode.com` as a PWA (Thorsten thinks the acronym PWA is what's blocking mass adoption of the install flow).
+- **Model dial:** low / medium / high / ultra, each level maps to a model + sub-agent choice.
+    - Sub-agent named **"Oracle"** (reviewer, gives advice).
+    - Sub-agent named **"Painter"** (generates images).
+    - Meta-agent named **"Puck"** (can control other agents, spawn orbs, message them, run flows).
+- **Default:** medium (Sol at balanced level) — no need for Fable in the mix unless the task warrants it.
+- **Multi-model:** GPT models, Anthropic models, GLM models all supported.
+
+---
+
+## Orbs — the multiplayer, headless-sandbox unit of work
+
+An **orb** = a remote sandbox tied to one conversation:
+
+- Sandbox goes to sleep when idle, wakes on typing.
+- Streams to phone, laptop, TUI — same conversation, any device.
+- **One URL packages: the thread + the agent + the computation + the diff.**
+- Share the URL → your teammate opens the orb and takes over.
+- Multiplayer is landing (agent-to-agent communication went live "last Friday").
+
+### Why orbs kill the "cloud IDE" objections from 10 years ago
+
+Old objections to cloud IDEs (Cloud9 etc.): latency, key bindings, "I can't SSH in," missing language servers.
+
+Now: **who cares about latency when you're waiting for tokens/sec anyway?** Nobody uses language servers, editors, key bindings the same way. The whole objection stack collapsed.
+
+### Async by default
+
+- Delegate a task → orb takes 16 minutes → doesn't matter, you're doing something else.
+- Live example from the interview: Twitter user asked "can orbs run Rust cross-platform desktop framework?" Thorsten prompted Puck → Puck spawned an orb → 16 minutes later, screenshot proof.
+- Quinn's tweet (AMP CEO): *"You're async anyway — so ask the agent to give you proof."* Screenshots, benchmarks, dark-mode + light-mode variants, 50 tests in parallel.
+
+---
+
+## How Thorsten prompts
+
+- **No custom slash commands, no skills, no MCP servers.**
+- The one thing that matters: **where does the agent get its information from?**
+
+Agents have two information sources:
+1. **Training data** — a "senior engineer who's seen it all," but lossy and possibly stale.
+2. **The context window** — everything you tell it, plus what the codebase and `AGENTS.md` provide.
+
+If your prompt / codebase / AGENTS.md is thin, the model can't turn a bad prompt into a good one.
+
+### Prompt structure Thorsten uses (paraphrased from the "port Puck to CLI" example)
+
+- **Set the standard:** "look at how it's implemented in web UI."
+- **State intent:** "I want to port this to our CLI."
+- **Riff on the design:** "have a `puck open` command that uses the command palette; show up in the sidebar; maybe a `puck clear`; think about whether we need a new TUI modality."
+- **Explicit process:** "research how it's implemented, research how we communicate what it does (look at the news post), document how it works, sit down and think, compile what you learned, then come up with a good idea."
+- **Sub-agent economics:** "use sub-agents for implementation — Fable is expensive, it scares me. So use GPT models for the implementation. Then present the results."
+
+Key phrase: *"This is how I would talk to a senior engineer. This is the Slack message I'd send."*
+
+---
+
+## Concrete velocity change at AMP
+
+- "Shipping velocity went up" in the past 4 weeks.
+- Designer Tim: "never fixed so many paper cuts as in the last two weeks" — screenshot a bug → send to AMP → orb comes back with fix → spot check → merge.
+- Agent-to-agent: if the current agent says "I found another bug", Thorsten replies "launch another orb to fix it" — spawns a new checkout, new branch, new agent, in parallel.
+
+---
+
+## Live demo shipped during the interview
+
+- Iterated on Puck orb variations, added them to the site, updated copy.
+- Asked for a screenshot for verification.
+- **Shipped to production during the podcast**, live.
+
+---
+
+## Predictions (his end-of-interview list)
+
+1. **Local dev effort is going away** — orbs / remote sandboxes replace it.
+2. **The distinction between models will matter less** — "John Carmack on a button."
+3. **Unclear what software will survive** — remixability + custom versions per user erode the moat of general-purpose SaaS.
+4. **Infra margins get eaten** — 15+ sandbox providers already racing to zero. That's not sustainable either.
+5. **We are all moving up a level of abstraction** — a lot to build; nobody yet knows the shape.
+
+---
+
+## Cross-cutting principles
+
+- **Optimize for shedding weight**, not for feature accumulation.
+- **Information > tuning.** What's in the context window matters more than which model is picked.
+- **Talk to the model like you'd Slack a senior engineer.** Standard, intent, riff, process, constraints.
+- **Async by default.** Ask for proof (screenshots, benchmarks, dark/light) since you're waiting anyway.
+- **Kill the human-only artifacts** — backlogs, admin panels, VS Code extensions, redundant CI.
+- **Package thread + agent + computation + diff in one URL.** Sharable, multiplayer, resumable.
+- **First-principles thinking > technical detail knowledge.** Everyone is an architect.
+- **99% AI-written code is compatible with high taste.** Taste is human input, not human keystrokes.
+- **Don't benchmark yourself against Mitchell Hashimoto.** Most software isn't Ghostty.
+
+---
+
+## Actionable takeaways
+
+- [ ] Pick one good model and stop tuning between them for the rest of the week
+- [ ] Delete one workflow that only made sense pre-agents (backlog triage, CI-repeat-of-agent-tests, VS Code extension you don't use)
+- [ ] Try running one agent in a **remote sandbox** rather than locally — see what your objection actually was
+- [ ] Instead of a form/admin panel, prompt the agent directly on the codebase (Thorsten's food-app example)
+- [ ] For your next non-trivial prompt, spend 3× longer on **context / references / standards** and no time on model choice
+- [ ] Ask an agent for **10-15 variations** of a design decision instead of "the answer" — pick with human taste
+- [ ] Set up async parallelism: "launch another orb / branch to fix that side-bug while you continue"
+- [ ] Ask agents for **screenshots, benchmarks, dark+light-mode proofs** as verification — you're async anyway
+- [ ] Try one "Emacs-style" remix: fork some OSS tool → have the agent add your bespoke features → run it locally, never upstream
+- [ ] Draft a company-internal doc titled "Software Is Dead — Now What?" and be honest about which of your processes only survive because humans used to be the bottleneck
+
+---
+
+## Who this is for
+
+- Engineers still hand-coding at 2024-era velocity, wondering what actually changed
+- Founders / EMs deciding whether to bet on agent-native tooling vs incremental IDE plugins
+- Product people asking "should we build for humans or agents?" — the answer is both, but the bias should shift
+- Anyone still deeply invested in local dev environments, backlogs, or IDE workflows and wondering what's next
+- Anyone starting an AI product now and wondering what the actual moat becomes

raw/sources/Everything we knew about software has changed.md

@@ -0,0 +1,73 @@
+# Conclusions — Everything we knew about software has changed
+
+**Source:** https://youtu.be/xUnRQ9vLXxo
+**Title:** Everything we knew about software has changed — Theo Browne, @t3dotgg
+**Duration:** 16:01
+**Speaker:** Theo Browne (t3.gg) at AIE
+
+---
+
+## Main thesis
+
+Models are improving faster than developers can. You cannot keep pace by "getting better" at your craft — you have to **go bigger** and, more precisely, **think wider**. That means shedding a whole generation of developer identity (tools, languages, sunk-cost attachment to code) and letting yourself pick ideas that feel embarrassingly ambitious. If your idea doesn't feel stupid, it isn't big enough.
+
+## The three model eras (why capability just jumped again)
+
+Theo frames recent model releases as qualitatively distinct eras rather than incremental upgrades:
+
+| Era | Representative model | What it unlocked |
+|---|---|---|
+| **Tool-call era** | Sonnet 3.5 | First model to do tool calls consistently and reliably inside a real codebase — good enough for day-to-day coding work. |
+| **Long-running-task era** | Opus 4.5 | Multi-hour tasks without losing the plot. Can write code, run it, test it, and drive it to a good state. This is where his "AI psychosis" started (Nov–Dec 2024). |
+| **Orchestration era** | Mythos / Fable | Doesn't just understand your codebase — understands **itself**. Spawns sub-models, breaks work up, verifies afterwards. You don't need a "software factory" of custom tooling; a prompt is enough. |
+
+Practical implication: a task that only takes Opus-4.5-shaped work will *not feel any different* on Mythos. You only see the gain if you push scope further. His old Jira tickets could all be trivially solved by Opus 4.5 — none of them would exercise Mythos.
+
+## Get over yourself — the psychological blockers
+
+Long-tenured engineers carry baggage that is now actively holding them back. Theo's iOS analogy: skeuomorphic iOS 6 looked "like a compass" because Apple was still convincing you the iPhone could replace physical objects. iOS 7 dropped that pretense and became more useful precisely because it stopped imitating the past.
+
+Developers are in their skeuomorphic phase right now. Symptoms:
+
+- **Terminal fetishism.** "Natural language has no place in a terminal, but we pretend it does because the terminal's familiar."
+- **Language-as-identity.** Both juniors and seniors reduce people to "he writes JavaScript." The framework/language you pick matters far less than it used to, and mattered less than we thought even before.
+- **Ceremonial git norms.** Why *can't* we commit `.env` files? Because git was built for one thing and then colonised our brains. Ask whether each convention is right or just old.
+- **Sunk-cost merges.** "Guilt-merging" a PR because someone spent a week on it — even when the right answer is to delete and reset. One under-appreciated gift of agents: no guilt when you throw the work away.
+
+## The tier shift — every project category moved down one slot
+
+Theo lays out the tiers he used to think in, and how they've shifted **exactly one level** after the recent model jumps:
+
+| Old category (≈2024) | Example he built | New category (today) |
+|---|---|---|
+| Side project | Reddit meme scraper | ↓ shifts down |
+| Startup | Ping / "Zoom for streamers" (YC) | Side project |
+| Too big | Full-stack cloud (Vercel + auth + DB) | Startup |
+| — | — | **New "too big" — unknown** |
+
+Below "side project" a new tier appears that didn't exist before:
+
+- **"G-brain tier" = a markdown file.** Executable prose. He replaced a whole PR-triage service with a markdown file piped to Codex / Claude on a 9 AM cron — by 9:15 it has read four repos, prioritised the day's work, and shipped a static HTML file to S3. Many products at AI conferences right now could just be a markdown file.
+
+And the top of the ladder is genuinely open: he admits he no longer knows what "too big" means. Training your own model? Your own OS? Competing head-on with npm? All are on the table. That uncertainty is the point — you find the new ceiling by pushing past what feels reasonable.
+
+## Think **wider**, not just bigger
+
+The reframe: any product has **breadth** (range of areas it covers) and **depth** (features per area). Old rule: you couldn't out-breadth an incumbent, so you picked a vertical and went deep.
+
+- **Vercel vs AWS.** Vercel will never match AWS's breadth; it goes deeper in frontend-leaning full-stack. If you're a frontend dev not on Vercel today, you feel the pain — even the agents prefer it. This was the old, correct playbook.
+- **What changed.** Breadth is now viable for small teams. You will not build something as reliable as RDS in a day — but you can bolt a serviceable database platform into your product in a day or two of prompting. Cover enough of the spectrum that users can **start** using it.
+- **Let users close the gap.** Architect so users can build the features you don't ship. Slack accidentally became the platform half of everyone's agents run in — not because Slack is good ("Slack sucks") but because its shape lets users extend it via the Slackbot API. Being the right shape beats being feature-complete.
+
+## Actionable takeaways
+
+- **Match your ambition to the model.** If your work would have made sense on Opus 4.5, you are not exercising Mythos. Pick tasks that *require* the new capability — orchestration, multi-agent spawning, self-verifying flows — or you'll conclude the models "aren't that much better."
+- **Try replacing a service with a markdown file.** Pick one internal automation, describe it as prose, cron it into Codex/Claude, ship its output somewhere. See how far it goes.
+- **Audit your developer identity.** List the tools/rules you cling to (terminal, language, framework, "we don't commit env files"). For each, ask: right, or just habit?
+- **Kill code without guilt.** Reset instead of guilt-merging. Especially easier when the author is an agent.
+- **Expand breadth deliberately.** Rather than adding the 27th feature to the vertical you own, add a shallow layer in an adjacent vertical. Make it extensible so users fill the gaps.
+- **Pick an idea that feels stupid.** Compete with Slack. Build a native OS. Challenge Salesforce. If nothing about the idea makes you flinch, it isn't big enough for the current models.
+
+## Who this is for
+
+Senior developers (10+ years) who feel the models are "impressive but not that useful for what I do" — Theo's argument is that this is a scoping problem on your side, not a capability ceiling on the model's side. Also useful for founders sizing a startup: what looked like a solo-founder impossibility 12 months ago is a plausible side project this quarter.

raw/sources/In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible.md

@@ -0,0 +1,170 @@
+#ai #productivity #video #webinar
+
+# Conclusions
+
+**Source:** https://www.youtube.com/watch?v=YfRkj9kmQf0
+**Title:** Ex-Amazon AI Leader: In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible
+**Guest:** Allie Miller (ex-Amazon AI leader; advises OpenAI / Google / Anthropic and Fortune 500s)
+**Duration:** 59:16
+
+---
+
+## Central thesis
+
+The compounding advantage of AI is no longer about *which prompt you write* — it's about whether you've built a **personal AI operating system**: persistent context documents, reusable skills, and proactive workflows that run while you sleep. The gap between someone who invests one focused week into setting this up and someone who keeps using AI as a chat-box will, in 12 months, be irreversible.
+
+Allie's own setup: **36 proactive workflows, ~28 master agents, ~100 total agents running on schedules.** Her productivity gain vs. two years ago: **2x–10x depending on the task.**
+
+---
+
+## The mindset shift (the actual unlock)
+
+| Old framing | New framing |
+|---|---|
+| AI is an intern | AI is a **first-class teammate** (Allie: "what intern has PhD-level intelligence and has read the entire internet?") |
+| AI is a tool I open when I have a question | AI is an **operating system** running on my behalf 24/7 |
+| I write a prompt | I delegate work to a **scheduled agent** that completes and reports back |
+| Prompt engineering | Context engineering — feeding the system who you are |
+
+The two camps in the Kenya entrepreneur study (some 10x'd their business with ChatGPT, some ran it into the ground) did **not** differ in expertise. They differed in mindset: the losers offloaded judgment; the winners used AI to **challenge and augment** their own thinking while keeping agency.
+
+---
+
+## The 4 Claude surfaces — pick the right one for the task
+
+| Surface | What it's best at | Action capability |
+|---|---|---|
+| **Claude (web chat)** | Q&A, projects, simple connectors (Notion, Gmail) | Low — retrieves, doesn't really act |
+| **Claude Cowork** | Business/professional agentic work, point-at-local-files, generate Google Docs | Medium |
+| **Claude Code** | Maximum control, customization, software-grade workflows, scheduled tasks | High |
+| **Claude Chrome extension** | Drives your browser tab (e.g. building a collage on Walgreens.com) | Browser-scoped |
+
+Skills built in one transfer to the others — and to ChatGPT, Perplexity, Gemini. They're just folders with markdown.
+
+---
+
+## The "skill" abstraction (toolbox metaphor)
+
+A **skill** is a folder with one MD file describing *what to do* + optional resources (examples, CSVs, brand guidelines, tool access). Claude has a built-in **skill creator** skill that can build new skills for you.
+
+Examples of skills every person should have:
+- **Tone-of-voice** skill (per channel: LinkedIn voice ≠ X voice)
+- **Brand guidelines** skill
+- **Anti-AI-language** skill (strips AI tells from any output)
+- **Role-specific** skills (PR, marketing, customer support, finance, legal) — Claude Cowork already ships pre-built plugins for many of these
+
+Key behavior: skills compose. Your LinkedIn-voice skill can call your anti-AI-language skill. Agents share skills with other agents.
+
+---
+
+## The 3 foundation documents to build first ("context hack")
+
+Spend **one hour** with Claude asking you questions while it builds these. Allie's team did this together on a muted Zoom call:
+
+| Document | What goes in it | Why it matters |
+|---|---|---|
+| **Personal Constitution** | Core values, vibes, working style, "what makes me tick" — nothing time-bound | Used by Silicon Valley teams to onboard each other; every future AI interaction is grounded in *who you are* |
+| **2026 Goals doc** | Annual → quarterly → monthly → weekly, habits to build/kill, specific inputs/outputs | Every "should I do X?" decision is now checkable against your real North Star |
+| **Core Business Strategy doc** | Who you serve, who you don't, value prop, *plus the off-website context* (failed launches, why you live where you live, what you've tried) | Public site = generic; this doc = the nuance no AI can guess |
+
+Once these three exist, every future ask becomes ~50% "Allie zone" output instead of generic. From there, layer client-specific context docs (Allie keeps one per retainer client) and templates.
+
+---
+
+## How to actually prompt (the new minimum)
+
+**"Just complain."** All humans know how to complain — and complaint is rich context. Allie's example: ramble for 1–10 minutes about being stressed before client calls, hating that you forget the umbrella, struggling to find deep work time. Claude will come back proposing: a proactive client-prep skill, a meeting-blocker, a weather-aware morning briefing.
+
+Two universal patterns to remember:
+1. **"Ask me questions before doing this."** Either say it directly, or invoke the built-in `ask user questions` skill. Claude interviews you, plans, then executes.
+2. **Push back when it refuses.** "Sorry I can't build a skill" → "Yes you can, two smart people just told me you can." Emotional fortitude still required.
+
+---
+
+## Proactive workflows — what "AI working while you sleep" actually looks like
+
+Two of Allie's real scheduled agents:
+
+| When | What it produces |
+|---|---|
+| Every morning (~6 AM) | **Morning Brief** Word doc: top 3 industry stories (ranked by what'll impress your boss), most-talked-about AI stories, weather + clothing recommendation, 3 fun local events for the next 4 days, kickoff notes for every meeting on today's calendar — with the option to reply with a keyword to trigger an asset-generation sub-agent |
+| Every Friday morning | **Email recap**: all urgent emails not yet replied to, ranked by urgency, with drafted replies, delegation options, and follow-up reminders |
+
+Scheduling exists natively in Claude Code, Claude Cowork, and Codex.
+
+---
+
+## The 4-tier model of AI work (Allie's framework)
+
+| Level | What it does | Example |
+|---|---|---|
+| **Microtask** | One-shot help inside a single task | "Summarize this paragraph" |
+| **Companion** | Conversational thinking partner | Brainstorming over a chat |
+| **Delegate** | Takes assigned work and returns output to *you* | The morning brief; client recap drafts |
+| **Teammate** | Acts on behalf of the whole **team or system** | Reads everyone's Jira, monitors a commercial real-estate build, prepares team-wide deliverables |
+
+The biggest enterprise problem right now: super-users get 3x–5x gains and **hoard** that knowledge because it makes them look elite. Treating AI as a *team* asset breaks the hoarding pattern.
+
+---
+
+## How to know when to trust AI
+
+| Situation | Trust calibration |
+|---|---|
+| Inside your field of expertise | High — you can spot BS instantly |
+| Outside your expertise (quantum physics, medical, legal at scale) | Low — pair with a human expert; some people are "inventing new sciences" that sound plausible and aren't |
+| Legal/contracts | Run through AI to first-pass, then a 15-minute human lawyer review (down from 2 hours). Cautionary tale: founder fired a contractor based on ChatGPT-advised reading of a contract → sued → owes more |
+| Anything with high stakes | Ground the model with retrieval (your prior contracts, your accepted/rejected decisions, browsed web) — don't rely on raw weights |
+
+**Meta-skill of the AI era: knowing what good looks like.** You don't need to be able to do the graphic design to know whether an ad is good. Honing taste — by going to conferences, reading source research (not just AI summaries), and questioning your own assumptions — is now more valuable than execution skill.
+
+---
+
+## What changes in 12 months (Allie's prediction)
+
+1. **Self-learning models** — not the current "memory file" trick (which is just retrieval-augmented context). Actual weight updates triggered by environmental signal. Example: Claude watches Allie's hiring calls for 5 months, sees she picked the New York candidate over the Nashville one, updates its decision framework to *"she's currently favoring higher-risk, higher-payoff calls."*
+2. **Market of one** — every person has their own AI OS; every website you visit is rendered for *you* in real time (tools like Flint already do this). Nike shows Allie the dark-green women's shoe because it knows her.
+3. **Agent-to-agent communication** — already starting. People email "Hey Allie's agent…" because they know an agent reads her inbox first. Proxy-to-proxy negotiation will plan podcasts, schedule meetings, draft the first 5 questions.
+
+Side effect: **personal human relationships become more valuable**, not less, because everything else gets mediated by proxies.
+
+---
+
+## What happens to teams and income
+
+Two paths companies will take:
+
+| Path A: Headcount cut | Path B: Output multiplication |
+|---|---|
+| 8 social media managers → 2 | Keep the 8, redirect 6 onto things you never had bandwidth for: YouTube launch, 70-language audio, ManyChat in Instagram DMs, second-brain maintenance |
+
+Allie's prediction: many teams will go path B and **5x–10x their output** rather than shrink. Her own team example: the person who used to handle guest outreach now also runs PR and Generative Engine Optimization (GEO) — same person, 3x the surface area.
+
+For income: be honest that some people are taking a **short-term step back this year** to pivot fully into AI, and that's okay. The long-term play is the combination of **AI fluency + diversified income + intelligent frugality** (not bare-bones). Don't over-optimize a single year.
+
+---
+
+## Cross-cutting principles
+
+- **Investment, not cost.** People say "it takes so much time to make all these context docs." It's one hour for ~3 hours/week saved every week thereafter.
+- **Modularity beats one-off prompts.** Skills > prompts. Folders > giant pasted blocks.
+- **Files are portable.** Markdown skills migrate from Claude → Perplexity → Gemini in seconds. Claude just shipped an import/export feature.
+- **Schedule the *asking*, not just the task.** If you check competitor news every morning, the *act of asking* should be automated, not just the search itself.
+- **Curiosity > expertise.** Kids and the "high-agency" mindset beat domain knowledge for getting value out of these tools.
+
+---
+
+## Actionable takeaways — what to do this week
+
+1. **Carve out 1 hour.** Solo or as a team Zoom. Build the three foundation docs (Personal Constitution, Goals, Business Strategy) by letting Claude interview you via the `ask user questions` skill.
+2. **Set up one proactive workflow.** Pick the most-repeated annoyance in your day (morning brief, weekly email recap, competitor watch). Schedule it.
+3. **Build two reusable skills.** Tone-of-voice and brand-guidelines are the universal starters.
+4. **Pick one core AI tool for now** (ChatGPT, Claude, or Gemini) — and **commit to testing its agentic surface** (Codex / Claude Code / Cowork). Don't stay only in the chat UI.
+5. **Complain to Claude.** Next time you catch yourself frustrated about a recurring task, say it out loud to Claude and let it propose the skill.
+6. **Decide: path A or path B for your team.** If you're keeping headcount, list the 3 new revenue lines or surfaces those people will now own.
+
+---
+
+## The gap, in one sentence
+
+In 12 months, the person who set up their AI OS this week will not just be **more productive** — they will have **less fear** of every new release, because each new capability will slot into a system they already understand. The person who didn't will keep meeting AI as a stranger, every time.

raw/sources/Larysa interview.md

@@ -0,0 +1,49 @@
+## Executive summary
+This is a scoping interview for an upcoming webinar on practical AI use, in which the host (SPEAKER_00) probes a power user (SPEAKER_01, "Larysa") for the concrete problems she hits with Claude. The dominant pain points are not hallucination but structural: agents have no useful persistent **memory**, and Claude confidently starts tasks against **integrations that turn out to be unavailable** for her account type — both burning time and tokens. The host's thesis is that the fix is to stop tool-hopping and instead build one consolidated, project-scoped agent "operating system," and to constrain prompts with **skills** rather than expecting a whole project from one or two requests.
+
+## Who's who
+- **SPEAKER_00** → The webinar host and AI power user. Advanced Claude Code user who has built a consolidated multi-agent workspace (his "Inspectron" projects) and an interview-analysis system that diarizes speakers and auto-writes conclusions — the same tool that produced this transcript. Stance: strongly pro-Claude, pragmatic, skeptical of one-shot "build everything" demos.
+- **SPEAKER_01 ("Larysa")** → A technical BA/PM and former mobile developer. Hands-on Claude user: opens pull requests, wires Claude to ClickUp (a Jira analog) and Figma, builds clickable prototypes, writes user stories and tests. Stance: enthusiastic but worn down by memory loss and dead-end integrations.
+
+## Key themes
+
+**Agent memory is the central frustration.** Larysa's core problem is that Claude doesn't carry context between sessions — she explains something one day and it's gone the next, so she re-pays in time and tokens. The host agrees bluntly that memory, as implemented, is a net negative.
+> "Memory is the worst thing agents have — it gives no benefit and confuses users to hell. Why even go there? … The memory exists, but the way it's implemented, it'd be better if it didn't."
+
+**Integrations overpromise, then dead-end.** Claude accepts a task and starts working, only to discover mid-way that a connector isn't implemented or isn't available for her (private vs. corporate) account — after she's already sunk half an hour. This is her example of a Teams bot that would watch a work chat and auto-create ClickUp tasks.
+> "What it recommended is available not for private accounts, only for corporate ones — and to get there with it I'd already burned half an hour. That's not hallucination exactly… it just first goes looking for what you don't have. I don't know how to fight this."
+
+**Build one system; stop tool-hopping.** The host's main pitch: assemble a personal "operating system" where all your project agents live together and can talk to each other, instead of spinning up Claude in separate folders. He claims it freed up mental overhead he didn't know he was spending.
+> "You build yourself an operating system where you have everything in one place… When I built this thing, my life just split into before and after."
+
+**Leave less room for imagination.** Under-specified prompts let Claude drift, and the drift causes large collateral damage; standardized procedures (skills) are the constraint. This is his explicit critique of demos that ask Claude to build a whole project in one or two requests.
+> "The more room for imagination, the more it will exploit it… it finds a way to understand something differently than you imagined, and it just gets carried away — you won't even notice."
+
+**Model choice and how far to trust coding AI.** The host runs Claude 4.7 in production, finding 4.8 "too proactive," and argues coding with AI is no longer elite or unsafe — with two exceptions.
+> "I use Claude 4.7 — it does exactly what I need, without the flights of fancy 4.8 has… Code isn't something elite anymore. From 4.6 on, the code is safe enough — though authorization and payments I still wouldn't trust to Claude."
+
+**Automated interview analysis.** Both independently landed on recording interviews and processing them, but the host's system adds speaker diarization plus role inference from context, which he says a plain GPT transcription flow cannot do — it only guesses who spoke.
+> "Instead of sitting and taking notes, you just screen-record, then run it through the AI… an hour-long interview took about 10–11 minutes. It splits by voice and pulls the role — Speaker 0, HR Equity Lead; Speaker 2, Senior Programmer — from the conversation itself."
+
+## Conclusions
+- The real friction with agentic AI here is structural, not accuracy: (1) no durable memory, (2) integrations that appear available but aren't for the user's account/tooling, and (3) over-eager drift on loosely specified tasks.
+- **Skills** are the host's recommended remedy for the memory and repeatable-procedure problems, and are the one topic he commits to covering for Larysa in the webinar.
+- Teams-based automation is effectively a dead end (Microsoft exposes no good external API); Slack has first-class Claude support from Anthropic, but that requires a paid seat she isn't given.
+- A single consolidated workspace of project-scoped agents — with completion notifications — beats juggling separate tools, both for output and for reduced mental load.
+- AI-assisted coding is treated as production-ready as of Claude 4.6/4.7, with authorization and payment logic as the deliberate carve-outs.
+- Both participants converged on automating interview/meeting analysis; diarization plus role inference is the differentiator over transcribe-then-summarize.
+
+## Takeaways
+- Use skills for anything repeatable to work around agent memory limits, rather than re-explaining context each session.
+- Verify integration and account requirements up front (connector exists? private vs. corporate? paid Figma/Slack?) before letting Claude spend time and tokens on it.
+- Prefer browser/web testing over emulator testing with Claude — the emulator got badly stuck.
+- Constrain prompts and don't expect a finished project from one or two requests; leaving room for "imagination" invites drift.
+- Keep authorization and payment code out of Claude's hands.
+- Consolidate into one agent workspace with completion signals instead of tool-hopping across folders and apps.
+- Default to Claude 4.7 for controllable work; only reach for a more imaginative model when the task genuinely needs it.
+
+## Open questions
+- How to reliably handle integrations Claude recommends that aren't actually available for the user's account type — left explicitly unresolved ("I don't know how to fight this").
+- Whether a Teams-triggered auto-task bot is feasible at all, given Microsoft's lack of usable APIs.
+- How to get full (editable) Figma project access without a personal paid account.
+- How to structure and schedule the webinar itself — deferred to a follow-up with Yulia.

raw/sources/Nina interview.md

@@ -0,0 +1,50 @@
+## Executive summary
+Eugene is shaping an internal webinar around one thesis: non-programmers can and should build their own small AI tools, because the old belief that "software is slow and expensive" is now false. A one-button local tool he built — record → diarize → transcribe → structured summary — already replaces hours of manual write-up, and Nina (an HR recruiter) confirms the demand with concrete pain points: job descriptions, interview transcripts, and candidate summaries. Both agree the real blocker to adoption is friction, not willingness — colleagues would use these tools "if it were simple."
+
+## Who's who
+- **SPEAKER_00 → Eugene ("Женя")** — senior software engineer (20+ years, ~20 commercial), works at Inspectron on Edge Compute / IoT; author and presenter of the AI webinar; heavy Claude user; evangelist for personal AI tooling ("harnesses") and the idea that "every person becomes a business."
+- **SPEAKER_01 → Nina** — HR/recruiter at Virtido; ultra-trail runner (50+ km); among the most AI-forward recruiters on her team; uses paid ChatGPT, LinkedIn Recruiter, and Manatal (ATS). Enthusiastic practical adopter and supportive foil who supplies the real-world use cases.
+
+## Key themes
+
+**AI is a multiplier, and "it makes mistakes" is a weak objection.** Both frame AI as amplifying human work rather than replacing judgment, and both bat away the reliability complaint by comparing it to human error rates.
+> "AI is a multiplier — it doesn't cancel the brain, it just helps the brain do the work it already has faster and better."
+
+**For recruiters, the transcript matters more than the AI summary.** Nina's biggest pain is interview write-ups; note-taking during a call wrecks the conversation and memory fails — especially on cross-timezone calls at 5 a.m. Automatic transcription is the part that actually changes the work.
+> "This transcript is honestly the most important thing. Because when you take notes yourself while talking to a person, it's useless — I don't concentrate on the conversation, I'm afraid I didn't finish writing down his previous sentence."
+
+**Build your own tools — the "software is slow and expensive" belief is dead.** The webinar's central pitch: most routine-task tools you can now create yourself, and running locally on a subscription removes cost, licensing, and security concerns.
+> "Most of these tools you can build yourself… humanity still carries this outdated belief that software is slow, that software is expensive. No."
+
+**Agents plus a real browser beat paid sourcing tools.** Eugene demos Claude Code driving a live browser to source candidates/companies in the background — a practical, cheaper end-run around LinkedIn Sales Navigator, with anti-bot risk at high volume.
+> "Find me companies doing Computer Vision, find the most senior reachable contact, save the link to their profile — but only companies under 200 people. And it works in the background."
+
+**Skills turn personal expertise into a transferable, packageable asset.** Do the task through AI, then freeze it into a "skill" — plain text zipped into a folder — that a brand-new hire can run to produce comparable output, cutting onboarding and spreading responsibility.
+> "'Create a skill for this.' After that you have a folder you can zip up and hand over… and a person with not even a third of your HR experience can deliver a decent result."
+
+**The payoff is lower cognitive load, not just more output.** Nina could go from 5 to 25 candidates a day, but the deeper win both land on is freeing mental capacity for higher-value work.
+> "Even if your output doesn't change, your cognitive load changes — your life overall gets better." / "More creative brain power."
+
+## Conclusions
+- The webinar thesis holds up: ordinary users have real, repetitive problems (JDs, interview write-ups, LinkedIn outreach) that small AI tools solve **today**, not eventually.
+- Adoption is blocked by friction, not resistance. Nina's colleagues aren't opposed — they lack a simple, all-in-one path (and not all have paid GPT). "They'd use it if it just transcribed everything for them."
+- Local + subscription beats API/SaaS for this class of tool: no per-call cost, no license violation, no login/security surface to worry about.
+- Human review stays essential, but the bar shifts — from "redo the AI's work" to "did I feed it the right inputs" (e.g., don't leak a client name into a prompt).
+- Skills are the real leverage and a de-risking tool: package once, hand off, and take a vacation without being on-call — though Eugene and Sebastian disagree on whether skills are personal IP or employer work product.
+
+## Takeaways
+- **The tool:** one red button → record → diarize + transcribe + analyze → structured report (who's who, key themes, conclusions, takeaways, open questions). ~10 minutes to process 1 hour of audio, locally on a GPU, on a Claude subscription.
+- **Don't "teach the AI" abstractly** — do your real task through it, watch the result, correct it, then freeze that into a reusable skill.
+- **Organize by project/agent**, not one catch-all chat — one responsible agent per project; Eugene ran 7 in parallel without losing track.
+- **Knowledge base (Karpathy-style, via Obsidian):** ingest sources, query, and let synthesized answers auto-feed back into the base. Eugene plans to share this file as a post-webinar "gift" attendees can try the same day.
+- **Recruiting sourcing** via Claude Code on a live browser (e.g., Computer-Vision companies <200 people, Dutch region, top contact + link) — but watch anti-bot patterns at team volume.
+- **Multilingual output** (English/German/Ukrainian) is a genuine unlock for Nina.
+- **Consent first:** tell candidates you're recording/transcribing before the call.
+- **Webinar:** first one in English, titled *"From a chatbox to your own operating system."* Keep it aimed at non-programmers, not another dev talk.
+
+## Open questions
+- How to bridge Eugene's programmer-grade demos to a non-programmer's actual workflow — he admits the simple examples "hang in a vacuum" with no clear on-ramp.
+- Can the transcribe→summarize tool plug into **Manatal** (and sync across recruiters, e.g., via git) rather than only LinkedIn?
+- Will LinkedIn flag automated browsing at HR-team volume? Eugene hasn't hit limits but doesn't know the threshold.
+- Are skills "intellectual property" you own, or work product owned by the employer — unresolved with Sebastian.
+- Larysa (now in project management) hasn't been interviewed yet — her PM use cases remain to be gathered.

raw/sources/Webinar Plan - From Chat Box to Your Own OS.md

@@ -0,0 +1,182 @@
+#webinar #ai #plan
+
+# Webinar Plan — From Chat Box to Your Own OS
+
+> How regular people (non-engineers) can benefit from using Claude Desktop as their daily assistant — and how it stops being an app you open and becomes **an operating system fine-tuned for you.**
+
+**Audience:** Business professionals / knowledge workers (managers, marketers, consultants, HR, analysts)
+**Format:** Short inspire talk — **~30 min + Q&A**
+**Goal:** Move the audience along one perspective shift — from "a chat box I open" → "a teammate that works for me" → **"a personal operating system fine-tuned to how *I* work."** No coding required.
+**Language:** English
+**Structure:** The **Evolution of LLMs is the spine of the entire talk.** We tease the destination up front, then walk the timeline from 2023 forward. Every step adds one capability (with an animation showing *what it now lets you do*) and moves the human–AI relationship one rung — ending at a personal OS. Mindset shift, Claude Desktop, and the demo all hang off steps of the journey.
+
+> **The through-line:** an app you *open* (a stranger) → a **doer** → it's **yours** → a real **teammate** → it **knows you** → an **always-on OS** → **your own OS, fine-tuned to you.**
+
+> **Animation note:** Each evolution step gets a short animation showing the new capability. **Not building these now** — `[ANIMATION]` marks where they go.
+
+---
+
+## The Arc at a Glance
+
+| # | Segment | Time | Purpose |
+|---|---|---|---|
+| 1 | Cold open — the teaser | 3 min | Where everyone lives (2023) → flash-forward to the destination → "but let's see how we get there" |
+| 2 | **The Journey: Evolution of LLMs** (the spine) | ~16 min | Six stations; each adds a capability `[ANIMATION]` and moves the relationship one rung |
+| 3 | Arrival — Insights Collector demo | 5 min | Today's reality: the teased destination, in full |
+| 4 | Next — an OS fine-tuned to *you* | 2 min | Lift beyond today: it learns you; the "market of one" |
+| 5 | Do this tonight | 3 min | Walk in a week what took the industry three years |
+| 6 | Close | 1 min | Callback + the irreversible-gap line |
+| — | Q&A | — | — |
+
+**Total content: ~30 min.**
+
+---
+
+## 1. Cold open — the teaser (3 min)
+
+*Tease the whole journey: start where everyone already is, flash-forward to where we're going, then pull back.*
+
+0. **Entry speech + boot-up (the cold open).** A short spoken intro (who you are, what this is, ~30–60s) — *then* "power on the operating system." Run the **boot-sequence slide** (`mockups/start-boot.html`): power button → CRT flash → themed Linux boot log whose modules foreshadow the entire talk (`chatbox.ko` → `react_agent` → `tool-calls` → `skills-curator` → **`reached target Your-Own-OS`**) → the title reveals. This *is* the title moment and locks in the game/OS frame from second one.
+
+1. **Start in 2023 — the chat box.** The familiar starting point: ask a question, get an answer. No memory, no tools, one-shot. *[screenshot or tiny live Q&A]* — "This is an **app you open**. It's where almost everyone still lives."
+2. **Flash-forward to the destination.** Cut to the Insights Collector output — *[screenshots of the structured interview-conclusions notes]*. "This talk was researched and organized by an AI working next to me — not something I *opened and asked*, but a system that runs the way *I* work. I didn't write a word of this."
+3. **The pull-back hook.** "But I'm getting ahead of myself. How do we get from an app you open... to a personal operating system that works like you do? Let me take you on the three-year journey — and by the end you'll know exactly how to walk it yourself." (Reassure: "No engineering. A laptop and your real work is all you need.")
+
+---
+
+## 2. The Journey: Evolution of LLMs — the spine (~16 min)
+
+*Retell the technical timeline (from the git-skills talk) as "what could it do for **you**?" Each station: capability → animation → the rung of the relationship.*
+
+| Station | Capability unlocked | `[ANIMATION]` shows | Relationship rung |
+|---|---|---|---|
+| **2023 — Answer machine** | Ask → answer | (established in opener) | An app you **open** · a **stranger** |
+| **Late 2023 — It learned to act** | ReAct / tools: take an action, see the result, adjust | The loop: question → tool → result → better answer | Stranger → **doer** |
+| **2024 — It reads your world** | RAG / connectors: it reads *your* docs, email, data | Pointing Claude at your files & inbox | Generic → **yours** |
+| **Late 2025 — The great simplification** | One capable assistant, huge variety, on your computer | Many task types, one assistant | Toy contraptions → **real teammate** |
+| **2025 → Skills = memory** | Reusable skills + your personal data; remembers who you are | Skill folders + "who I am" docs feeding in | Teammate → **knows you** |
+| **Now (2026) — It runs around you** | Proactive, scheduled, always on | A morning brief appearing overnight | Tool I open → an **always-on OS** |
+
+**Beat-by-beat:**
+
+- **2023 — Answer machine** *(~1 min, recap from opener).* A smart stranger you meet fresh every time. Great knowledge, but forgets you and can't *do* anything.
+- **Late 2023 — It learned to act** *(~3 min).* It can take an action, see what happened, and adjust — the "agent loop." Look things up, use a calculator, call a service. `[ANIMATION: the loop]`
+- **2024 — It reads your world** *(~3 min).* It reads *your* documents and data, not just its training. Now the answers are about *your* work, not the average of the internet. `[ANIMATION: pointing at your files]`
+- **Late 2025 — The great simplification** *(~3 min).* Engineers over-built for a while; turns out one capable assistant with a few simple abilities handles enormous variety. **Claude Desktop enters here** as the concrete embodiment — the assistant that lives on your computer, reads local files, connects to Gmail/Calendar/Drive. `[ANIMATION: one assistant, many tasks]`
+- **2025 → Skills = memory** *(~3 min).* It holds reusable **skills** (a folder + a plain-text note — *no code*; Claude can build them; portable to other tools) alongside your **context docs** (the "who I am" files). It stops being stateless and starts sounding like you. `[ANIMATION: skills + context feeding in]`
+- **Now (2026) — It runs around you** *(~3 min).* Proactive, scheduled — a brief waiting for you in the morning. You stop *opening* it; it runs in the background of your day. **This is where the mindset shift crystallizes into the OS metaphor:** intern → **teammate**; a tool I open → an **operating system running for me**; a clever prompt → **context about who I am**. Winners keep judgment and agency; losers offload it. *"It's an investment, not a cost"* — one hour → ~3 hrs/week saved. `[ANIMATION: overnight brief]`
+
+> **Transition to the demo:** "We've arrived at today. You now understand every capability behind the thing I teased at the start. Let me show you the whole of it."
+
+---
+
+## 3. Arrival — Insights Collector demo (5 min) ⭐
+
+*The teaser pays off — today's reality, now that they understand every capability behind it.*
+
+**Callback:** "Remember those notes from the first minute? Here's how they were made."
+
+**The universal problem:** hours of meetings, calls, webinars, and podcasts you never mine for value.
+
+**The pipeline (shown simply):**
+1. **Record** the conversation (e.g., the Sebastian interview).
+2. Claude **transcribes** it (Whisper) and separates *who said what* (speaker diarization).
+3. Claude reads the raw transcript and **distills** it into a structured insight note: executive summary, key themes, tensions, memorable quotes, actionable takeaways.
+4. All notes live together in a **searchable knowledge base** (Obsidian) — a skill + your data.
+
+**Show the real artifact in depth:** the Sebastian interview conclusions note. "I recorded a 56-minute chat and got *this*."
+
+> **Meta-punchline:** "Three of the biggest ideas in this talk — the evolution timeline, the mindset shift, the irreversible gap — came straight out of these notes. **The assistant did the research; I did the judgment.**"
+
+*(optional)* **Ask across everything:** "what did everyone agree on about non-engineers using AI?" — it synthesizes across notes. (Sebastian: "you can put your whole life into a RAG.")
+
+**Land it on them:** "Every meeting and interview you sit in could be a searchable, structured asset instead of a vague memory. This isn't an app you opened — it's a system running the way you work."
+
+---
+
+## 4. Next — an OS fine-tuned to *you* (2 min)
+
+*Lift beyond today. This is what makes "fine-tuned for you" literal — and the reason to start now.*
+
+> **Say the gloss out loud first (don't assume they know the term):** "*Fine-tuned* just means **shaped around you** — it takes in your voice, your goals, your data and adjusts until it works the way *you* work, not the way the average person does. Think of breaking in a pair of boots until they fit only your feet."
+
+- **Today you fine-tune it by hand:** your context docs, your skills, your data shape it into *yours*.
+- **Next it fine-tunes itself — by watching how you work.** Allie's example: Claude observes her hiring calls for months, notices she keeps favoring higher-risk / higher-payoff candidates, and updates its own decision framework to match her judgment. Not a memory trick — the system actually adapts to you.
+- **The "market of one":** every person ends up with their own AI OS; tools and even websites render themselves for *you* (Nike shows Allie the dark-green shoe because it knows her).
+- **The point:** it stops being a product everyone shares and becomes an operating system fine-tuned to exactly one person — **you.** Side effect: real human relationships get *more* valuable, because everything else is mediated by proxies.
+
+---
+
+## 5. Do this tonight (3 min)
+
+*The industry took three years to walk this path. You can walk it in a week.*
+
+1. **One hour.** Let Claude interview you and build your **3 foundation docs** — who you are · your goals · your role/business. Say "ask me questions before you start."
+2. **Pick your #1 recurring annoyance** and let Claude propose a skill for it ("just complain").
+3. **Use Claude Desktop, not just the chat box** — point it at one real file this week.
+
+---
+
+## 6. Close (1 min)
+
+- **Callback to the journey:** "We started with a chat box you open and ended with an operating system fine-tuned to you. The whole industry took three years. You just watched the map."
+- **The gap, in one sentence:** the person who sets up their OS this week won't just be *more productive* — they'll have *less fear* of every new release, because each new capability slots into a system they already understand and that already knows them.
+- **Final line:** "You don't need to be an engineer. You need a laptop, one hour, and your real work. Start building your OS tonight." → **Q&A.**
+
+---
+
+## Open follow-ups (decide before building slides)
+
+- **HR-contacts search** as a fast *second* demo at the "reads your world" (2024) station — "you already have the right candidates/clients in your contacts, you just can't see them." Ready dataset exists (`HR Contacts.md`). Trade-off: adds wow but tightens timing and leans recruiter-specific.
+- **"Become your own boss"** thread (`Ideas for webinar.md`) — could color the "real teammate" station for an entrepreneur-leaning crowd.
+- **"Connections are everything"** (Sebastian) — pairs naturally with the "market of one" beat (§4: human relationships get more valuable). Could be a closing note or a Q&A talking point.
+- **Animations** — one per station. **Update:** likely become the interactive mini-games below rather than pre-rendered clips — see *Visual system & interactive concept*.
+
+## Visual system & interactive concept (production track)
+
+> **Mockups:** working design mockups live in [[mockups/README|`mockups/`]] — `intro`, `style-directions`, `demo-slides`, and the interactive `mini-games` (the four levels). Double-click any to open in a browser.
+
+### Decisions so far
+- **Build:** Web / WebGL (Three.js + GLSL shaders); auto-playing animations, browser full-screen; can render to video as a fallback.
+- **Aesthetic:** TRON-flavored. Leaning toward a **hybrid of Cyber-terminal (C) + Holo-HUD (D)** — Holo-HUD as the *world/frame* that carries the "game / levels" metaphor (level rail `0X / 07`, glass panels, corner brackets, gauges), Cyber-terminal for every *interaction moment* (chat, commands, the demo). Pure-C and pure-D remain viable; final call pending.
+- The per-station animations become the **interactive mini-games** below (upgrade from pre-rendered placeholders).
+
+### Phase 2 — live terminal via OpenRouter
+- Wire the on-screen terminal to a real model through **OpenRouter** (OpenAI-compatible, token streaming). The typewriter becomes *real* streaming.
+- **Key handling:** a tiny **local proxy** holds the API key (avoids exposing it in the browser + dodges CORS). Page → `localhost` proxy → OpenRouter.
+- **Stage safety:** on-rails prompts (keypress-triggered) with **cached fallback** responses; low temperature; deterministic stubs where an exact outcome matters. Never a naked live call.
+- **Bonus:** fire the same prompt at an *old vs new* model live — direct proof of the "evolution" spine.
+- **Scope caveat:** OpenRouter covers the **chat/reasoning** only. The full Insights Collector pipeline (Whisper transcribe + speaker diarization + file writes) is real tooling — **pre-bake or record** that part.
+
+### Big idea — one mini-game per concept (interactive "levels")
+Each evolution rung = a self-contained HTML page that *behaves* like that generation of AI. **Shared stage:** a *weather-in-Kyiv widget* + a *playing field with a movable block*. Same user request every time — **"move the block down if Kyiv is below 20°C"** — solved differently as capability grows:
+
+- **Level 1 · Chatbox** — no tools, no live data. It can only *talk*: asks you for the weather, then tells *you* to move the block manually. (System prompt hard-constrains a modern model to 2023 behavior so it doesn't cheat.)
+- **Level 2 · ReAct** — the model emits a text protocol (`Thought → Action → Observation`). The page parses it, fetches the weather, feeds the observation back, the model decides, the page moves the block. Glow/pulse effects wrap each ReAct message to teach the loop.
+- **Level 3 · Tool calls** — same scenario via native function-calling (`get_weather`, `move_block` as tool schemas). Show the structured `tool_calls` JSON to contrast with ReAct's text parsing.
+- **Level 4 · Skills** — the punchline. Instead of re-explaining the task each time, **save a skill** ("weather-based-movement"). After a page refresh, just say *"do a weather-based movement"* — the model loads the skill and executes. Demonstrates **two-stage loading**: short description always in context → full body loaded on demand.
+
+*Note:* the mini-game order (chatbox → ReAct → tools → skills) is a tool/skill-centric sub-progression; may refine or align the middle stations of the evolution spine.
+
+### In-browser skill system (feasible)
+- A **skill** = a small record: `name`, short `description` (the trigger), long `body` (the steps + which tools it uses). Faithful to "a skill is a folder + a note."
+- **On load:** inject only skill *descriptions* into the system prompt (progressive disclosure). Model calls `load_skill(name)` → harness injects the full body → model executes. `save_skill(name, description, body)` creates new ones.
+- **Storage:** `localStorage` / IndexedDB for pure-browser; or write real `SKILL.md` files via the local proxy (more faithful *and* more impressive — "it just created a file").
+- Effectively a **tiny agent harness in the browser** — a meta-demonstration of the whole talk.
+
+### Engineering caveats (shared)
+- Constrain each level with a system prompt so a capable model *acts its age*.
+- Tool-calling levels need a tools-capable model — pin exact model IDs against current OpenRouter docs at build time.
+- Prefer a **deterministic weather stub** (fixed value) on stage; real weather API optional.
+- Build shared components once (widget, field, block, message log, effects); per level, swap only the "brain" wiring.
+- Reliability: cached fallbacks, low temperature, no naked live calls.
+
+## Source material map
+
+- **Evolution timeline (the spine)** → `Скиллы на базе git — новая память AI-агентов.md` (Parts 1 & 3), simplified per station.
+- **Mindset shift, OS framing, foundation docs, "just complain," the gap, self-learning / market-of-one (§4)** → `In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible.md`.
+- **Insights Collector demo artifacts, "RAG your whole life," ownership, connections (§4)** → `sebastian interview - conclusions and insights.md` + the other processed notes in this folder.
+- **Demo dataset** → `HR Contacts.md`.
+
+---
+*Plan created 2026-07-07 · reframed destination: teammate → personal OS fine-tuned for you*

raw/sources/Webinar script.md

@@ -0,0 +1,617 @@
+_ideas: disclamer, 
+it's, essentially, the same demo, just with extended set of tools.
+your harnes is unique to you and adapdet to your own workflow_
+# Intro
+
+So... Let's start!
+
+{Press start button}
+
+---
+
+I've always had a passion for building internal tools.  
+
+Tools that make one person's life at a company a little easier.  
+
+They cut stress here and there...  
+
+Maybe they only save five minutes a day.  
+
+No one would invest in that.  
+
+But for that one person, those could be the most stressful five minutes of their day.  
+
+Take them away, and they're happier...  
+
+...and more productive.  
+
+Back then, I'd burn whole weekends to help someone.  
+
+Myself included.  
+
+But today, things have changed...
+
+---
+
+We all know ChatGPT. 
+
+But what we know about it is differ from person to person.
+
+Some says that "it just predicts the next token". 
+
+The others: "it is so capable that it will replace all jobs in nearest future"
+
+Somehow both statements are right and wrong at the same time.
+
+I've prepared a small journey for you.
+
+This journey will show you how the same simple task could be done with AI as it evolved over time.
+
+And how you can come from **Chat box** to your own **Agentic Operating System**
+
+# Mail from boss
+
+So, let's imagine that you are working in an office and it's a beginning of your work day. 
+
+You are dreaming for the next vacation while there is a new mail from your boss.
+
+{Open and read email}
+
+You've got yourself a new assignment!
+
+But, before go full in on this, you remember that you've heard about AI that can help people a lot in their work.
+
+So you deciding to give it a shot.
+# Chat box
+
+It's autumn of 2022. ChatGPT is on hype. Everyone talking about it. So it's your way to go.
+
+You open the chatbox and typing.
+
+"I've got this mail from my boss! what should i do? {paste mail text}"
+
+{Chatbox gives answer}
+
+Pretty good instructions, i would say.
+
+AI knows about your environment and now about your task. So it can help you to compete it.
+
+{Following AI instructions}
+
+Task is complete. You are happy. Boss is happy. 
+
+Let's see what allowed AI to be so helpful for us.
+
+{Open system prompt}
+
+Each AI model has a system prompt that shapes it's behavior.
+
+And this is exactly what we see here. 
+
+This is essentially an instruction on how to interact with our toy system.
+
+And AI works like an advanced search engine. 
+
+It works great with 
+
+Now you just need to check on weather and do this routine till your next vacation.
+
+AI just can't help you more. You've got the knowledge that you need. That's it.
+
+Essentially, that is google on steroids or interactive instruction to your product, but nothing more.
+
+Researchers of the time realized this fairly quickly.
+
+There just should be a way to make AI to do something useful.
+
+Allow AI to act.
+# ReAct
+
+in the same autumn of 2022. ReAct technique was released.
+
+Let's imagine that you have received this task from your boss a bit later.
+
+And now programmers of your company integrated ReAct technique into your AI chat.
+
+So what this means for you? 
+
+AI can act now!
+
+let's see how it would react on the same prompt.
+
+{use the same prompt}
+
+AI does the job for you now!
+
+This opened the door to some possibilities. 
+
+AI can work with information from the real world, not only from instruction.
+
+But this technique was highly experimental and hard to use.
+
+It required a lot of effort to add new functionality to model.
+
+AI models were glitching, hallucinating, writing answers themselves...
+
+But the direction was set.
+
+This was highly usable.
+
+let's see what allowed us to teach ai to do something useful
+
+{show system prompt}
+# Tools
+
+in summer of 2023 GPT-4 made tool definition as standard
+
+models were trained with this definition in mind, so it became native for them.
+
+programmers now could add functions to models the same way as they could do it in code
+
+models could have a variety of tools for low price of adding them
+
+so now it's even easier to integrate AI into everything
+
+here i want to introduce a new term: Harness.
+
+you've, probably, heard about it.
+
+Harness is a set of tools and techniques that are built around AI model.
+
+lot of SaaS startups working like this
+
+just make a harness, connect to OpenAI api, take your profit
+
+_todo: here i would need some examples of saas startups_
+
+now, when we can integrate AI into more things, let's see how our work day is going
+
+"check if there is new mail from Marcus and do what he wants"
+
+{AI does something}
+
+now AI has access to mail
+
+and we don't even need to describe the task by ourselves
+
+AI just reads it and does it
+
+Imagine that that there is Jira ticket instead of mail
+
+And you have task automation
+
+"But what if AI has a question? What if the task is not clear?" - i hear you ask
+
+{ask AI to write answer to the boss}
+
+it can update and re-assign tickets in the same way
+
+and the coolest thing is that, thanks to MCP servers, programmer needs less than an hour to add connection to any datasource
+
+let's get back to our task
+
+if we start a new session, AI would still know nothing about us.
+
+Let's check it.
+# Memory
+
+{close the terminal, open a fresh one}
+
+"do what Marcus asked"
+
+{AI has no idea who Marcus is}
+
+And... it's a stranger again.
+
+Everything we built up in that conversation — gone.
+
+Here's the uncomfortable truth about AI models: they never remember anything.
+
+The model's entire world is the current conversation.
+
+Close the window — and that world is erased.
+
+Every session, you meet the same brilliant amnesiac.
+
+For a chatbot, that's annoying.
+
+For a coworker, that's a deal-breaker.
+
+You wouldn't re-onboard a new employee from zero every single morning.
+
+So the fix had to come. And it turned out to be almost funny in its simplicity.
+
+A notebook.
+
+{open the Memory level}
+
+We give AI one more tool — a notebook it can write in.
+
+And one standing rule: if you learn something worth keeping — write it down *before* you answer.
+
+Let's watch it work.
+
+"From now on: when Kyiv is below 20 degrees, the cube goes to the top shelf. Above 20 — bottom shelf."
+
+{AI saves a note, then does the task}
+
+Notice — before doing the job, it quietly made a note.
+
+Now, the moment of truth.
+
+{close the terminal — session destroyed — open a new one}
+
+New session. Blank conversation. Yesterday this meant total amnesia.
+
+"Check the weather at my place"
+
+{AI checks the weather and moves the cube}
+
+It knows.
+
+No explanation needed. The knowledge survived the session.
+
+Want to see the magic trick?
+
+{show system prompt}
+
+There is no magic.
+
+When a session starts, the harness simply pastes the notebook into the system prompt.
+
+And the notebook itself?
+
+{show memory.md on disk}
+
+A text file. Sitting on my computer.
+
+A text file I never wrote. AI maintains it itself.
+
+There's a second notebook too — about *me*.
+
+{show user.md — "The user lives in Kyiv"}
+
+So I don't even have to say "Kyiv" anymore. "Check the weather at my place" is enough.
+
+This is the moment AI stops being a tool you operate...
+
+...and starts being a teammate.
+
+Because a teammate remembers agreements. Remembers your preferences. Remembers *you*.
+
+But look closer at that notebook.
+
+It's tiny. On purpose.
+
+Everything in it gets loaded into every single session — needed or not.
+
+Facts about you fit fine.
+
+But whole procedures? Step-by-step workflows?
+
+Write all of those down, and the notebook becomes a phone book the AI must re-read every morning.
+
+What we need is memory that stays on the shelf...
+
+...and comes down only at the exact moment it's needed.
+
+That's the next stop.
+
+
+# Skills
+
+in autumn of 2025, the industry landed on an answer.
+
+And once again, it's funny in its simplicity.
+
+A folder with a text note in it.
+
+They called it a skill.
+
+Let me show you why this changes everything.
+
+{open the Skills level — the shelf is empty}
+
+Let's do our morning routine. But this time, I'll walk AI through it step by step.
+
+"check the weather in Kyiv"
+
+{AI checks the weather}
+
+"the rule is: below 20 — top shelf, above 20 — bottom shelf. it's below right now, so move it to the top"
+
+{AI moves the cube}
+
+Job done. Nothing new so far.
+
+But notice who did the thinking.
+
+Me. I was the recipe.
+
+The procedure lived in my head, and I dictated it, step by step.
+
+Do this every morning — and *I'm* the bottleneck again.
+
+So now, the one sentence that changes the game:
+
+"save what we just did as a skill"
+
+{AI writes the skill}
+
+Let's look at what it created.
+
+{show SKILL.md on disk}
+
+A folder. Inside — one markdown note.
+
+A name. A one-line description of *when* to use it.
+
+And the steps we just walked through — written down as a recipe.
+
+No code. Plain human language. My procedure, on paper.
+
+Now watch.
+
+{close the terminal, open a fresh one}
+
+New session. Total amnesiac, remember?
+
+"do the weather-based movement"
+
+{AI loads the skill and runs it — weather, cube, done}
+
+One line.
+
+No briefing. No step-by-step. No me-being-the-recipe.
+
+It found the skill on the shelf, read the recipe, and did the job.
+
+And here's the clever part — the part the notebook couldn't do.
+
+{show system prompt}
+
+Look what's actually loaded: just the name and one line of description.
+
+The full recipe stays on disk...
+
+...until the exact moment it's needed.
+
+That's why you can have ten skills. A hundred. Hundreds.
+
+The shelf can be huge — the desk stays clean.
+
+And remember: a skill is just a file.
+
+You can read it. Fix it. Improve it.
+
+You can send it to a colleague — and now *their* AI knows your procedure.
+
+You can take it to a different AI tool tomorrow. It's plain text. It travels.
+
+Your experience is no longer locked in your head — or in one chat window.
+
+Memory made AI a teammate who knows *you*.
+
+Skills make it a teammate with *experience* — one who knows how the job is done.
+
+But one thing still bothers me.
+
+Marcus said: "continuously — don't let it drift."
+
+And every single run still starts the same way...
+
+...with me. Typing.
+
+The AI has the knowledge. It has the skill.
+
+But I'm still the alarm clock.
+
+What if we could remove even that?
+
+# Process
+
+it's 2026 now. and this is where we finally arrive.
+
+{open the Process level}
+
+This window looks like all the others.
+
+But it's not a chat anymore. It's a *shell*.
+
+And the AI behind it is not an assistant. It's a process manager.
+
+Watch what happens when I give it — not a task...
+
+...but a goal.
+
+"keep the cube on the right shelf: below 20 — top, above 20 — bottom. continuously."
+
+{AI spawns a process — "started process 1"}
+
+Look at the answer.
+
+It didn't do the task.
+
+It started a *process*. With a process id. Like a real operating system would.
+
+And now — the most important moment of the whole journey.
+
+I take my hands off the keyboard.
+
+{step away; heartbeat lines tick every few seconds}
+
+Every few seconds — a heartbeat.
+
+Check the weather. Compare. Decide. Hold.
+
+Nobody is typing. It just... runs.
+
+Let's make the world change.
+
+{drag the weather Override slider across 20°}
+
+{the cube moves by itself}
+
+There.
+
+The temperature crossed the line — and the cube moved.
+
+No prompt. No click. No me.
+
+And it stays manageable, like any process:
+
+"what's running?"
+
+{ps-style table of processes}
+
+"stop process 1"
+
+{process killed}
+
+Spawn. List. Kill.
+
+Where have you heard those words before?
+
+That's how an operating system talks about its programs.
+
+Now — the reveal. What actually happened when I typed that goal?
+
+{show the prompt the shell wrote for the worker}
+
+The AI wrote... a prompt.
+
+For another AI.
+
+It authored the worker's instructions — like a manager writing a job description — and launched it.
+
+AI managing AI. And you? You just state the goal.
+
+Remember what Marcus asked for? "Continuously. Don't let it drift."
+
+Handled.
+
+I haven't touched the keyboard in two minutes.
+
+You can finally get back to dreaming about that vacation.
+
+But... one thing still feels unfinished.
+
+Look at this window. It's still a terminal.
+
+I still had to *type* the goal. To talk to it the way a programmer talks to a shell.
+
+Most people never will.
+
+What if this whole routine could stop being a conversation at all...
+
+...and become a tool? A small one. Made for exactly one person.
+
+# OS
+
+{open the OS app}
+
+Look at this window.
+
+No chat box. No blinking cursor. Nothing to type.
+
+A status bar. One button: "Check temperature in Kyiv". One checkbox: "Do every 5 seconds".
+
+That's the whole interface.
+
+{click the button}
+
+{AI checks the weather, the cube slides to the right shelf, the status bar shows its one-line report}
+
+One click.
+
+The agent checked the weather, applied Marcus's rule, placed the cube — and reported back in one line.
+
+But wait. Where did the rule go? I never typed it.
+
+It's baked in. This app was *built* around Marcus's instruction.
+
+The prompt was written once — and disappeared behind a button.
+
+{tick "Do every 5 seconds"}
+
+And now it's not even a button anymore.
+
+{drag the Override slider across 20° — the cube crosses on its own; the status bar updates}
+
+It's an appliance. It just... works.
+
+Notice what disappeared along the way.
+
+The conversation.
+
+There's still a full AI agent in there — same model, same tools, reasoning on every tick.
+
+But you don't chat with it anymore.
+
+You click it. You tick it. You close it.
+
+You interact with it the way you interact with any other program on your computer.
+
+The agent became... a program.
+
+A tiny program that does exactly one job. For exactly one person. You.
+
+Remember where we started tonight?
+
+I told you I used to burn whole weekends building little tools like this.
+
+Tools that save one person five stressful minutes a day.
+
+This one took 10 minutes.
+
+And I didn't write it — I *asked* for it.
+
+That's the last step of the ladder.
+
+The chat box didn't just get smarter.
+
+It dissolved — into the operating system.
+
+Into little tools you make for yourself.
+
+---
+
+And here's the secret of tonight's whole journey.
+
+The model never changed.
+
+Chat box, ReAct, tools, memory, skills, processes — even that button — behind every level, the *same* AI model.
+
+What changed was everything around it.
+
+The tools it can reach. The notebook it keeps. The skills on its shelf. The processes it runs. The buttons it hides behind.
+
+That's the harness. And the harness is the whole difference...
+
+...between a stranger in a chat box and an operating system that works while you don't.
+
+And here's the part that matters for *you*:
+
+nobody can sell you this off the shelf.
+
+Because the harness is built from *your* mail, *your* rules, *your* procedures, *your* routine.
+
+It grows out of the way you already work.
+
+Your harness is unique to you.
+
+You don't buy it. You build it — one small tool at a time.
+
+We started this journey by pasting an email into a chat box.
+
+We're ending it with a button that already knows what the email said.
+
+From a chat box... to your own Agentic Operating System.
+
+# Notes
+- push yourself up the management chain
+- terminal, MS office is skeuomorphism
+
+Andrej Karpathy
+
+This is a new paradigm for interacting with Claude that is significantly more "inline" with all the other human activity org-wide. Once you do all of the under the hood engineering work to make this "just work" (e.g. across tools, integrations, compute environments, memory, security, etc.), Claude basically joins the team in a seamless way - you can talk to it as you would talk to a person and it can help with a very large variety of workloads. Imo this is the 3rd major redesign of LLM UIUX. The first paradigm was that the LLM is a website you go to, the second was that it is an app you download to your computer. This third one is that it is a self-contained, persistent, asynchronous entity with org-wide tools and context, working alongside teams of humans. It really takes a while to wrap your head around it, but it works and it is awesome.

raw/sources/You're reading way too much code.md

@@ -0,0 +1,175 @@
+# Conclusions
+
+**Source:** https://www.youtube.com/watch?v=434cG4g5KLE
+**Title:** You're reading way too much code
+**Duration:** 24:11
+**Speaker:** Theo Browne (t3.gg / T3 / Lakebed)
+
+---
+
+## Core thesis
+
+Most engineers are reading **too high a percentage** of their code — not because the code that matters shouldn't be read, but because they aren't **generating enough code that doesn't matter**. AI has made code cheap; the smart move isn't to merge more slop into your product, it's to write mountains of throwaway code around it to **verify, explore, stress-test, and answer questions** that were too expensive to bother with before.
+
+> "I'm not telling you to make your code cheaper. I'm telling you to make more cheap code."
+
+---
+
+## The importance-of-code spectrum
+
+All software lives on a spectrum:
+
+| End | Example |
+|---|---|
+| Low | "Slop website with one viewer" |
+| High | "Firmware for a pacemaker" |
+
+Two big mistakes people make when arguing about AI code:
+
+1. **They assume they're further along the spectrum than they actually are.**
+2. **They project the statement they hear onto their own tier** — if they like it, they assume the speaker is at or above their tier; if they don't, they assume the speaker is below.
+
+This makes the "should you read AI code?" debate nearly impossible because everyone is thinking too highly of themselves.
+
+---
+
+## The old ratio vs. the new ratio
+
+Theo's example numbers from his own workflow:
+
+| Era | Read/day | Written/day | Merged/day |
+|---|---|---|---|
+| Pre-AI (Twitch era) | 1,000 | 200 | 100 |
+| Now | ~1,000 | **2,000+** | **~500** |
+
+Reading has not gone down. Writing and merging **have both gone up** — but the critical, unspoken piece is that a huge chunk of the newly generated code is **never merged and never reviewed** because it wasn't ever meant to be shipped. It exists to test ideas.
+
+---
+
+## The key argument (Theo grants the strongest version of the opposition)
+
+Steelmanned position: *"Every line of code in my job is so important that a mistake could kill someone / bankrupt a business / stop a heart."*
+
+Theo grants this. Then:
+
+- If your production code is that important, you should absolutely read every line of it.
+- **But** — that's not a reason to write less code overall. That's a reason to write **10,000× more** throwaway code to verify it.
+- "Every line of code that goes in should have 100 lines of slop verifying it. Every line that goes in should have 10,000 lines of code of slop that you can use to verify the system."
+- If the core is too important for AI to touch — abstract one layer higher. If the verification layer is too important — abstract another layer higher. Custom debuggers. Custom runtimes. Custom logging. Custom lint rules. Load-test rigs. Property-based probes.
+
+**Trap Theo calls out:** "our verification tools are also too important for AI to touch." → Then build tools that introspect the verification tools. There is always another layer.
+
+Referenced (approvingly): Shao's ratio — **~80% of his AI-generated code goes into test harnesses and guardrails**, with the LLM getting the harness results in its context. Fewer mistakes overall.
+
+---
+
+## The four tiers of code
+
+| Tier | Label | Attitude toward reading |
+|---|---|---|
+| **A — Slop** | "I would rather die than have anyone read this code" (e.g. 10K lines to organize 100 files on his own machine) | Don't read it. It exists to answer one question. |
+| **B — "I'd like this to work"** | Personal tools, experiments, prototypes | Skim. Ask the agent for a summary. |
+| **C — "I'll get in trouble if this breaks"** | Product code that can be reverted | Read the pieces that matter — signatures, APIs, boundaries. Rely on tests + AI review. |
+| **D — Death tier** | Pacemakers, ERPs, financial systems, medical devices | Read every line. Verify obsessively. |
+
+**Most people spend across multiple tiers.** Nobody spends 100% in D. And that's the leverage point — because the tier-D specialists barely used tiers A-B before (since writing bad code by hand was as costly as good code), they now have the biggest untapped upside in throwaway code.
+
+---
+
+## What actually changed
+
+- **Before:** writing code was expensive → all your writing effort had to be worth merging → reading was cheap by comparison → high read-to-write ratios made sense.
+- **Now:** writing code is nearly free → writing 10,000 lines to verify one line finally makes sense → reading is still expensive (it still costs attention) → the ratio of *generated* to *read* should skyrocket.
+
+> "Writing 10,000 lines of code to organize 100 files is mental illness until the code is free to generate. Then all of a sudden it's totally reasonable."
+
+---
+
+## What "more slop" actually looks like in practice
+
+Concrete examples Theo gives:
+
+- **Generate custom lint rules on demand** for a specific bug pattern you found
+- **Build one-off debuggers** and compiler hooks for a specific investigation
+- **Slop-port your Go service to Rust** just to run the test suite against it and see if it's faster (knowing most won't merge)
+- **Spin up 10 agents with dumb models** (grok tier) to try building on top of a freshly designed API/SDK — if dumb models can use it, ship it; if they can't, fix the API
+- **Give Codex AWS access** and tell it to spin up services and stress-test your system
+- **When a PR is ambiguous** — have an agent try 3 different theories in parallel and test all 3
+- **Missing tests?** Have an agent write a bespoke test suite for the one-off theory you're worried about
+
+---
+
+## Reading tricks for tier-C code (via Dax)
+
+From a Dax post Theo quotes approvingly:
+
+> "Lately after a big diff change, instead of reading the diff, I ask the agent for a summary of what it did in every file. Anything weird will stick out immediately and one or two prompts later it's completely how he wants it. Files and function signatures he needs to know, but he cares less about the function body."
+
+Theo's own version — for Lakebed:
+
+- **Reads every function signature and API definition, always** — because stable APIs = maintainability
+- **Uses slop to verify the APIs** — the 10-dumb-agents test above
+
+---
+
+## The pattern Theo *doesn't* endorse
+
+- ❌ Merging unreviewed AI slop into production
+- ❌ Reducing verification of code that ships
+- ❌ "Move faster" as an end in itself
+- ❌ Being one of the loud lovable/vibe-coder-ships-slop people — Theo openly calls those the most obnoxious people on earth and says "I hate them too. We're on the same side."
+
+The pattern he **does** endorse:
+
+- ✅ Same (or more) hand-verification of code that ships
+- ✅ Much more generation of code that never ships
+- ✅ Using AI to *review* code before humans do
+- ✅ Treating code as disposable — "for one idea, one theory, one question, one thing"
+
+---
+
+## Reframing chart — "same read, more write, same merge"
+
+| Metric | Old day for a tier-D engineer | New day (Theo's proposal) |
+|---|---|---|
+| Lines written for prod (hand-verified) | 100 | 80-100 (roughly unchanged) |
+| Lines read (hand-reviewed) | 200 | 400 |
+| Lines **generated as throwaway slop** | 0 | **800+** |
+| Merged | 100 | 80-100 |
+
+Read goes **up** in absolute terms. Slop goes way up. Merged is unchanged. Percent-of-code-you-read as a share of *generated* falls dramatically — which is the whole thing Theo is defending.
+
+---
+
+## Cross-cutting principles
+
+- **Code is useful for things other than shipping.** Exploration, verification, debugging, one-off answers, "does this API feel right when a dumb model uses it".
+- **Draw a line between code-that-ships and code-that-doesn't.** Change your discipline separately on each side.
+- **The importance of your ship code is not a reason to write less other code — it's a reason to write way more.**
+- **If you feel you can't find slop-generation opportunities, you're not creative enough**, not the tools' problem.
+- **Reading takes real energy.** Don't try to read faster — try to only read what's worth reading.
+- **Have AI review your code first** before bringing it to your team.
+
+---
+
+## Actionable takeaways for engineers on important systems
+
+- [ ] Identify which tier (A/B/C/D) your daily code actually falls in — be honest, most work is B/C
+- [ ] Keep hand-review discipline on tier-D code exactly as-is
+- [ ] Add a bucket in your repo (or a sibling repo) explicitly for **throwaway verification code**
+- [ ] For your critical production module, plan **10,000 lines of AI-generated verification** as a first-class output: fuzzers, property tests, alternate implementations, custom debuggers
+- [ ] Whenever you find a subtle bug, have an agent **generate a custom lint rule** for it
+- [ ] Ambiguous PR? Have an agent **A/B/C-test three theories in parallel**
+- [ ] For any new API/SDK you own, **spin up dumb-model agents to try to use it** — treat their failures as UX bugs in your API
+- [ ] Route giant diffs through **agent-generated per-file summaries** instead of line-by-line reads
+- [ ] Add **AI code review as a pre-human step** in your workflow
+- [ ] For load/performance questions, delegate to an agent with cloud access to spin up throwaway rigs
+
+---
+
+## Who this is for
+
+- Engineers on important systems (finance, medical, infra, ERP) who feel defensive about AI-generated code
+- Skeptics who conflate "AI slop shipped to prod" with "any AI-generated code at all"
+- Engineers with high read/write ratios who haven't yet added throwaway-verification work to their toolkit
+- Anyone still writing code as if generation cost is the bottleneck (it isn't — attention is)

raw/sources/Yulia interview.md

@@ -0,0 +1,55 @@
+## Executive summary
+
+An HR/recruiting lead (SPEAKER_00) brings a senior programmer/AI consultant (SPEAKER_01) three team pain points, and he demonstrates that all of them are solvable today with Claude plus reusable "skills." The firm conclusion: their two recruiting problems collapse into one — build a searchable candidate knowledge base (record interviews → auto-transcribe → auto-generate profiles) — and the next step is a webinar he'll plan over the coming weekend, with a possible paid build of an HR tool to follow.
+
+## Who's who
+
+- **SPEAKER_00** → HR/recruiting lead (female), collecting her team's AI pain points and organizing the webinar. Self-described beginner; refers to Nina, Sergiy and "Andryuk" as the people who approve budget, and to "Jean-Luc/Zhenlyuk" who posts about AI.
+- **SPEAKER_01** → Senior programmer (~20 years), works on "Inspectron" and its clients. Heavy Claude user on the $200 max plan; proposes the webinar and offers to build the HR system for money.
+
+## Key themes
+
+**AI usage has distinct levels, and most people are stuck at level one.** He maps a ladder: web chatbot → built-in memory → Claude Code/Cowork with local file access → CLAUDE.md → skills → Obsidian knowledge base → RAG. The practical ceiling for non-programmers is CLAUDE.md plus skills.
+> "Usually you need CLAUDE.md and skills. That's your maximum."
+
+**Skills are reusable process memory — solve first, skill-ify after.** The recurring mistake is building the skill up front. Instead, solve a task with Claude once, then ask it to package that into a skill it can rerun on command.
+> "The mistake people always make is they create a skill first and then try to shove it somewhere… You first solve a task with Claude; the moment you reach the final solution, you say — now create a skill from this."
+
+**Both recruiting problems are the same problem: a candidate base plus search over it.** Recording interviews, auto-transcribing (with speaker diarization), and generating standardized profiles feeds a knowledge base you can later query by skill — including finding people you already spoke to who match a niche stack.
+> "You need a candidate database and you need search over that candidate database."
+
+**AI automates all information work; the human keeps the human parts.** His central thesis for the webinar — the residual human role is connection and communication, not information processing.
+> "The human's role in this process is just to be human — introductions, communication… Because our reality is all information work. And AI can replace all of it."
+
+**AI prices will rise, not crash — so invest in the skill now.** He argues the "bubble" pops upward: capable AI gets more expensive, and the leverage shifts to knowing which models to use.
+> "What I now buy for 200 will cost about 1,000… Expensive AI will become even more expensive."
+
+**Economics favor renting GPU over owning.** Live demos (RunPod for transcription, Claude driving a browser to pull LinkedIn HR contacts into a Markdown list) frame the cost: ~$0.10 per candidate to rent, versus a $1,500–2,000 machine — though a home GPU can transcribe overnight for free at roughly 2× real-time on CPU.
+> "It's not per hour of video. The server costs about a dollar an hour, but you only need it for ~6 minutes — so 10 cents."
+
+## Conclusions
+
+- The next webinar will be an overview of the levels of AI usage and how to use them; SPEAKER_01 will draft a plan Saturday–Sunday, present it on a call, and there is **no deadline** — SPEAKER_00 was explicit about zero time pressure.
+- The team's two recruiting problems are "banal" and easily solvable: a candidate knowledge base plus semantic search, fed by recorded-interview transcripts and standardized profiles.
+- Recommended stack: Claude (Claude Cowork for non-programmers), with CLAUDE.md + skills as the realistic ceiling; RAG only matters at corporate scale. He prefers Claude over GPT/Google for professional work; cheaper models (e.g. Qwen) do the same tasks "just worse."
+- The immediate good-practice change regardless of tooling: **start recording candidate interviews now**, one file per candidate, named by candidate.
+- Renting GPU (~$0.10/candidate) is cheaper than buying hardware, but a home GPU works overnight for free if you already have one.
+- A paid build of the HR system is on the table — priced per project, roughly "$5 to $100," with more scoping needed; possibly delivered as a shared monthly service on his subscription.
+
+## Takeaways
+
+- Solve a task with Claude first; only then have it create a skill from the finished workflow. Don't build skills speculatively.
+- Turn any correction loop longer than ~3 messages into a skill.
+- Use CLAUDE.md for persistent per-project instructions, and add "always keep CLAUDE.md up to date" to make it self-maintaining memory.
+- Constrain prompts — your job as a user is to "narrow the variability of interpretation." Vague asks ("make me a dashboard") invite unwanted "fantasy."
+- Learn from docs.claude.com; there's no single good course yet. SPEAKER_01 will cover this in the webinar.
+- Memorable framing to reuse: "Split yourself into two people — one slightly smarter than you, your manager; one slightly dumber, your subordinate. You become the smarter one; the AI is the dumber one."
+- Company-scale idea worth flagging to leadership: a lightweight AI "assistant" that chats with employees and forms an information core — automating most of the PM/status-reporting role.
+
+## Open questions
+
+- Exact scope, deliverables, and price of the HR system — SPEAKER_01 needs more task definition before quoting.
+- Webinar date and title — SPEAKER_01 to propose; possibly with pre-recorded segments so nobody waits on live runs.
+- Rent GPU vs. buy a machine with a GPU — left as "something to think about," possibly folded into SPEAKER_00's next hardware purchase.
+- Larisa's Claude memory complaint — fixable (built-in memory, "remember this," CLAUDE.md), but her specific BA/PM task was never detailed.
+- Can it pull a recruiter's full LinkedIn history at scale? No — LinkedIn bans bots; only a shallow pass (~20 contacts at a time) is safe.

raw/sources/sebastian interview - conclusions and insights.md

@@ -0,0 +1,150 @@
+#ai #interview #development #webinar
+
+# Sebastian Interview — Conclusions & Insights
+
+**Participants:** Sebastian (founder of *Virtido*, a ~11-year-old software outsourcing/engineering company) and Eugene (the interviewer — a computer-vision & embedded/firmware developer, content creator, and builder of his own AI "harness").
+**Length:** ~56 minutes · **Topic:** How AI is reshaping software engineering — teams, tooling, careers, enterprise reality, and business development.
+**Context:** Appears to be a pre-webinar conversation. Casual, candid, two practitioners comparing notes.
+
+> **Sourcing note:** Built from an automatically generated (Whisper large-v3) and speaker-diarized transcript. Quotes are lightly cleaned for readability and obvious speech-to-text errors are corrected (e.g. "Claude Code," "COBOL," "RAG," "Virtido"). A few rapid-crosstalk moments may be mis-attributed.
+
+---
+
+## Executive Summary
+
+The debate is over *whether* AI can write software — it can. The whole game is now *how you use it*. That single shift cascades into everything else in the interview:
+
+- **Teams shrink and roles merge.** The 8-person scrum team collapses to 2–3 people who share coordination and agent-wrangling.
+- **Tooling becomes personal ("bring your own harness") — except where it can't.** Individual developers get maximum leverage from custom harnesses on top of Claude Code; regulated enterprises can't allow that, which creates a real business opportunity.
+- **The value of pure coding skill collapses; the value of judgment, ownership, and relationships rises.** Claude "levels" a 20-year veteran and a fresh grad to similar output — so the differentiator moves to understanding problems and, above all, human connection.
+- **The durable human skills are product ownership and real-world networking.** These are the two things AI doesn't commoditize.
+
+---
+
+## Who's Who
+
+|                      | **Sebastian** (SPEAKER_01)                                                  | **Eugene** (SPEAKER_00)                                                                   |
+| -------------------- | --------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- |
+| **Role**             | Founder/owner of *Virtido*, a software outsourcing company                  | Hands-on developer & content creator; the interviewer                                     |
+| **Vantage point**    | Running a services business, client/compliance/sales lens                   | Building tooling, embedded/firmware & computer vision, individual-leverage lens           |
+| **Signature stance** | "Bring-your-own-harness won't survive enterprise; connections win business" | "Build your own harness; get closer to the client's real problem"                         |
+| **Notable work**     | 11 yrs in business, 10–15 engineers on big teams, enterprise clients        | Custom Claude-Code harness, projects like *insin* (apt-get-style edge updater) & *Keller* |
+
+---
+
+## Key Themes & Insights
+
+### 1. The question changed: not "can AI code?" but "how do you use it?"
+The cost of writing code trends toward zero, so the leverage moves entirely to *how* AI is directed.
+> "It's not a question *if* AI can write software anymore — it's just a question of *how* you use it."
+
+### 2. Team structure collapses from ~8 people to 2–3
+No more scrum master + PM + requirements engineer + a big dev team. Instead: one coordination/ownership role plus one or two people managing coding agents, sharing responsibilities.
+> "Teams will be two or three people and they will share these roles… one person with a coordination role and one or two who manage the coding agents. That's it."
+
+### 3. "Bring your own harness" — but it hits a wall in the enterprise
+Eugene's thesis (echoed by many practitioners he cites): every developer should build a personal *harness* on top of Claude Code because knowing every detail makes it far more effective. He demoed his own: a Telegram-like UI with one agent per project, inter-agent messaging, per-agent memory, and a "done thinking" signal so you don't babysit the console. Tools referenced: **Conductor** (isolates a git worktree per chat, automates PRs/merges), plus "open clock, Hermes, paperclip."
+
+Sebastian's crucial counterpoint: this **does not scale to large or regulated organizations**. Compliance and liability make ad-hoc, per-developer setups impossible.
+> "From a compliance perspective I can guarantee you that bring-your-own-harness will not be the way forward… it has to be a company-managed resource. We cannot let everyone pick their own setup."
+
+**→ Business opportunity identified:** *scalable, manageable, company-standard harnesses for larger engineering teams.* Sebastian explicitly frames this as "the interesting market."
+
+### 4. Enterprise reality is far more locked-down than the indie world
+Sebastian's biggest clients: engineers can't use their own laptops — only a centrally managed VM, **zero ability to install their own tools.** Reference points: a Roche SAP transformation ran ~1,200 engineers for years; banks first banned AI outright and are now cautiously adopting it "because it's just so good."
+
+### 5. Seniors are now *more* valuable; juniors are being squeezed out
+Counter-intuitively, AI has raised demand for seniors and made juniors "completely irrelevant" in the market, even though a junior + Claude could in theory produce the same output.
+- **Why seniors win:** 20 years of experience = knowing *where things typically go wrong*, so you don't let the AI make those mistakes. "AI does the same mistakes humans do because it's trained on our mistakes."
+- **The junior risk (a security argument):** the habit of clicking "yes… yes… allow for all future" is how "API keys are leaked, databases get dumped or deleted." A junior can't evaluate a 250-line bash script; a senior at least *could*.
+> "Give a junior fresh out of university access to this almighty Claude and then access to the codebase — they will [wreck] it in two days."
+
+### 6. Ownership & product thinking is the durable human skill
+The recurring "profile picture" story: an engineer implemented "change your photo," ticked every acceptance criterion, but shipped it *ugly* (visible in the corner) because they never looked at the actual result. That's the absence of **ownership**.
+- Ownership = putting yourself in the user's/customer's shoes and understanding what they'll expect — a mindset/personality trait, not a task list.
+- Reframe the work: **stop thinking "what needs to be done" (tickets); start thinking "what problem needs to be solved."**
+> "No one ever needed a programmer… people have problems that you are solving."
+- AI forces the issue: if you don't understand what to build, "you will simply not be an engineer anymore" — or you get closer to the product and the software gets *better* (product-wise, if not always technically).
+
+### 7. The planning/waterfall debate: coordination overhead can exceed the work
+A colleague (Daniel) floated returning to waterfall. Sebastian disagrees — with AI, "we don't have time for planning." Concrete evidence:
+- On a small two-person project (each ~1 day/week), Sebastian is **faster alone**: the effort to synchronize who-does-what and how-it-integrates exceeds the speed of just prompting it himself.
+- **Printer anecdote:** a new printer had to work in 2 days via an unfamiliar direct-printing protocol in Java (which he'd never written). Explaining it to a remote engineer wouldn't have made the deadline; he went on-site and Claude Code solved it in ~30 minutes. His edge wasn't coding — it was *knowing how to instruct and verify* the result.
+
+### 8. Connections are everything — the standout insight
+Eugene's core unsolved problem (stuck ~6 months): how to build a professional network. The framing that lands:
+- Claude **levels pure programming skill.** 20 years of experience vs. a fresh grad, same Claude subscription → similar output. The *only* real differentiator becomes the ability to communicate with clients and understand their problems.
+- **Real, in-person connection is the one thing AI can't commoditize** — and it gets more valuable as AI floods everything else. Soon you won't be able to tell bots from humans on LinkedIn, or even on a phone call. "In 10 years… zero" ability to tell.
+- **What actually works for winning business:** showing up in person 2–4 days/week (business lunches, networking events, conferences, open days). **What doesn't:** sales agencies, cold calling, email marketing, LinkedIn campaigns, content, SEO — "Big zero." Every real long-term customer came through personal network.
+> "The only way to get a real connection is to stand face to face in the same room with someone, shake their hand, and have a conversation."
+- **Mechanics of a connection:** it forms not on the first meeting but when you meet the *same* person in *different* circumstances → recognition value → trust → referrals. ("Oh, there's this guy, Eugene — I met him a couple of times, he's real, I trust him.")
+- **Be memorable in your humanness:** lead with something human (renovating a house, two kids, a cat, a dog) — not "I run a software company," which everyone forgets. Because everyone now uses the same AI tools, *everything online looks identical*; humanity is the differentiator. (Virtido's playful `humans.verti.com` / "human badge on LinkedIn" is a riff on exactly this.)
+
+### 9. Decouple identity from profession (the philosophical turn)
+Older generations tie identity to their job ("I *am* a doctor"). As many professions collapse into "prompt the AI," they'll lose obvious societal value. The advice: learn to separate *who you are* from *what you do professionally*, or "we will feel worthless in a couple of years."
+> "Fundamentally I'm Eugene — I'm not a programmer. But I need to work on that."
+
+### 10. AI's value extends well beyond programmers
+Non-technical, high-leverage uses discussed: profile ~2,000 LinkedIn/HR contacts into Obsidian, build RAG/search over your own collected information, spot who's hiring and pitch as a contractor. "You can put your whole life into a RAG." You don't need to be a programmer to benefit.
+
+### 11. Two smaller-but-sharp side points
+- **Open source will grow because of AI.** When writing code costs ~nothing and most code isn't high-value, people will give it away. (Eugene's more cynical read: OSS is largely marketing; every OSS dev cites *The Cathedral and the Bazaar*.)
+- **Legacy/hobby niches persist.** A few holdouts survive (e.g., COBOL engineers in banks — no training data for AI), plus people who code for the love of it "like driving an old-timer car" — but not where time, quality, and money matter.
+- **On outsourcing economics (opening exchange):** great engineers exist everywhere (India has as many as Ukraine/Russia); the problem is that a *low-cost expectation* selects for bad code. Pay $10k/month and you get excellent people; an $800/month hire won't beat a good, well-paid engineer.
+
+---
+
+## Points of Tension / Disagreement
+
+- **Personal vs. company-managed harness:** Eugene champions bring-your-own; Sebastian says compliance kills it at scale (and that gap *is* the business).
+- **Planning:** Daniel (absent) wants waterfall back; Sebastian says coordination overhead now outweighs the work itself.
+- **Open source motivation:** Eugene sees it mostly as marketing/"gambling for questionable results"; Sebastian expects *more* OSS as code becomes nearly free to produce.
+- **Networking channels:** Eugene is invested in LinkedIn/articles; Sebastian bluntly calls online outreach a "waste of time" versus in-person.
+
+---
+
+## Standout Conclusions
+
+1. **Move up the value chain — from writing code to owning outcomes.** The engineer's job is shifting from "produce the solution" to "understand and frame the problem, then direct and verify the AI."
+2. **Seniority = risk reduction.** The senior's real product is judgment: preventing expensive mistakes and catching dangerous agent actions.
+3. **The enterprise-harness market is wide open.** Someone will make money providing compliant, centrally managed AI tooling for large regulated teams.
+4. **Relationships are the last non-commoditized asset.** When skill and online presence are equalized by AI, in-person trust becomes the scarce, decisive edge.
+5. **Protect your identity.** Tie your sense of self to *who you are*, not a job title that AI may hollow out.
+
+---
+
+## Memorable Quotes
+
+- "It's not a question *if* AI can write software anymore — it's just a question of *how* you use it."
+- "No one ever needed a programmer… people have problems that you are solving."
+- "Give a junior… access to this almighty Claude and then access to the codebase — they will [wreck] it in two days."
+- "The only way to get a real connection is to stand face to face in the same room with someone, shake their hand, and have a conversation."
+- "We tried sales agencies, cold calling, email marketing, LinkedIn campaigns, content, SEO. Zero. Big zero… Every real long-term customer has come through [personal network]."
+- "We need to learn to decouple our identity from the thing we do professionally."
+
+---
+
+## Actionable Takeaways
+
+**For Eugene (his stated problem — building a network):**
+- Reallocate time from LinkedIn posts/articles to **recurring in-person events** (aim for the same circles repeatedly to build recognition value).
+- Prepare a **memorable, human self-introduction** that isn't your job description.
+- Treat the network as the moat, not the code — the coding is already commoditized.
+
+**For engineers generally:**
+- Practice **product ownership**: always look at the actual result a user sees, not just the acceptance criteria.
+- Shift vocabulary from "tasks/tickets" to "problems and desired outcomes."
+- Build (or learn) a **harness** for personal leverage — but expect a company-standard one at any regulated employer.
+- **Read what you approve.** Don't reflexively "allow all"; that habit is a security incident waiting to happen.
+
+**For businesses / founders:**
+- The **compliant enterprise-harness** space is an underserved market.
+- Assume digital outreach converges to noise; **invest in face-to-face relationship-building** as the durable channel.
+
+---
+
+## Open Questions Raised (Unresolved in the Interview)
+
+- How does AI actually transform *huge* enterprise programs (the ~1,200-engineer, multi-year kind)? Sebastian is candid that he doesn't know.
+- How do you unify wildly different personal workflows into one company process? (Eugene and his collaborator spent a month and couldn't.)
+- Concretely, how does an individual engineer *build* a connections network from a standing start? (Sebastian offers principles; the step-by-step remains open.)

raw/sources/ИИ глупый!.md

@@ -0,0 +1,63 @@
+# Выводы по видео
+
+**Источник:** https://www.youtube.com/shorts/P4eWd2jvz4k
+**Название:** ИИ глупый! #ии #ai #бизнес
+**Длительность:** 1:28
+**Язык:** русский
+
+---
+
+## Главный тезис
+
+ИИ выглядит «глупым» не потому, что модель плохая, а потому, что ей систематически недодают **две вещи**: **контекст** (память о вашем конкретном бизнесе) и **harness** — набор правил, по которым модель обязана рассуждать. Без них даже сильнейшая модель отвечает как чужой эксперт, а не как ваш сотрудник.
+
+---
+
+## Аналогия, которую строит автор
+
+Представьте компанию, продающую оборудование, и два источника ответа на вопрос *«как у нас закроется месяц по продажам?»*:
+
+| Кого спрашиваем | Что ответит | Почему |
+|---|---|---|
+| 10 нобелевских лауреатов и докторов наук | «По вашей категории бизнеса, согласно отраслевому отчёту, в среднем по России продажи падают/растут на ~5%» | Умные, но говорят про *среднее по рынку* — к вашему бизнесу это отношения не имеет |
+| Рядовой сотрудник вашей компании | Ответит точнее и ближе к реальности | У него есть **контекст**: он видит вашу воронку, клиентов, сезонность, сделки |
+
+Вывод: **ум без контекста проигрывает контексту без ума.** Именно это происходит с ИИ по умолчанию — он умный, но пустой.
+
+---
+
+## Что нужно дать модели
+
+### 1. Память / контекст
+Данные о вашей компании: продукты, воронка, клиенты, история сделок, внутренние документы, метрики. Как только этот контекст оказывается «в голове» у эксперта — качество ответа растёт **на порядки** (автор говорит: *«в десятки раз, может быть, в миллион»*).
+
+Практически это значит:
+- RAG над корпоративными данными
+- Долгосрочная память ассистента
+- Инжест CRM/ERP/документов в тот же контекст, где работает модель
+
+### 2. Harness — набор правил работы модели
+Не просто промпт, а **инженерная обвязка**: что модель обязана проверить, каким инструментам довериться, как формировать ответ, что запрещено. Это превращает LLM из «энциклопедии со средним по больнице» в **процедурного агента**, который отвечает так, как отвечал бы ваш сотрудник, знающий и данные, и внутренние правила игры.
+
+---
+
+## Формула из видео
+
+**Сильная модель + контекст вашего бизнеса + harness = ответ уровня сотрудника, а не постороннего эксперта.**
+
+Убери любой из трёх компонентов — получишь либо «умный, но общий» ответ, либо «конкретный, но недисциплинированный», либо «глупый ИИ».
+
+---
+
+## Практические takeaways
+
+- Если ИИ у вас «не работает» — почти всегда проблема не в модели, а в **отсутствии контекста и обвязки**, а не в интеллекте модели.
+- Прежде чем менять модель на «более умную», подайте ей то, что знает ваш рядовой сотрудник.
+- Инвестировать стоит в **инфраструктуру контекста** (данные, память, интеграции) и в **harness** (правила, проверки, тулинг) — это то, что даёт результат ×10…×1000, а не смена версии модели.
+- Метрика зрелости AI-внедрения: *может ли модель ответить на вопрос про ваш бизнес точнее, чем сторонний консультант?* Если нет — не хватает контекста или harness'а.
+
+---
+
+## Кому полезно
+
+Владельцам бизнеса и продактам, которые внедряют LLM во внутренние процессы и разочарованы «общими» ответами; инженерам, строящим корпоративных ассистентов; всем, кто выбирает между «взять модель побольше» и «дать модели правильные данные и правила».

raw/sources/Скиллы на базе git — новая память AI-агентов.md

@@ -0,0 +1,444 @@
+#ai #agents #video #webinar
+
+# Выводы по видео
+
+**Источник:** https://www.youtube.com/watch?v=a-NIeMB-Hj8
+**Название:** Скиллы на базе git — новая память AI-агентов. Мой опыт
+**Автор:** Константин (Сбер, команда разработки ГигаЧата, R&D по агентам)
+**Длительность:** 53:09
+
+---
+
+## Главный тезис
+
+**Скиллы, объединённые с данными пользователя и алгоритмами автоулучшения — это новая память AI-агентов, к которой все агентные системы в итоге придут.** Это не просто «набор навыков», это принципиально новая архитектура памяти, в которой:
+
+- инструменты (как их вызывать)
+- данные (то, над чем работаем)
+- история использования (что уже сделано)
+
+лежат вместе в одном git-репозитории, и харнесс сам решает, что подгружать в контекст в конкретный момент.
+
+Автор ведёт слушателя от исторического рекапа к практическому опыту и заканчивает моделью «трёхуровневого агентного цикла», который, по его прогнозу, будет доминировать в 2027.
+
+---
+
+## Часть 1. Рекап эволюции агентов (как мы пришли к харнессам)
+
+### Таймлайн
+
+| Период | Что появилось | Что это дало |
+|---|---|---|
+| Начало 2023 | LLM / ChatGPT (не чатовая) — задал вопрос, получил ответ | Нет памяти, нет инструментов, одноходовой обмен |
+| Лето 2023 | Концепция **ReAct-агентов** — LLM может либо ответить текстом, либо вызвать функцию | Впервые появился «агентный цикл»: вызов инструментов → рефлексия → изменение поведения. Мир научился давать LLM обратную связь через tools |
+| 2023–2024 | Цепочки вызовов, роли, первые агентные SDK, векторные БД, **RAG**, JSON-структурированные ответы | Агент становится сложнее, начал использовать внешние знания |
+| 2024 | Цепочки → **графы**. LangGraph. Мультиагентные подходы (агент-планировщик, агент-критик, третий агент отвечает). Фреймворки: AutoGen, CrewAI. **Скаффолдинг** — сложная конструкция вокруг LLM | Пик технической сложности агентов |
+| Конец 2025 | Внезапное **упрощение**. Оказалось, что достаточно простого агента с ~10 базовыми функциями работы с файлами, чтобы решать сложные задачи. Начало эпохи **универсальных агентов = харнессов** | Резкое снижение сложности при росте возможностей |
+| 2026 (сейчас) | Универсальные агенты (харнессы) вкладываются во внешние циклы (**Ralph loop**), запускаются на дни/недели. Появляется **AI factory** (полностью автономная работа без human-in-the-loop) | Human-in-the-middle → man-on-the-middle → полное отсутствие человека |
+| 2027 (прогноз) | Доминирование скиллов + агентных циклов | — |
+
+### Эволюция ролей человека
+
+- **Prompt-инженер** (текстовое описание задачи) → **Context-инженер** (сложный prompt с памятью, RAG, структурами) → **Harness-строитель** (архитектура харнесса, политики, песочница) → сейчас поднимается **Loop-инженер** (построение циклов вокруг агента: CI/CD, back-pressure, метациклы)
+
+### Ключевая мысль этой части
+
+«За полгода всё меняется». Ничего фундаментального в этой сфере пока нет. Только что утвердили MCP — уже все хотят A2A. Корпорации от этого страдают.
+
+---
+
+## Часть 2. Что такое харнесс
+
+### Определение и метафора
+
+**Харнесс** (в переводе — упряжка) = агент + инструменты. LLM — источник силы. Набор инструментов — упряжка. Поле задач — данные. LLM, запряжённая в инструменты, «тянет их по пространству данных», превращая необработанные задачи в решённые.
+
+Важно: **задачи разные, а способ их обработки одинаковый** — одна и та же упряжка (харнесс) решает большое количество разнородных задач.
+
+### Стандартный набор инструментов харнесса (~30–40 max)
+
+| Категория | Инструменты |
+|---|---|
+| Файлы | Read, Edit, Write |
+| Shell | Bash |
+| Поиск | Grep, Glob, WebSearch |
+| Планирование | TodoWrite/TodoRead |
+| Расширение | Спавн субагентов |
+
+**Предел:** >30–40 встроенных тулов не встречается ни в одном популярном харнессе. Больше 100 — LLM (даже Fable 5) начинает путаться, и контекст уходит с огромной скоростью, потому что каждый тул подкладывается в вызов.
+
+### Из чего состоит хороший харнесс
+
+1. **Короткий system prompt** («используй инструменты, чтобы решить задачу»). Чем короче — тем лучше.
+2. **Набор стандартных тулов** (см. выше).
+3. **Runtime loop** — тот же ReAct-цикл: вызывай тулы, пока не решишь.
+4. **Управление контекстом** — своевременная суммаризация, запуск субагентов без передачи полного контекста.
+5. **Стандартизованные ключевые файлы** — AGENTS.md, CLAUDE.md, GEMINI.md для описания проекта; директории `skills/` со `SKILL.md`; подключение MCP-серверов.
+6. **Устойчивость к нештатным ситуациям** — обрывам соединения, ошибкам ОС, отключению VPN.
+7. **Интерфейс** — консольный CLI, чат, мессенджер.
+
+### Два режима работы харнесса (де-факто стандарт)
+
+| Режим | Описание | Термин |
+|---|---|---|
+| Интерактивный | Постоянные уточнения у человека («можно я прочту этот файл?») | Human-in-the-middle → man-on-the-middle (человек уже не контролирует, а лишь присматривает) |
+| Автономный (fire-and-forget) | Запуск через CLI с задачей аргументом; агент решает и возвращает результат | Позволяет встраивать харнессы в CI/CD и строить цепочки последовательных вызовов |
+
+### Популярные харнессы
+
+- **Claude Code**
+- **Codex CLI**
+- **Cursor** (в каком-то смысле)
+- **OpenClaude** (форк Claude Code)
+- **Hermes** — построен полностью вокруг скиллов
+- И почти все агенты «последнего поколения»
+
+### Личный опыт: харнессы — must-have (три хакатона)
+
+| Хакатон | Результат | Технология |
+|---|---|---|
+| Interpress-Ex Challenge | 7 место | Свой харнесс, запущенный в бесконечном цикле на выходные. **Ни одну задачу глазами не читал** — просто оставил агента работать |
+| Snowbase Camp | 3 место общее / 1 по техническим метрикам | Утечённый Claude Code в качестве бэкенда + красивый фронт. Идеально, когда задача плохо понятна заранее |
+| BitGen | ~топ-20 | Обнаружил инсайт: **19 из 20 команд-топов делали свои решения на харнессах**. Все, кто участвует в интересных хакатонах, уже перешли на них |
+
+---
+
+## Часть 3. Эволюция инструментов агентов
+
+### Три поколения
+
+```
+Tools (2022–2024) → MCP (кон.2024–2025) → Skills (2025→)
+```
+
+### Tools (2022–2024)
+
+- Функция, помеченная тегом, подкладывается в вызов модели.
+- Каждый тул попадает в контекст.
+- Библиотеки от LangChain, LlamaIndex.
+- **Проблема:** приходилось каждый раз писать или адаптировать самому.
+
+### MCP-серверы (конец 2024 → 2025, Anthropic)
+
+- Локально развёрнутый сервер, подключаемый к агенту стандартным протоколом.
+- К агенту сразу добавляется несколько готовых тулов.
+- Появились маркетплейсы MCP.
+- **Проблемы:**
+  - Многие MCP содержат десятки тулов → быстро съедается контекст (>100 функций = хаос).
+  - Безопасность: если сервер подгружается по сети, поведение агента может неожиданно измениться.
+- Автор **не хейтит MCP** — проблемы во многом уже решены, MCP имеет право на жизнь.
+
+### Skills (2025 →) — главная тема доклада
+
+**Скилл** = директория + джентльменское соглашение.
+
+Состав:
+- `SKILL.md` — как работает этот скилл
+- Инструменты (bash-скрипты, Python-код) в той же директории
+- (новое предложение автора) — **данные** прямо в этой же директории
+
+**Ключевое преимущество: двухэтапная загрузка описания скилла**
+
+| Что | Что видно всегда | Что подгружается по требованию |
+|---|---|---|
+| Короткое описание | Попадает в System Prompt агента → он знает, что скилл существует | — |
+| Длинное описание | — | Только когда агент решил «мне нужен этот скилл» — он заходит в директорию и читает SKILL.md |
+
+Это позволяет иметь **очень много скиллов без переполнения контекста**. Пример: Hermes у автора начинался с 56 скиллов, через пару недель работы вырос до 100 — и всё равно работает. С тулами такое невозможно (2 запроса — и контекст закончился).
+
+**Стоимость создания:**
+- MCP-сервер: нужен разработчик.
+- Скилл: нужно уметь писать тексты (можно даже не на английском). Распространение — через мессенджер / GitHub / куда угодно.
+
+### Skills vs MCP — когда что использовать
+
+| Ситуация | Что выбрать |
+|---|---|
+| Не знаешь, какие задачи будет решать агент | Skills |
+| Задачи разнообразные, разные тулы для разных сценариев | Skills |
+| Количество тулов 5–50 | Skills |
+| Агент узкоспециализированный, задачи однотипные | MCP |
+| Для каждой задачи нужен один и тот же набор тулов | MCP |
+| Мало тулов и агент решает однотипный поток задач | MCP |
+
+**Оговорка:** грань стирается. Например, Claude Code использует MCP не напрямую, а превращает их в скиллы (файлик подкладывается, функции сразу в контекст не попадают). В этом режиме минусы MCP во многом исчезают.
+
+### Что автор считает «недостающим» в классическом скилле
+
+Как «архитектура фон Неймана без данных»: код есть, а данных нет. **Предложение — добавлять в скилл данные и историю использования прямо внутри git-репозитория.**
+
+Тогда скилл раскрывается как:
+- короткое описание
+- длинное описание
+- инструменты
+- **+ данные**
+
+---
+
+## Часть 4. Skill-first архитектура на базе git
+
+### Почему именно git
+
+Git-репозиторий как контейнер скилла + данных даёт:
+
+1. **Skill-first архитектура:** к одному скиллу можно подключить несколько разных агентов (Claude Code для больших операций, Hermes через Telegram для быстрых, OpenClaude — из любой точки).
+2. **Встраивание в CI/CD:** пайплайн работает с тем же git-репозиторием.
+3. **Совместная работа команды:** можно делиться скиллом с коллегами.
+4. **Решение проблемы коллизий:** современные модели на харнессах научились решать merge-конфликты. Раньше нужен был человек — сейчас нет. Это позволяет строить системы с параллельной работой многих акторов **на голом git**, без транзакционной БД. (Не для платежей, конечно, но для многого — да.)
+
+### Обязательные правила в AGENTS.md для такого скилла
+
+- **Всегда `git pull` в начале работы** (последние данные).
+- **Сразу `push` + `commit` после работы** (не терять правки).
+- **CI как «back-pressure» (обратное давление)** — обязательно прописать в AGENTS.md. Возвращает агента в рамки, если он начинает «расползаться» — придумывать себе новые задачи, отклоняться от того, что описано в AgentsMD. Без CI изменения накапливаются, агент уходит в свою сторону.
+
+---
+
+## Часть 5. Личные скиллы автора (ежедневное использование)
+
+### Список скиллов
+
+| Скилл | Что делает | Особенность |
+|---|---|---|
+| ДНК / медицина | Анализ ДНК-тестов и секвенирования всей семьи | Разбирается ниже |
+| Рекомендации | Фильмы, музыка, игры | Основан на выгрузке ~1000 оценок с КиноНавигатора |
+| Планирование поездок | Командировки, документы, брони | Разбирается ниже |
+| HR / оценка резюме | Автоматическая оценка присланных резюме | Разбирается ниже |
+| Управление финансами | Мониторинг платежей, показания счётчиков, долги | — |
+| R&D по агентам (командный) | Исследование агентов, много людей одновременно | — |
+
+### Скилл 1. ДНК и медицина
+
+**Данные:**
+- ДНК-тесты (Atlas, Genotek) на всех членов семьи
+- ДНК-секвенирование — ~100 ГБ прочитанного ДНК
+- По каждому человеку — шаблон: пол, возраст, вес, лекарства, особенности
+
+**Возможности:**
+- Задавать вопросы про себя: какие лекарства эффективнее, какие виды спорта подходят, стиль обучения
+- Сравнивать двух людей — кто более общительный, кто усидчивый (звучит как слоп, но работает)
+- Автоматическая сборка сырого ДНК в единую цепочку (у автора это заняло неделю руками — Claude сделал за сутки)
+- Скачивание референсного генома и сравнение
+- Дашборд в стиле компьютерной игры: перки, дебафы, распределение характеристик
+
+**Впечатляющий сценарий:** У каждого человека ~100 уникальных мутаций (из них 10 полезных, 10 вредных, 80 нейтральных в среднем). Большинство науке неизвестны.
+- Автор попросил Claude проанализировать конкретную мутацию.
+- Claude нашёл, что мутация не описана нигде.
+- Определил, к какому гену относится.
+- Сам обратился к **AlphaFold** (Google) — ИИ для рендеринга сворачивания белков.
+- Отрендерил белок автора и сделал вывод: белок сворачивается корректно, мутация ничего не значит.
+
+**Валидация:**
+- Автор сравнил разные ДНК-тесты одного человека (Atlas / Genotek / секвенирование) → совпадение 99.95%. Лаборатории не жульничают.
+
+**Контекст (важные истории «AI в медицине»):**
+- **Reddit-пользователь через ChatGPT + MRI-снимок** нашёл сложную взаимосвязь болей в спине с дефицитом B12. Пошёл к врачу — подтвердилось. История опубликована в блоге OpenAI.
+- **Пол Конингем** — его собака заболела раком. Он с помощью ChatGPT + AlphaFold **сам разработал индивидуальную мРНК-вакцину**, заказал печать в лаборатории, вколол собаке. **Собака была вылечена.**
+
+**Масштаб:**
+- Референсный геном человека: **3 млрд долларов, 13 лет** работы.
+- Свой полный геном сегодня: **~1000 долларов и один вечер** работы ноутбука + Claude.
+
+**«Домашняя работа над исходниками себя»** — то, что раньше было доступно только большой науке.
+
+### Скилл 2. Планирование поездок
+
+**Структура скилла:**
+- Шаблон командировки
+- Список людей, которые могут поехать (со всеми документами)
+
+**Сценарий:**
+1. Открыл Cursor → «создай мне поездку в Китай»
+2. Ушёл, поехал домой
+3. В Telegram (через Hermes или OpenClaude, подключённый к тому же скиллу) — фотография купленного билета
+4. Агент делает `git pull`, добавляет билет в структуру поездки, кладёт PDF в директорию поездки, коммитит
+5. В любой момент можно спросить: «что осталось по поездке?» — он ответит: «не забронирована гостиница, между самолётами 2 часа — даже не пытайся»
+
+**Автозаполнение** — успешно заполнил заявление на визу практически без ошибок.
+
+### Скилл 3. HR / оценка резюме
+
+**Как возник:** стихийно. Автор кинул Hermes'у резюме (картинка без текстового слоя), сказал «оцени».
+- Hermes подтянул OCR
+- Первая оценка была нерелевантной
+- Автор давал фидбэк на каждой итерации:
+  - «человек ищет только удалёнку, а у нас гибрид — таких не рассматриваем»
+  - «когда у человека есть GitHub, обязательно заходи, анализируй код, оценивай impact в open source»
+- **10–20 итераций** — скилл сам себя корректировал
+
+**Результат:** «идеальный HR-скилл». Кидаешь резюме → получаешь ответ → соглашаешься, если смотришь глазами. **Ошибок ~10%.**
+
+**Правовая оговорка:** резюме приходят напрямую в личку → есть моральное право на обработку. Закон о персональных данных соблюдён.
+
+---
+
+## Часть 6. Автоулучшение скиллов (пример Hermes)
+
+Hermes построен **полностью вокруг скиллов** — не только использует, но и создаёт их автономно.
+
+### Критерий автосоздания скилла
+
+Если Hermes на какую-то задачу потратил **>5 tool calls**, он сразу рассматривает: «а не стоит ли это запомнить как скилл».
+
+### Механизм куратора (два слоя)
+
+1. **Прунинг (обрезание неиспользуемого)**
+   - Скилл не использовался **30 дней** → он делается неактивным (в системе есть, но его description не подкладывается или подкладывается уменьшенным).
+   - Скилл не использовался **90 дней** → архивируется, полностью исчезает из системы.
+
+2. **Консолидация (раз в 7 дней)**
+   - Анализирует, можно ли попарно объединить мелкие скиллы в более крупный.
+   - Не даёт системе раздуться до тысяч скиллов, чьи «короткие описания» съедят весь контекст.
+
+### Итог
+
+Скиллы **эволюционируют автоматически**. Если они ещё и с данными — они становятся основой системы и **новой памятью агента**.
+
+Раньше память делали на:
+- поиск в переписках
+- RAG на извлечении фактов о пользователе
+
+Теперь **вся информация о пользователе лежит в скиллах**, подгружается ровно тогда, когда скилл активирован, и харнесс сам решает, что попадёт в контекст (а не RAG «за него» до начала работы модели).
+
+---
+
+## Часть 7. Агентные циклы (три уровня)
+
+Это следующая большая тема после харнессов. По прогнозу автора — «стрельнёт» в 2027.
+
+### Уровень 1: Inner Loop (React-цикл внутри харнесса)
+
+Задача → вызов тулов → ... → решено → текстовый ответ. Классика.
+
+### Уровень 2: Outer Loop / Ralph Loop (придумал Джеффри Хантли)
+
+Харнесс засунут в бесконечный `while true`:
+
+```bash
+while true; do
+  claude --dangerously-skip-permissions -p "реши задачу" || true
+done
+```
+
+Позволяет агенту работать днями/неделями. Хитрости против «слопа»:
+- **Back-pressure через CI/CD** — если агент слетает с катушек, CI возвращает его
+- **Валидация качества кода**
+
+**Почему это работает:**
+- Позволяет работать **без раста контекста**.
+- Когда контекст растёт → в какой-то момент кончается → суммаризация → потеря данных → **агент тупеет** (кто пользовался OpenClaude — «сегодня решил задачу, завтра ту же задачу забыл»).
+- У модели есть **смарт-зона** — примерно первая треть контекста, где она максимально «умная». Дальше — глупеет, даже если у неё миллионный контекст.
+- Ralph Loop позволяет **постоянно оставаться в смарт-зоне**.
+
+### Уровень 3: Meta Loop (авторский, не общепринятый)
+
+Проблема, подсвеченная **Андреем Карпатым** — **схлопывание (collapse)**. Если давать модели одну и ту же задачу постоянно, она «решает разными способами», но фактически всеми одним и тем же способом с разными словами.
+
+**Пример Карпатого:** попросите модель рассказать анекдот, потом ещё один, потом ещё. На пятый раз — тот же анекдот, только место действия и герои другие.
+
+**Решение (авторское Meta Loop):**
+- В какой-то момент **полностью останавливаем цикл**
+- **Полностью зачищаем все данные, которые агент создал**
+- Данные складываем в архив, который агент изначально не видит
+- Запускаем цикл с чистого листа → агент идёт другим путём
+- Через какое-то время он находит архив, распаковывает, обнаруживает свои прошлые данные → но уже пошёл в другую сторону
+- Это позволяет **исследовать задачу в разных направлениях**
+
+Хорошо для исследовательских задач, когда сам до конца не понимаешь, что решаешь.
+
+### Пример Ralph Loop в коде
+
+```bash
+while true; do
+  claude "реши задачу"   # inner loop внутри
+done                     # outer loop = Ralph
+# meta loop уже не в коде
+```
+
+---
+
+## Часть 8. Q&A — важные тезисы
+
+### Про фундаментальность скиллов
+
+- Ничего фундаментального в LLM-движухе нет.
+- Полгода — и всё меняется.
+- Корпорации страдают: «утвердили MCP на архкоме → все хотят A2A → утвердили A2A → снова поменялось».
+
+### Кого автор нанимает
+
+- Команда R&D, поэтому смотрит на:
+  - **Широкий технический кругозор**
+  - **Автономность** — full-stack, сам может найти задачу, прикопать, решить
+- Знания по агентам «доберёт в процессе».
+- Круто, если есть **фундаментальная математика и понимание устройства обучения**, но не стоп-фактор.
+
+### Какие данные класть в скилл (нет стандартов)
+
+- Пока — только интуиция и статистика использования.
+- Автор в геномный скилл кладёт **200 ГБ данных**, в скилл поездок — **100 КБ**. Оба работают одинаково хорошо.
+- «Потолок сверху ещё не нащупал.» Харнессы умные — насыщение данными скилл **не убивает** (в отличие от RAG и классических промптов).
+
+### Что ещё можно добавить в архитектуру агента (вопрос из зала)
+
+- Слушатель предложил концепцию: LLM → tools → skills → auto-improvement → «больше ничего добавить нельзя?»
+- Автор: **не хватает восприятия мира / квалиа**.
+- Пример: «до автомойки 5 минут ехать или 10 минут идти пешком — как лучше?» Нейронка отвечает: «Пешочком сходите, всего 5 минут». Не понимает, что без машины на автомойке делать нечего.
+- **Возможно помогут world-models** (модели мира), но как их сделать — открытый вопрос.
+
+### Прикладной пример: авто-улучшение агента
+
+Автор построил скилл, где:
+- **Данные:** бенчмарк, который надо улучшить + код агента
+- **Задача агенту:** улучшай себя на бенчмарке в цикле
+- Идея взята у Карпатого (репозиторий назывался «autoagent»):
+  - Агент выдвигает гипотезу
+  - Меряет бенчмарк
+  - Хорошая гипотеза → фиксирует
+  - Плохая → откатывает
+- **Стартовая база:** слабый ГигаЧат, решал 1 из 89 задач бенча
+- **Результат за выходные:** **11 задач из 89**
+- **Рост в 11 раз.**
+- Автор проверил всё — «сделал адекватно, нигде не заоверфитился».
+
+---
+
+## Сквозные принципы доклада
+
+1. **Простота бьёт сложность.** Универсальный агент с ~10 функциями работы с файлами делает больше, чем сложный мультиграф.
+2. **Задачи разные — способ обработки одинаковый.** Один харнесс на всё.
+3. **Данные должны жить рядом с инструментами.** Скилл без данных — как «фон Нейман без данных».
+4. **Git — универсальный контейнер** для скилла + данных + истории + коллаборации.
+5. **Контекст — самый ценный ресурс.** Двухэтапная загрузка скиллов, back-pressure через CI, оставаться в смарт-зоне.
+6. **Автономность важнее контроля.** Human-in-the-middle → man-on-the-middle → AI factory.
+7. **Автоулучшение обязательно.** Куратор, прунинг, консолидация, генерация новых скиллов.
+8. **Циклы — новая парадигма.** Inner + Outer (Ralph) + Meta.
+9. **Ничего фундаментального нет.** Готовьтесь переучиваться каждые полгода.
+
+---
+
+## Actionable takeaways для практика
+
+1. **Строй агентов на харнессах** (Claude Code / OpenClaude / Hermes / Cursor). Это уже must-have.
+2. **Не переходи с ходу на MCP** — оцени: количество тулов 5–50 → скиллы. >50 однотипных → MCP.
+3. **Клади данные в тот же git-репозиторий, где скилл.** Это не убьёт агента.
+4. **Прописывай в AGENTS.md жёсткие правила:**
+   - `git pull` в начале
+   - `push` + `commit` в конце
+   - CI как back-pressure
+5. **Автоматизируй создание скиллов** — если задача съела >5 tool calls, это кандидат в скилл.
+6. **Внедри куратора:** прунинг неиспользуемого (30/90 дней), консолидация раз в неделю.
+7. **Оборачивай агента в Ralph Loop** для многодневных задач: избегай раста контекста и суммаризации.
+8. **Держи агента в первой трети контекста** (смарт-зона), даже если у модели миллионный контекст.
+9. **Для исследовательских задач** — Meta Loop: периодически сноси всё в архив, стартуй с нуля.
+10. **Хочешь стать HR/медиком/финансистом для себя?** Начни с одного скилла с данными по своему кейсу. Итерируй фидбэком — через 10–20 циклов будет работать.
+
+---
+
+## Кому полезно
+
+- **Разработчикам агентов** — карта перехода от tools → MCP → skills и практическая схема хранения в git.
+- **Тимлидам R&D** — фреймворк оценки: скиллы vs MCP, back-pressure через CI, куратор.
+- **Продактам AI-продуктов** — понимание, куда движется парадигма (skill-first архитектура, harness как бэкенд, memory-as-skills).
+- **Индивидуальным biohacker'ам / self-quantifiers** — реальный кейс «Claude + AlphaFold над своим ДНК за $1000 и вечер».
+- **Всем, кто участвует в AI-хакатонах** — 19 из 20 победителей уже строят решения на харнессах. Догоняйте.