commit b75730fda36b13101c64621e34895364cd477669 Author: meels Date: Tue Jul 28 13:00:04 2026 +0200 chore: initial commit of vault before dashboard work diff --git a/.gitignore b/.gitignore new file mode 100644 index 0000000..933a70d --- /dev/null +++ b/.gitignore @@ -0,0 +1,3 @@ +.obsidian/workspace.json +.obsidian/workspace-mobile.json +.obsidian/cache diff --git a/.obsidian/app.json b/.obsidian/app.json new file mode 100644 index 0000000..9e26dfe --- /dev/null +++ b/.obsidian/app.json @@ -0,0 +1 @@ +{} \ No newline at end of file diff --git a/.obsidian/appearance.json b/.obsidian/appearance.json new file mode 100644 index 0000000..d8c9acb --- /dev/null +++ b/.obsidian/appearance.json @@ -0,0 +1,5 @@ +{ + "cssTheme": "tesanti", + "theme": "moonstone", + "accentColor": "#e1261c" +} \ No newline at end of file diff --git a/.obsidian/core-plugins.json b/.obsidian/core-plugins.json new file mode 100644 index 0000000..639b90d --- /dev/null +++ b/.obsidian/core-plugins.json @@ -0,0 +1,33 @@ +{ + "file-explorer": true, + "global-search": true, + "switcher": true, + "graph": true, + "backlink": true, + "canvas": true, + "outgoing-link": true, + "tag-pane": true, + "footnotes": false, + "properties": true, + "page-preview": true, + "daily-notes": true, + "templates": true, + "note-composer": true, + "command-palette": true, + "slash-command": false, + "editor-status": true, + "bookmarks": true, + "markdown-importer": false, + "zk-prefixer": false, + "random-note": false, + "outline": true, + "word-count": true, + "slides": false, + "audio-recorder": false, + "workspaces": false, + "file-recovery": true, + "publish": false, + "sync": true, + "bases": true, + "webviewer": false +} \ No newline at end of file diff --git a/.obsidian/graph.json b/.obsidian/graph.json new file mode 100644 index 0000000..a889a2f --- /dev/null +++ b/.obsidian/graph.json @@ -0,0 +1,22 @@ +{ + "collapse-filter": false, + "search": "", + "showTags": true, + "showAttachments": false, + "hideUnresolved": false, + "showOrphans": true, + "collapse-color-groups": false, + "colorGroups": [], + "collapse-display": false, + "showArrow": false, + "textFadeMultiplier": 0, + "nodeSizeMultiplier": 1, + "lineSizeMultiplier": 1, + "collapse-forces": true, + "centerStrength": 0.518713248970312, + "repelStrength": 10, + "linkStrength": 1, + "linkDistance": 250, + "scale": 0.999999999999998, + "close": false +} \ No newline at end of file diff --git a/.obsidian/themes/tesanti/manifest.json b/.obsidian/themes/tesanti/manifest.json new file mode 100644 index 0000000..44b0ce3 --- /dev/null +++ b/.obsidian/themes/tesanti/manifest.json @@ -0,0 +1,7 @@ +{ + "name": "tesanti", + "version": "1.0.0", + "minAppVersion": "1.0.0", + "author": "tesanti Design System", + "authorUrl": "" +} diff --git a/.obsidian/themes/tesanti/theme.css b/.obsidian/themes/tesanti/theme.css new file mode 100644 index 0000000..ed9331e --- /dev/null +++ b/.obsidian/themes/tesanti/theme.css @@ -0,0 +1,477 @@ +/* ============================================================ + tesanti — Obsidian theme + Port of the tesanti Design System. + Minimal, editorial, high-contrast. Swiss-influenced. + Palette: black, white, one signal red (#e1261c) — used sparingly. + Type: Space Grotesk (display) · Inter (body/UI) · JetBrains Mono (data/eyebrows) + Borders carry the weight; shadows are near-absent. + ============================================================ */ + +/* --- Webfonts (Google-hosted; degrade to system fonts offline) --- */ +@import url("https://fonts.googleapis.com/css2?family=Space+Grotesk:wght@400;500;600;700&family=Inter:wght@400;500;600;700&family=JetBrains+Mono:wght@400;500;700&display=swap"); + +/* ============================================================ + 1. SHARED TOKENS (mode-independent) + Fonts, type scale, radii, borders, motion. + ============================================================ */ +body { + /* ---- Accent: signal red #e1261c expressed as HSL so Obsidian derives + interactive-accent, text-accent, checkboxes, focus, etc. from one source ---- */ + --accent-h: 3; + --accent-s: 78%; + --accent-l: 50%; + + /* ---- Font families ---- */ + --font-display: "Space Grotesk", ui-sans-serif, system-ui, -apple-system, "Helvetica Neue", Arial, sans-serif; + --font-text-theme: "Inter", ui-sans-serif, system-ui, -apple-system, "Helvetica Neue", Arial, sans-serif; + --font-interface-theme: "Inter", ui-sans-serif, system-ui, -apple-system, "Helvetica Neue", Arial, sans-serif; + --font-monospace-theme: "JetBrains Mono", ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; + + --font-text-size: 16px; + --line-height-normal: 1.5; + --line-height-tight: 1.2; + + /* ---- Headings: display face, medium weight, tight tracking ---- */ + --h1-font: var(--font-display); + --h2-font: var(--font-display); + --h3-font: var(--font-display); + --h4-font: var(--font-interface-theme); + --h5-font: var(--font-interface-theme); + --h6-font: var(--font-monospace-theme); + + --h1-weight: 500; + --h2-weight: 500; + --h3-weight: 500; + --h4-weight: 600; + --h5-weight: 600; + --h6-weight: 500; + + --h1-size: 2.25em; + --h2-size: 1.7em; + --h3-size: 1.35em; + --h4-size: 1.12em; + --h5-size: 1em; + --h6-size: 0.8em; + + --h1-line-height: 1.08; + --h2-line-height: 1.12; + --h3-line-height: 1.2; + + /* ---- Radii: small. 6px is the maximum; cards/tags near-square ---- */ + --radius-s: 2px; + --radius-m: 4px; + --radius-l: 6px; + --radius-xl: 8px; + --input-radius: 6px; + --button-radius: 6px; + --tab-radius: 4px; + --tab-radius-active: 4px; + --modal-radius: 6px; + --checkbox-radius: 2px; + --toggle-radius: 999px; /* the one place a pill is allowed */ + --slider-thumb-radius: 999px; + --meta-property-radius: 2px; + + /* ---- Borders: 1px hairline everywhere ---- */ + --border-width: 1px; + --divider-width: 1px; + --tab-outline-width: 1px; + + /* ---- Tags rendered as the signature mono all-caps eyebrow chip ---- */ + --tag-weight: 500; + --tag-border-width: 1px; + --tag-radius: 2px; + --tag-decoration: none; + --tag-decoration-hover: none; + + /* ---- Links: red, underline slides in on hover (no permanent rule) ---- */ + --link-decoration: none; + --link-decoration-hover: underline; + --link-decoration-thickness: 1px; + --link-external-decoration: none; + --link-external-decoration-hover: underline; + + /* ---- Blockquote: a black hairline rule, not a tinted block ---- */ + --blockquote-border-thickness: 2px; + --blockquote-font-style: normal; + + /* ---- Callouts: hairline-bordered, low-key, editorial ---- */ + --callout-border-width: 1px; + --callout-border-opacity: 1; + --callout-radius: 4px; + --callout-title-weight: 600; + + /* ---- Horizontal rule: a single hairline ---- */ + --hr-thickness: 1px; + + /* ---- Red caret — a status LED for the cursor ---- */ + --caret-color: var(--interactive-accent); +} + +/* ============================================================ + 2. LIGHT — the brand-true default (white canvas, ~95% of surface) + ============================================================ */ +.theme-light { + /* Ink ramp */ + --ink-000: #ffffff; + --ink-050: #f7f7f7; + --ink-100: #ececec; + --ink-200: #d9d9d9; + --ink-300: #b8b8b8; + --ink-400: #8a8a8a; + --ink-500: #5e5e5e; + --ink-600: #3d3d3d; + --ink-700: #262626; + --ink-900: #0a0a0a; + + /* Surfaces — content is white, chrome is a half-step off-white, + separation carried by hairlines (see tesanti app UI kit) */ + --background-primary: var(--ink-000); + --background-primary-alt: var(--ink-050); + --background-secondary: var(--ink-050); + --background-secondary-alt: var(--ink-100); + + --background-modifier-hover: rgba(10, 10, 10, 0.045); + --background-modifier-active-hover: rgba(10, 10, 10, 0.075); + --background-modifier-border: var(--ink-200); + --background-modifier-border-hover: var(--ink-300); + --background-modifier-border-focus: var(--interactive-accent); + --background-modifier-form-field: var(--ink-000); + + /* Text */ + --text-normal: var(--ink-900); + --text-muted: var(--ink-500); + --text-faint: var(--ink-400); + --text-on-accent: #ffffff; + --text-accent: var(--interactive-accent); + --text-accent-hover: #c31c14; + + --text-selection: hsla(3, 78%, 50%, 0.16); + --text-highlight-bg: hsla(48, 100%, 50%, 0.28); + + --bold-color: var(--ink-900); + --italic-color: var(--text-normal); + + /* Interactive */ + --interactive-normal: var(--ink-050); + --interactive-hover: var(--ink-100); + --interactive-accent-hover: #c31c14; + + /* Structure */ + --divider-color: var(--ink-200); + --hr-color: var(--ink-200); + + /* Headings — near-black, uniform */ + --h1-color: var(--ink-900); + --h2-color: var(--ink-900); + --h3-color: var(--ink-900); + --h4-color: var(--ink-900); + --h5-color: var(--ink-900); + --h6-color: var(--ink-500); + --heading-formatting: var(--ink-300); + + /* Links */ + --link-color: var(--interactive-accent); + --link-color-hover: #c31c14; + --link-external-color: var(--interactive-accent); + --link-external-color-hover: #c31c14; + --link-unresolved-color: var(--ink-400); + --link-unresolved-opacity: 1; + + /* Tags */ + --tag-color: var(--ink-500); + --tag-color-hover: var(--ink-900); + --tag-background: transparent; + --tag-background-hover: var(--ink-050); + --tag-border-color: var(--ink-200); + --tag-border-color-hover: var(--interactive-accent); + + /* Code */ + --code-background: var(--ink-050); + --code-normal: var(--ink-700); + + /* Blockquote */ + --blockquote-border-color: var(--ink-900); + --blockquote-color: var(--ink-500); + --blockquote-background-color: transparent; + + /* Navigation */ + --nav-item-color: var(--ink-600); + --nav-item-color-hover: var(--ink-900); + --nav-item-color-active: var(--ink-900); + --nav-item-background-hover: rgba(10, 10, 10, 0.045); + --nav-item-background-active: var(--ink-100); + --nav-item-weight-active: 500; + --nav-indentation-guide-color: var(--ink-100); + + /* Chrome */ + --titlebar-background: var(--ink-050); + --titlebar-background-focused: var(--ink-000); + --titlebar-text-color: var(--ink-500); + --ribbon-background: var(--ink-050); + --tab-background-active: var(--ink-000); + --tab-text-color-focused-active: var(--ink-900); + --tab-outline-color: var(--ink-200); + --status-bar-background: var(--ink-050); + --status-bar-text-color: var(--ink-500); + + /* Scrollbar */ + --scrollbar-thumb-bg: rgba(10, 10, 10, 0.16); + --scrollbar-active-thumb-bg: rgba(10, 10, 10, 0.32); + --scrollbar-bg: transparent; + + /* Restrained shadows — a hairline where a shadow would do */ + --shadow-s: 0 1px 0 rgba(0, 0, 0, 0.04); + --shadow-l: 0 2px 8px rgba(0, 0, 0, 0.06); + + /* Graph view */ + --graph-line: var(--ink-200); + --graph-node: var(--ink-700); + --graph-node-focused: var(--interactive-accent); + --graph-node-tag: var(--interactive-accent); + --graph-node-unresolved: var(--ink-300); +} + +/* ============================================================ + 3. DARK — inverted ink ramp. Black canvas, same signal red. + ============================================================ */ +.theme-dark { + /* Ink ramp (inverted usage) */ + --ink-000: #ffffff; + --ink-050: #f7f7f7; + --ink-100: #ececec; + --ink-200: #b8b8b8; + --ink-400: #8a8a8a; + --ink-500: #5e5e5e; + --ink-600: #3d3d3d; + --ink-700: #262626; + --ink-800: #161616; + --ink-900: #0a0a0a; + --ink-999: #000000; + + /* Surfaces — content near-black, chrome pure black; hairlines separate */ + --background-primary: var(--ink-900); + --background-primary-alt: var(--ink-800); + --background-secondary: var(--ink-999); + --background-secondary-alt: var(--ink-800); + + --background-modifier-hover: rgba(236, 236, 236, 0.06); + --background-modifier-active-hover: rgba(236, 236, 236, 0.10); + --background-modifier-border: var(--ink-700); + --background-modifier-border-hover: var(--ink-600); + --background-modifier-border-focus: var(--interactive-accent); + --background-modifier-form-field: var(--ink-800); + + /* Text */ + --text-normal: var(--ink-100); + --text-muted: var(--ink-400); + --text-faint: var(--ink-500); + --text-on-accent: #ffffff; + --text-accent: var(--interactive-accent); + --text-accent-hover: #ff4d43; + + --text-selection: hsla(3, 78%, 50%, 0.30); + --text-highlight-bg: hsla(48, 100%, 50%, 0.30); + + --bold-color: #ffffff; + --italic-color: var(--text-normal); + + /* Interactive */ + --interactive-normal: var(--ink-800); + --interactive-hover: var(--ink-700); + --interactive-accent-hover: #ff4d43; + + /* Structure */ + --divider-color: var(--ink-700); + --hr-color: var(--ink-700); + + /* Headings */ + --h1-color: var(--ink-050); + --h2-color: var(--ink-050); + --h3-color: var(--ink-050); + --h4-color: var(--ink-050); + --h5-color: var(--ink-050); + --h6-color: var(--ink-400); + --heading-formatting: var(--ink-600); + + /* Links */ + --link-color: var(--interactive-accent); + --link-color-hover: #ff4d43; + --link-external-color: var(--interactive-accent); + --link-external-color-hover: #ff4d43; + --link-unresolved-color: var(--ink-500); + --link-unresolved-opacity: 1; + + /* Tags */ + --tag-color: var(--ink-400); + --tag-color-hover: var(--ink-050); + --tag-background: transparent; + --tag-background-hover: var(--ink-800); + --tag-border-color: var(--ink-700); + --tag-border-color-hover: var(--interactive-accent); + + /* Code */ + --code-background: var(--ink-800); + --code-normal: var(--ink-200); + + /* Blockquote */ + --blockquote-border-color: var(--ink-100); + --blockquote-color: var(--ink-400); + --blockquote-background-color: transparent; + + /* Navigation */ + --nav-item-color: var(--ink-400); + --nav-item-color-hover: var(--ink-050); + --nav-item-color-active: var(--ink-050); + --nav-item-background-hover: rgba(236, 236, 236, 0.06); + --nav-item-background-active: var(--ink-800); + --nav-item-weight-active: 500; + --nav-indentation-guide-color: var(--ink-800); + + /* Chrome */ + --titlebar-background: var(--ink-999); + --titlebar-background-focused: var(--ink-900); + --titlebar-text-color: var(--ink-400); + --ribbon-background: var(--ink-999); + --tab-background-active: var(--ink-900); + --tab-text-color-focused-active: var(--ink-050); + --tab-outline-color: var(--ink-700); + --status-bar-background: var(--ink-999); + --status-bar-text-color: var(--ink-400); + + /* Scrollbar */ + --scrollbar-thumb-bg: rgba(236, 236, 236, 0.14); + --scrollbar-active-thumb-bg: rgba(236, 236, 236, 0.30); + --scrollbar-bg: transparent; + + /* Shadows — deeper on black, still short and uncolored */ + --shadow-s: 0 1px 0 rgba(0, 0, 0, 0.4); + --shadow-l: 0 2px 10px rgba(0, 0, 0, 0.5); + + /* Graph view */ + --graph-line: var(--ink-700); + --graph-node: var(--ink-200); + --graph-node-focused: var(--interactive-accent); + --graph-node-tag: var(--interactive-accent); + --graph-node-unresolved: var(--ink-600); +} + +/* ============================================================ + 4. COMPONENT POLISH — the bits variables alone can't express + ============================================================ */ + +/* ---- Headings: tight display tracking (Swiss editorial) ---- */ +.markdown-rendered :is(h1, h2, h3), +.cm-s-obsidian :is(.HyperMD-header-1, .HyperMD-header-2, .HyperMD-header-3) { + letter-spacing: -0.02em; +} +.markdown-rendered :is(h4, h5), +.cm-s-obsidian :is(.HyperMD-header-4, .HyperMD-header-5) { + letter-spacing: -0.005em; +} + +/* h6 becomes a muted mono eyebrow (all-caps, wide-tracked) */ +.markdown-rendered h6, +.cm-s-obsidian .HyperMD-header-6 .cm-header-6 { + text-transform: uppercase; + letter-spacing: 0.12em; + font-family: var(--font-monospace-theme); +} + +/* ---- Tags: the signature all-caps mono eyebrow chip with a red dot ---- */ +.markdown-rendered a.tag, +.cm-s-obsidian .cm-hashtag { + font-family: var(--font-monospace-theme); + font-size: 0.72em; + font-weight: 500; + text-transform: uppercase; + letter-spacing: 0.11em; + line-height: 1; + padding: 0.28em 0.55em; + border: 1px solid var(--tag-border-color); + border-radius: 2px; + vertical-align: middle; +} +/* Reading view — red leading dot ( • SOURCE ) */ +.markdown-rendered a.tag::before { + content: ""; + display: inline-block; + width: 5px; + height: 5px; + margin-right: 0.5em; + border-radius: 999px; + background: var(--interactive-accent); + vertical-align: middle; +} +/* Live-preview hashtag: seam the split # + name and tint the # red as the "dot" */ +.cm-s-obsidian .cm-hashtag-begin { + border-right: none; + border-top-right-radius: 0; + border-bottom-right-radius: 0; + color: var(--interactive-accent); + padding-right: 0; +} +.cm-s-obsidian .cm-hashtag-end { + border-left: none; + border-top-left-radius: 0; + border-bottom-left-radius: 0; + padding-left: 0.4em; +} + +/* ---- Inline code & code blocks: hairline-bordered gray panels ---- */ +.markdown-rendered code { + border: 1px solid var(--background-modifier-border); + border-radius: var(--radius-s); + padding: 0.12em 0.35em; +} +.markdown-rendered pre { + border: 1px solid var(--background-modifier-border); + border-radius: var(--radius-m); +} +.markdown-rendered pre > code { + border: none; + padding: 0; +} + +/* ---- Active tab: a 2px red top rule (the "active/selected" red state) ---- */ +.workspace-tab-header.is-active.mod-active { + box-shadow: inset 0 2px 0 0 var(--interactive-accent); +} + +/* ---- Active file in the explorer: a 2px red left rule ---- */ +.nav-file-title.is-active, +.workspace-leaf.mod-active .nav-file-title.is-active { + box-shadow: inset 2px 0 0 0 var(--interactive-accent); +} + +/* ---- Eyebrow-style tag pane & outline headers stay quiet ---- */ +.status-bar { + font-family: var(--font-monospace-theme); + font-size: 11px; + letter-spacing: 0.06em; + border-top: 1px solid var(--divider-color); +} + +/* ---- Selection: a red wash (readable over live text; on-brand accent) ---- */ +::selection { + background: hsla(3, 78%, 50%, 0.22); +} + +/* ---- Checkbox: near-square, red when checked (via accent) ---- */ +input[type="checkbox"] { + border-radius: var(--checkbox-radius); +} + +/* ---- Tables: hairline grid, mono-ish numeric feel kept via defaults ---- */ +.markdown-rendered table { + border: 1px solid var(--background-modifier-border); +} +.markdown-rendered th { + font-weight: 600; + background: var(--background-secondary); +} + +/* ---- Blockquotes: no tint, just the rule ---- */ +.markdown-rendered blockquote { + padding-left: 1em; +} diff --git a/CLAUDE.md b/CLAUDE.md new file mode 100644 index 0000000..a09634c --- /dev/null +++ b/CLAUDE.md @@ -0,0 +1,189 @@ +# LLM Wiki Schema (Operational Contract) + +You are the dedicated maintainer of this vault as a persistent, compounding wiki. + +## Mission + +Maintain a high-signal personal knowledge base where: + +- `raw/` contains immutable source materials. +- `wiki/` contains LLM-authored, continuously maintained markdown pages. +- `index.md` is the content catalog. +- `log.md` is an append-only chronological operation log. + +The user curates sources and asks questions. You perform all wiki maintenance. + +## Non-Negotiable Rules + +1. Never modify files inside `raw/`. +2. Always update `index.md` and `log.md` after any ingest/query/lint operation that changes the wiki. +3. Prefer editing existing pages over creating duplicates. +4. Use Obsidian-style wiki links (`[[page-name]]`) for internal references. +5. Record contradictions and superseded claims explicitly (do not silently overwrite history). +6. Keep claims attributable: include source links to `wiki/sources/*` pages. +7. Do not leave orphan pages intentionally; add at least one inbound and one outbound link when possible. +8. Keep writing concise, structured, and diff-friendly. +9. Every wiki page carries exactly one page-type hashtag (see Tagging Rules) matching its folder. + +## Folder Convention + +```text +raw/ + sources/ # immutable source markdown/text/pdf exports + assets/ # immutable local images/files referenced by raw sources + +wiki/ + overview.md # top-level synthesis and navigation + sources/ # one summary page per ingested raw source + entities/ # people, orgs, projects, places, tools + concepts/ # themes, ideas, methods, frameworks + timelines/ # optional chronological reconstructions + comparisons/ # side-by-side analyses + queries/ # durable outputs created from Q&A sessions + lint-reports/ # periodic health-check reports +``` + +## File Naming Rules + +- Use kebab-case for file names. +- Prefix source summary pages with date: `YYYY-MM-DD-title.md`. +- Prefer stable canonical pages: + - `wiki/entities/.md` + - `wiki/concepts/.md` +- If a page name collides, merge instead of creating suffixes unless truly distinct. + +## Tagging Rules + +Every page in `wiki/` starts with its page-type hashtag on its own line, directly after the `# ` heading (Obsidian inline tag format): + +```text +# <Title> + +#<type-tag> + +## <first section> +``` + +Folder → required tag: + +| Folder / file | Tag | +| ---------------------- | -------------- | +| `wiki/overview.md` | `#overview` | +| `wiki/sources/*` | `#source` | +| `wiki/entities/*` | `#entity` | +| `wiki/concepts/*` | `#concept` | +| `wiki/timelines/*` | `#timeline` | +| `wiki/comparisons/*` | `#comparison` | +| `wiki/queries/*` | `#query` | +| `wiki/lint-reports/*` | `#lint-report` | + +- Exactly one page-type tag per page; it must match the page's folder. +- Additional topical tags are allowed on the same line after the type tag (e.g. `#concept #ai-tooling`), but the type tag comes first. +- When creating any new page, add the tag immediately; when moving a page between folders, update the tag in the same operation. + +## Required Page Templates + +### 1) Source Summary (`wiki/sources/*.md`) + +Must include sections: + +- `# <title>` +- `#source` tag line (per Tagging Rules) +- `## Source Metadata` (date, raw path, source type, ingestion date) +- `## Core Claims` +- `## Key Evidence / Details` +- `## Connections` (links to entities/concepts/comparisons) +- `## Open Questions` +- `## Change Impact on Wiki` (what pages were updated and why) + +### 2) Entity / Concept Page + +Must include: + +- `# <name>` +- `#entity` or `#concept` tag line (per Tagging Rules) +- `## Summary` +- `## Current Understanding` +- `## Evidence` (bullets with links to `wiki/sources/*`) +- `## Related Pages` +- `## Contradictions / Uncertainty` +- `## Next Questions` + +### 3) Query Output (`wiki/queries/*.md`) + +Must include: + +- `#query` tag line (per Tagging Rules) +- Question asked +- Answer +- Evidence trail (links) +- Follow-up questions +- Whether this output changed existing pages + +## Standard Workflows + +### Workflow A: Ingest One Source + +When user says "ingest <source>": + +1. Read the raw source from `raw/sources/` (and `raw/assets/` references if needed). +2. Extract key claims, facts, entities, concepts, uncertainty. +3. Create/update one source summary in `wiki/sources/`. +4. Update relevant `wiki/entities/*` and `wiki/concepts/*` pages. +5. Update `wiki/overview.md` synthesis if this source materially changes understanding. +6. Update `index.md`. +7. Append ingest entry to `log.md`. +8. Report what changed, what is uncertain, and suggested next source/questions. + +### Workflow B: Answer Query + +1. Read `index.md` first. +2. Select relevant pages and synthesize answer with page citations. +3. If answer has durable value, save to `wiki/queries/YYYY-MM-DD-<slug>.md`. +4. If answer reveals new synthesis, update affected concept/entity pages. +5. Update `index.md` and append query entry in `log.md` when files changed. + +### Workflow C: Lint Wiki + +Run periodic health checks for: + +- contradiction detection across pages +- stale claims superseded by newer sources +- orphan pages / weak linking +- high-mention concepts lacking dedicated pages +- missing evidence links +- missing or folder-mismatched page-type tags (per Tagging Rules) + +Write report to `wiki/lint-reports/YYYY-MM-DD-lint.md`, then update `index.md` and `log.md`. + +## Citation & Evidence Policy + +- Prefer citing wiki source summaries (`wiki/sources/*.md`) rather than raw files in normal answers. +- If citing raw material directly, also reflect it into a source summary page. +- Mark uncertain or contested claims with `Status: tentative` in relevant section. + +## Update Policy + +- Never perform silent large rewrites. +- Preserve meaningful prior interpretations; move outdated material under a "Superseded" note when needed. +- Keep sections ordered consistently for predictable diffs. + +## Operational Commands (Natural Language) + +Supported intents: + +- "ingest path-or-title" +- "query: question" +- "lint wiki" +- "show recent changes" +- "suggest next sources" + +Always execute intents according to workflows above. + +## Session Start Checklist + +At start of every session: + +1. Read `index.md` and the latest section of `log.md`. +2. Identify last completed operation and current open questions. +3. Continue from prior state without resetting conventions. diff --git a/docs/superpowers/plans/2026-07-28-webinar-dashboard.md b/docs/superpowers/plans/2026-07-28-webinar-dashboard.md new file mode 100644 index 0000000..256d5d0 --- /dev/null +++ b/docs/superpowers/plans/2026-07-28-webinar-dashboard.md @@ -0,0 +1,1619 @@ +# Webinar Vault Dashboard Implementation Plan + +> **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development (recommended) or superpowers:executing-plans to implement this plan task-by-task. Steps use checkbox (`- [ ]`) syntax for tracking. + +**Goal:** Build an Obsidian plugin that renders a two-pane dashboard showing the vault's source pipeline (with one-click headless ingest) and concept coverage against the webinar script. + +**Architecture:** A single unbundled `main.js` CommonJS plugin. Pure logic (path extraction, pipeline derivation, table parsing, filename validation) lives at the top of the file behind a guarded `require("obsidian")`, so it can be unit-tested with plain `node --test` and no Obsidian runtime. Obsidian glue (code-block processor, DOM rendering, subprocess spawn) sits below it. The plugin reads the vault and never writes to it. + +**Tech Stack:** Plain CommonJS (no TypeScript, no bundler, no build step), Node's built-in `node:test` runner, Node `child_process`, Obsidian Plugin API, tesanti design tokens. + +## Global Constraints + +- **No build step.** `main.js` is loaded by Obsidian verbatim. No TypeScript, no esbuild, no `npm install`. +- **No dependencies.** Tests use Node's built-in `node:test` and `node:assert/strict` only. +- **`isDesktopOnly: true`** is mandatory in `manifest.json` — the plugin uses `child_process`, which Obsidian only provides on desktop. +- **`minAppVersion`: `"1.5.0"`.** +- **Relative `require()` between plugin files is unsupported.** All code lives in one `main.js`. +- **The plugin never writes to the vault.** It reads files and spawns one subprocess. It must never read `index.md`. +- **Design tokens are copied verbatim** from `tesanti Design System.zip → colors_and_type.css`. Black / white / red only; radii at most 6px; 1px hairlines instead of shadows. +- **No emoji anywhere** — in code, UI, comments, or commit messages. Status icons are inline Lucide stroke paths. +- **Sentence case** for all UI copy. No Title Case. +- **The seven stations**, in order: `Chat box`, `ReAct`, `Tools`, `Memory`, `Skills`, `Process`, `OS`. +- **Valid statuses**, exactly: `covered`, `partial`, `absent`. + +--- + +## File Structure + +| File | Responsibility | +|---|---| +| `.obsidian/plugins/webinar-dash/manifest.json` | Plugin identity and desktop-only flag | +| `.obsidian/plugins/webinar-dash/main.js` | Everything: pure helpers, renderers, plugin class | +| `.obsidian/plugins/webinar-dash/styles.css` | tesanti tokens and dashboard styling, scoped to `.webinar-dash` | +| `.obsidian/plugins/webinar-dash/test/pipeline.test.js` | Tests for `extractRawPath`, `derivePipeline` | +| `.obsidian/plugins/webinar-dash/test/coverage.test.js` | Tests for `parseCoverageTable`, `groupByStation` | +| `.obsidian/plugins/webinar-dash/test/safety.test.js` | Tests for `isSafeFilename` | +| `dashboard.md` | Vault root. Holds one `webinar-dash` config block | +| `wiki/script-coverage.md` | The coverage table | +| `CLAUDE.md` | Modified: folder convention, tagging rules, Workflow D, sync triggers | + +Tests live inside the plugin folder. Obsidian loads only `main.js` from a plugin directory, so `test/` is inert at runtime. + +--- + +### Task 1: Repository and plugin scaffold + +**Files:** +- Create: `.gitignore` +- Create: `.obsidian/plugins/webinar-dash/manifest.json` +- Create: `.obsidian/plugins/webinar-dash/main.js` +- Create: `dashboard.md` + +**Interfaces:** +- Consumes: nothing +- Produces: a loadable plugin registering the `webinar-dash` code-block language; `module.exports.__test__` as the export surface every later task extends + +- [ ] **Step 1: Initialize the repository** + +The vault is not currently a git repository. The plugin will spawn agents that write to `wiki/`, `index.md`, and `log.md` unsupervised, so an undo path is required before that capability exists. + +```bash +cd "D:/Projects/Notes/Webinar/Webinar" +git init +``` + +- [ ] **Step 2: Create `.gitignore`** + +Obsidian rewrites `workspace.json` constantly; it is local UI state, not vault content. + +```gitignore +.obsidian/workspace.json +.obsidian/workspace-mobile.json +.obsidian/cache +``` + +- [ ] **Step 3: Commit the vault as it stands** + +```bash +git add -A +git commit -m "chore: initial commit of vault before dashboard work" +``` + +- [ ] **Step 4: Create the manifest** + +`isDesktopOnly` must be `true` — Obsidian only exposes `child_process` on desktop, and the ingest button depends on it. + +```json +{ + "id": "webinar-dash", + "name": "Webinar dashboard", + "version": "0.1.0", + "minAppVersion": "1.5.0", + "description": "Source pipeline and script coverage for the webinar vault.", + "author": "meels", + "isDesktopOnly": true +} +``` + +- [ ] **Step 5: Create `main.js` with the Obsidian guard and a stub renderer** + +The `try/catch` around `require("obsidian")` is what lets `node --test` load this file. Under Node the require throws, `OB` stays null, and `PluginBase` becomes an empty class so `class ... extends PluginBase` still evaluates. Every later task adds pure functions above the plugin class and registers them in `__test__`. + +```js +"use strict"; + +// Obsidian injects its own module resolver. Under plain `node --test` it is +// absent, so guard the require and fall back to an empty base class. This is +// what keeps the pure helpers below unit-testable without an Obsidian runtime. +let OB = null; +try { + OB = require("obsidian"); +} catch (_) { + OB = null; +} +const PluginBase = OB ? OB.Plugin : class {}; + +const STATIONS = ["Chat box", "ReAct", "Tools", "Memory", "Skills", "Process", "OS"]; + +const DEFAULTS = { + script: "raw/sources/Webinar script.md", + coverage: "wiki/script-coverage.md", + rawDir: "raw/sources", + wikiSourceDir: "wiki/sources", + conceptDir: "wiki/concepts", +}; + +function parseConfig(source) { + const cfg = Object.assign({}, DEFAULTS); + for (const line of String(source).split(/\r?\n/)) { + const m = line.match(/^\s*([A-Za-z][A-Za-z0-9_]*)\s*:\s*(.+?)\s*$/); + if (m && Object.prototype.hasOwnProperty.call(DEFAULTS, m[1])) { + cfg[m[1]] = m[2]; + } + } + return cfg; +} + +class WebinarDashPlugin extends PluginBase { + async onload() { + this.registerMarkdownCodeBlockProcessor("webinar-dash", (source, el, ctx) => { + const cfg = parseConfig(source); + const root = el.createDiv({ cls: "webinar-dash" }); + root.createDiv({ cls: "wd-eyebrow", text: "Webinar dashboard" }); + root.createEl("p", { text: `Reading coverage from ${cfg.coverage}` }); + }); + } +} + +module.exports = WebinarDashPlugin; +module.exports.default = WebinarDashPlugin; +module.exports.__test__ = { parseConfig, STATIONS, DEFAULTS }; +``` + +- [ ] **Step 6: Create `dashboard.md`** + +````markdown +# Webinar dashboard + +```webinar-dash +script: raw/sources/Webinar script.md +coverage: wiki/script-coverage.md +``` +```` + +- [ ] **Step 7: Enable the plugin and verify it renders** + +In Obsidian: Settings → Community plugins → turn off Restricted mode if on → Installed plugins → Reload → enable "Webinar dashboard". Open `dashboard.md` in reading view. + +Expected: the text `Webinar dashboard` followed by `Reading coverage from wiki/script-coverage.md`. + +If nothing renders, run "Reload app without saving" (`Ctrl+R`) — Obsidian caches plugin code between edits. + +- [ ] **Step 8: Commit** + +```bash +git add .gitignore .obsidian/plugins/webinar-dash dashboard.md +git commit -m "feat: scaffold webinar-dash plugin with config block" +``` + +--- + +### Task 2: Source pipeline derivation + +**Files:** +- Modify: `.obsidian/plugins/webinar-dash/main.js` +- Test: `.obsidian/plugins/webinar-dash/test/pipeline.test.js` + +**Interfaces:** +- Consumes: `module.exports.__test__` from Task 1 +- Produces: + - `extractRawPath(text: string) => string | null` + - `derivePipeline({ rawFiles, sourcePages }) => { processed, unprocessed, orphaned }` + - `rawFiles` items: `{ path: string, name: string, size: number }` + - `sourcePages` items: `{ path: string, name: string, rawPath: string | null }` + - `processed` items: `rawFiles` item plus `{ page }` + +- [ ] **Step 1: Write the failing tests** + +Create `.obsidian/plugins/webinar-dash/test/pipeline.test.js`. The fixtures are the real strings from this vault. + +```js +"use strict"; +const test = require("node:test"); +const assert = require("node:assert/strict"); +const { extractRawPath, derivePipeline } = require("../main.js").__test__; + +test("extractRawPath pulls the backticked path", () => { + const page = [ + "# You're reading way too much code", + "", + "#source", + "", + "## Source Metadata", + "", + "- **Date:** YouTube video, 24:11", + "- **Raw path:** `raw/sources/You're reading way too much code.md`", + "- **Source type:** video essay", + ].join("\n"); + assert.equal(extractRawPath(page), "raw/sources/You're reading way too much code.md"); +}); + +test("extractRawPath handles cyrillic and em dashes", () => { + const page = "- **Raw path:** `raw/sources/Скиллы на базе git — новая память AI-агентов.md`"; + assert.equal(extractRawPath(page), "raw/sources/Скиллы на базе git — новая память AI-агентов.md"); +}); + +test("extractRawPath returns null when the line is absent", () => { + assert.equal(extractRawPath("# A page\n\n#source\n\nNo metadata here."), null); +}); + +test("derivePipeline splits claimed from unclaimed raw files", () => { + const rawFiles = [ + { path: "raw/sources/Nina interview.md", name: "Nina interview.md", size: 6614 }, + { path: "raw/sources/Webinar script.md", name: "Webinar script.md", size: 15841 }, + ]; + const sourcePages = [ + { + path: "wiki/sources/2026-07-14-nina-interview.md", + name: "2026-07-14-nina-interview.md", + rawPath: "raw/sources/Nina interview.md", + }, + ]; + const out = derivePipeline({ rawFiles, sourcePages }); + assert.equal(out.processed.length, 1); + assert.equal(out.processed[0].name, "Nina interview.md"); + assert.equal(out.processed[0].page.name, "2026-07-14-nina-interview.md"); + assert.equal(out.unprocessed.length, 1); + assert.equal(out.unprocessed[0].name, "Webinar script.md"); + assert.equal(out.orphaned.length, 0); +}); + +test("derivePipeline reports source pages whose raw file is gone", () => { + const out = derivePipeline({ + rawFiles: [], + sourcePages: [ + { path: "wiki/sources/x.md", name: "x.md", rawPath: "raw/sources/deleted.md" }, + ], + }); + assert.equal(out.orphaned.length, 1); + assert.equal(out.orphaned[0].name, "x.md"); +}); + +test("derivePipeline treats a page with no raw path as orphaned", () => { + const out = derivePipeline({ + rawFiles: [{ path: "raw/sources/a.md", name: "a.md", size: 10 }], + sourcePages: [{ path: "wiki/sources/y.md", name: "y.md", rawPath: null }], + }); + assert.equal(out.orphaned.length, 1); + assert.equal(out.unprocessed.length, 1); +}); + +test("derivePipeline sorts unprocessed by name and processed newest first", () => { + const out = derivePipeline({ + rawFiles: [ + { path: "raw/sources/b.md", name: "b.md", size: 1 }, + { path: "raw/sources/a.md", name: "a.md", size: 1 }, + { path: "raw/sources/c.md", name: "c.md", size: 1 }, + ], + sourcePages: [ + { path: "wiki/sources/2026-07-14-x.md", name: "2026-07-14-x.md", rawPath: "raw/sources/c.md" }, + ], + }); + assert.deepEqual(out.unprocessed.map((f) => f.name), ["a.md", "b.md"]); + assert.equal(out.processed.length, 1); +}); +``` + +- [ ] **Step 2: Run the tests to verify they fail** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar/.obsidian/plugins/webinar-dash" +node --test test/pipeline.test.js +``` + +Expected: FAIL — `extractRawPath is not a function` (it is not yet exported). + +- [ ] **Step 3: Implement the helpers** + +In `main.js`, insert directly below the `DEFAULTS` constant: + +```js +const RAW_PATH_RE = /^\s*-\s*\*\*Raw path:\*\*\s*`([^`]+)`/m; + +function extractRawPath(text) { + const m = String(text).match(RAW_PATH_RE); + return m ? m[1].trim() : null; +} + +function derivePipeline({ rawFiles, sourcePages }) { + const claimed = new Map(); + for (const page of sourcePages) { + if (page.rawPath) claimed.set(page.rawPath, page); + } + + const processed = []; + const unprocessed = []; + for (const file of rawFiles) { + const page = claimed.get(file.path); + if (page) processed.push(Object.assign({}, file, { page })); + else unprocessed.push(file); + } + + const rawPaths = new Set(rawFiles.map((f) => f.path)); + const orphaned = sourcePages.filter((p) => !p.rawPath || !rawPaths.has(p.rawPath)); + + unprocessed.sort((a, b) => a.name.localeCompare(b.name)); + processed.sort((a, b) => b.page.name.localeCompare(a.page.name)); + + return { processed, unprocessed, orphaned }; +} +``` + +- [ ] **Step 4: Export them** + +Replace the `__test__` line at the bottom of `main.js`: + +```js +module.exports.__test__ = { parseConfig, extractRawPath, derivePipeline, STATIONS, DEFAULTS }; +``` + +- [ ] **Step 5: Run the tests to verify they pass** + +```bash +node --test test/pipeline.test.js +``` + +Expected: PASS, 7 tests. + +- [ ] **Step 6: Commit** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar" +git add .obsidian/plugins/webinar-dash +git commit -m "feat: derive source pipeline from raw path claims" +``` + +--- + +### Task 3: Left pane — source pipeline rendering + +**Files:** +- Modify: `.obsidian/plugins/webinar-dash/main.js` +- Create: `.obsidian/plugins/webinar-dash/styles.css` + +**Interfaces:** +- Consumes: `derivePipeline`, `extractRawPath` from Task 2; `parseConfig` from Task 1 +- Produces: + - `async readPipeline(app, cfg) => { processed, unprocessed, orphaned }` as a method on the plugin class + - `renderLeftPane(container, pipeline, onIngest)` where `onIngest` is `(file, rowEl) => void`; Task 6 supplies the real handler, this task passes a no-op + - CSS class root `.webinar-dash` and the shared primitives `.wd-eyebrow`, `.wd-row`, `.wd-btn`, `.wd-mono` + +- [ ] **Step 1: Create `styles.css` with tesanti tokens** + +Values are copied verbatim from `colors_and_type.css`. Scoped to `.webinar-dash` so nothing leaks into the rest of Obsidian. Obsidian loads `styles.css` from the plugin folder automatically. + +```css +.webinar-dash { + --wd-ink-000: #ffffff; --wd-ink-050: #f7f7f7; --wd-ink-100: #ececec; + --wd-ink-200: #d9d9d9; --wd-ink-400: #8a8a8a; --wd-ink-500: #5e5e5e; + --wd-ink-700: #262626; --wd-ink-900: #0a0a0a; --wd-ink-999: #000000; + --wd-red-500: #e1261c; --wd-red-600: #c31c14; + + --wd-bg: var(--wd-ink-000); + --wd-bg-subtle: var(--wd-ink-050); + --wd-fg: var(--wd-ink-999); + --wd-fg-2: var(--wd-ink-700); + --wd-fg-3: var(--wd-ink-500); + --wd-fg-4: var(--wd-ink-400); + --wd-border: var(--wd-ink-200); + --wd-border-strong: var(--wd-ink-999); + --wd-border-subtle: var(--wd-ink-100); + --wd-accent: var(--wd-red-500); + --wd-accent-press: var(--wd-red-600); + --wd-accent-on: #ffffff; + --wd-ok: #0a8a3f; + --wd-warn: #c68a00; + --wd-danger: var(--wd-red-500); + + --wd-mono: "JetBrains Mono", ui-monospace, SFMono-Regular, Menlo, Consolas, monospace; + --wd-sans: "Inter", ui-sans-serif, system-ui, -apple-system, "Helvetica Neue", Arial, sans-serif; + + font-family: var(--wd-sans); + color: var(--wd-fg); + display: grid; + grid-template-columns: minmax(0, 38fr) minmax(0, 62fr); + gap: 24px; +} + +.theme-dark .webinar-dash { + --wd-bg: var(--wd-ink-900); + --wd-bg-subtle: #161616; + --wd-fg: var(--wd-ink-000); + --wd-fg-2: var(--wd-ink-200); + --wd-fg-3: var(--wd-ink-400); + --wd-fg-4: var(--wd-ink-500); + --wd-border: var(--wd-ink-700); + --wd-border-strong: #b8b8b8; + --wd-border-subtle: #161616; + --wd-accent: #ff4a3d; + --wd-accent-press: #ff6d62; + --wd-accent-on: #0a0a0a; + --wd-ok: #2fbf6a; + --wd-warn: #e0a516; + --wd-danger: #ff4a3d; +} + +@media (max-width: 820px) { + .webinar-dash { grid-template-columns: minmax(0, 1fr); } +} + +.webinar-dash > * { min-width: 0; } + +.wd-pane { display: flex; flex-direction: column; gap: 20px; } + +.wd-eyebrow { + font-family: var(--wd-mono); font-size: 11px; line-height: 1; + letter-spacing: 0.12em; text-transform: uppercase; + color: var(--wd-fg-3); font-weight: 500; + display: flex; align-items: center; gap: 8px; +} +.wd-eyebrow::before { + content: ""; width: 5px; height: 5px; flex: none; background: var(--wd-accent); +} + +.wd-block { display: flex; flex-direction: column; gap: 12px; } + +.wd-row { + display: flex; align-items: center; gap: 12px; + border: 1px solid var(--wd-border); border-radius: 4px; + padding: 12px 12px 12px 16px; background: var(--wd-bg); +} +.wd-row + .wd-row { margin-top: -1px; } +.wd-row-main { flex: 1; min-width: 0; display: flex; flex-direction: column; gap: 2px; } +.wd-row-name { + font-size: 14px; font-weight: 600; + overflow: hidden; text-overflow: ellipsis; white-space: nowrap; +} +.wd-mono { + font-family: var(--wd-mono); font-size: 11px; color: var(--wd-fg-3); + font-variant-numeric: tabular-nums; +} + +.wd-btn { + display: inline-flex; align-items: center; gap: 6px; flex: none; + font-family: var(--wd-sans); font-size: 13px; font-weight: 600; + padding: 6px 12px; border-radius: 6px; cursor: pointer; + border: 1px solid var(--wd-accent); background: var(--wd-accent); + color: var(--wd-accent-on); + transition: background 120ms cubic-bezier(0.2, 0, 0, 1); +} +.wd-btn:hover { background: var(--wd-accent-press); border-color: var(--wd-accent-press); } +.wd-btn:focus-visible { outline: 2px solid var(--wd-accent); outline-offset: 2px; } +.wd-btn[disabled] { + opacity: 0.45; cursor: not-allowed; + background: transparent; color: var(--wd-fg-3); border-color: var(--wd-border); +} +.wd-btn svg { width: 14px; height: 14px; flex: none; } + +.wd-done { display: flex; flex-direction: column; } +.wd-done-row { + display: flex; align-items: baseline; gap: 12px; padding: 5px 0; + border-bottom: 1px solid var(--wd-border-subtle); font-size: 13px; +} +.wd-done-row:last-child { border-bottom: 0; } +.wd-done-name { + color: var(--wd-fg-2); + overflow: hidden; text-overflow: ellipsis; white-space: nowrap; +} + +.wd-note { font-size: 12px; color: var(--wd-fg-3); } +.wd-error { + font-size: 13px; color: var(--wd-danger); + border: 1px solid var(--wd-danger); border-radius: 4px; padding: 12px; +} + +@media (prefers-reduced-motion: reduce) { + .webinar-dash * { transition-duration: 0.01ms !important; } +} +``` + +- [ ] **Step 2: Add the Lucide icon helper and the left-pane renderer** + +Insert into `main.js` above the plugin class. Icons are inline stroke paths — the Lucide CDN is unavailable offline and the design system forbids emoji. + +```js +const ICONS = { + terminal: "M4 17l6-6-6-6M12 19h8", + check: "M20 6 9 17l-5-5", + minus: "M5 12h14", + x: "M18 6 6 18M6 6l12 12", + refresh: "M3 12a9 9 0 0 1 9-9 9 9 0 0 1 6.7 3L21 8M21 3v5h-5 M21 12a9 9 0 0 1-9 9 9 9 0 0 1-6.7-3L3 16M3 21v-5h5", +}; + +// Built with createElementNS rather than Obsidian's createSvg helper, whose +// availability varies by version. This works on any Obsidian build. +const SVG_NS = "http://www.w3.org/2000/svg"; + +function addIcon(parent, name) { + const svg = document.createElementNS(SVG_NS, "svg"); + svg.setAttribute("viewBox", "0 0 24 24"); + svg.setAttribute("fill", "none"); + svg.setAttribute("aria-hidden", "true"); + const path = document.createElementNS(SVG_NS, "path"); + path.setAttribute("d", ICONS[name]); + path.setAttribute("stroke", "currentColor"); + path.setAttribute("stroke-width", "1.75"); + path.setAttribute("stroke-linecap", "round"); + path.setAttribute("stroke-linejoin", "round"); + svg.appendChild(path); + parent.appendChild(svg); + return svg; +} + +function formatBytes(n) { + return `${n.toLocaleString("en-US")} B`; +} + +function renderLeftPane(container, pipeline, onIngest) { + const pane = container.createDiv({ cls: "wd-pane" }); + + const queue = pane.createDiv({ cls: "wd-block" }); + queue.createDiv({ + cls: "wd-eyebrow", + text: `Queue — ${pipeline.unprocessed.length} unprocessed`, + }); + if (pipeline.unprocessed.length === 0) { + queue.createDiv({ cls: "wd-note", text: "Every raw source has a summary page." }); + } + for (const file of pipeline.unprocessed) { + const row = queue.createDiv({ cls: "wd-row" }); + const main = row.createDiv({ cls: "wd-row-main" }); + main.createDiv({ cls: "wd-row-name", text: file.name }); + main.createDiv({ cls: "wd-mono", text: formatBytes(file.size) }); + const btn = row.createEl("button", { cls: "wd-btn" }); + addIcon(btn, "terminal"); + btn.createSpan({ text: "Ingest" }); + btn.addEventListener("click", () => onIngest(file, row)); + } + + const done = pane.createDiv({ cls: "wd-block" }); + done.createDiv({ cls: "wd-eyebrow", text: `Ingested — ${pipeline.processed.length}` }); + const list = done.createDiv({ cls: "wd-done" }); + for (const file of pipeline.processed) { + const row = list.createDiv({ cls: "wd-done-row" }); + const date = file.page.name.slice(0, 10); + row.createSpan({ cls: "wd-mono", text: /^\d{4}-\d{2}-\d{2}$/.test(date) ? date : "—" }); + row.createSpan({ cls: "wd-done-name", text: file.name.replace(/\.md$/, "") }); + } + + if (pipeline.orphaned.length > 0) { + const orphan = pane.createDiv({ cls: "wd-block" }); + orphan.createDiv({ + cls: "wd-eyebrow", + text: `Orphaned — ${pipeline.orphaned.length}`, + }); + for (const page of pipeline.orphaned) { + const row = orphan.createDiv({ cls: "wd-done-row" }); + row.createSpan({ cls: "wd-done-name", text: page.name }); + row.createSpan({ cls: "wd-mono", text: page.rawPath || "no raw path" }); + } + } + + return pane; +} +``` + +- [ ] **Step 3: Replace the plugin class body to read the vault and render** + +`vault.getFiles()` returns every markdown file; filter by path prefix. `vault.cachedRead` is the correct read for display purposes. + +```js +class WebinarDashPlugin extends PluginBase { + async onload() { + this.registerMarkdownCodeBlockProcessor("webinar-dash", async (source, el, ctx) => { + const cfg = parseConfig(source); + const root = el.createDiv({ cls: "webinar-dash" }); + try { + const pipeline = await this.readPipeline(cfg); + renderLeftPane(root, pipeline, () => {}); + } catch (err) { + root.createDiv({ cls: "wd-error", text: `Dashboard failed: ${err.message}` }); + } + }); + } + + async readPipeline(cfg) { + const all = this.app.vault.getFiles(); + const rawDir = cfg.rawDir.replace(/\/+$/, "") + "/"; + const wikiDir = cfg.wikiSourceDir.replace(/\/+$/, "") + "/"; + + const rawFiles = all + .filter((f) => f.path.startsWith(rawDir) && f.extension === "md") + .map((f) => ({ path: f.path, name: f.name, size: f.stat.size })); + + const pageFiles = all.filter((f) => f.path.startsWith(wikiDir) && f.extension === "md"); + const sourcePages = []; + for (const f of pageFiles) { + const text = await this.app.vault.cachedRead(f); + sourcePages.push({ path: f.path, name: f.name, rawPath: extractRawPath(text) }); + } + + return derivePipeline({ rawFiles, sourcePages }); + } +} +``` + +- [ ] **Step 4: Verify in Obsidian** + +Reload the app (`Ctrl+R`) and open `dashboard.md` in reading view. + +Expected, against the vault's current state: +- `Queue — 3 unprocessed` listing `Agentic Engineering, explained by a 10x developer.md` (15,020 B), `Webinar Plan - From Chat Box to Your Own OS.md` (17,177 B), and `Webinar script.md` (15,841 B), each with a red **Ingest** button that does nothing yet. +- `Ingested — 9` listing the source summaries newest first, starting with `2026-07-24`. +- No orphaned block. + +- [ ] **Step 5: Run the existing tests to confirm nothing regressed** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar/.obsidian/plugins/webinar-dash" +node --test test/ +``` + +Expected: PASS, 6 tests. + +- [ ] **Step 6: Commit** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar" +git add .obsidian/plugins/webinar-dash +git commit -m "feat: render source pipeline in left pane" +``` + +--- + +### Task 4: Coverage table parser + +**Files:** +- Modify: `.obsidian/plugins/webinar-dash/main.js` +- Test: `.obsidian/plugins/webinar-dash/test/coverage.test.js` + +**Interfaces:** +- Consumes: `STATIONS` from Task 1 +- Produces: + - `parseCoverageTable(markdown) => { meta, rows, errors }` + - `meta`: `{ script: string | null, lastSynced: string | null }` + - `rows` items: `{ concept: string, status: "covered"|"partial"|"absent", stations: string[], pinned: boolean, line: number }` + - `errors` items: `{ line: number, text: string, reason: string }` + - `groupByStation(rows) => Array<{ station: string, rows: Row[] }>` ordered `All stations`, then the seven stations, then `No station`; empty groups omitted + +- [ ] **Step 1: Write the failing tests** + +Create `.obsidian/plugins/webinar-dash/test/coverage.test.js`. + +```js +"use strict"; +const test = require("node:test"); +const assert = require("node:assert/strict"); +const { parseCoverageTable, groupByStation } = require("../main.js").__test__; + +const DOC = [ + "# Script coverage", + "", + "#coverage", + "", + "## Metadata", + "", + "- **Script:** `raw/sources/Webinar script.md`", + "- **Last synced:** 2026-07-28", + "", + "## Coverage", + "", + "| Concept | Status | Station | Pinned |", + "|---|---|---|---|", + "| [[harness]] | covered | Tools | |", + "| [[agentic-loops]] | partial | Process | |", + "| [[levels-of-ai-usage]] | partial | all | |", + "| [[connections-as-moat]] | absent | — | yes |", +].join("\n"); + +test("parseCoverageTable reads metadata", () => { + const { meta } = parseCoverageTable(DOC); + assert.equal(meta.script, "raw/sources/Webinar script.md"); + assert.equal(meta.lastSynced, "2026-07-28"); +}); + +test("parseCoverageTable reads every data row and skips the header", () => { + const { rows, errors } = parseCoverageTable(DOC); + assert.equal(errors.length, 0); + assert.equal(rows.length, 4); + assert.deepEqual(rows.map((r) => r.concept), [ + "harness", "agentic-loops", "levels-of-ai-usage", "connections-as-moat", + ]); +}); + +test("parseCoverageTable normalises stations", () => { + const { rows } = parseCoverageTable(DOC); + assert.deepEqual(rows[0].stations, ["Tools"]); + assert.deepEqual(rows[2].stations, ["all"]); + assert.deepEqual(rows[3].stations, []); +}); + +test("parseCoverageTable reads the pinned flag", () => { + const { rows } = parseCoverageTable(DOC); + assert.equal(rows[0].pinned, false); + assert.equal(rows[3].pinned, true); +}); + +test("parseCoverageTable strips a wikilink alias", () => { + const doc = "| Concept | Status | Station |\n|---|---|---|\n| [[harness\\|The harness]] | covered | Tools |"; + const { rows } = parseCoverageTable(doc); + assert.equal(rows[0].concept, "harness"); +}); + +test("parseCoverageTable splits a multi-station cell", () => { + const doc = "| C | S | St |\n|---|---|---|\n| [[x]] | covered | Tools, Memory |"; + const { rows } = parseCoverageTable(doc); + assert.deepEqual(rows[0].stations, ["Tools", "Memory"]); +}); + +test("parseCoverageTable rejects an invalid status instead of coercing it", () => { + const doc = "| C | S | St |\n|---|---|---|\n| [[x]] | maybe | Tools |"; + const { rows, errors } = parseCoverageTable(doc); + assert.equal(rows.length, 0); + assert.equal(errors.length, 1); + assert.match(errors[0].reason, /invalid status/); + assert.equal(errors[0].line, 3); +}); + +test("parseCoverageTable reports a row with too few columns", () => { + const doc = "| C | S | St |\n|---|---|---|\n| [[x]] | covered |"; + const { rows, errors } = parseCoverageTable(doc); + assert.equal(rows.length, 0); + assert.equal(errors.length, 1); + assert.match(errors[0].reason, /at least 3 columns/); +}); + +test("parseCoverageTable returns empty results for a document with no table", () => { + const { rows, errors } = parseCoverageTable("# Nothing\n\nJust prose."); + assert.equal(rows.length, 0); + assert.equal(errors.length, 0); +}); + +test("groupByStation orders all-stations first and no-station last", () => { + const { rows } = parseCoverageTable(DOC); + const groups = groupByStation(rows); + assert.deepEqual(groups.map((g) => g.station), [ + "All stations", "Tools", "Process", "No station", + ]); + assert.equal(groups[1].rows[0].concept, "harness"); +}); + +test("groupByStation places a multi-station row under its first station only", () => { + const rows = [{ concept: "x", status: "covered", stations: ["Memory", "Skills"], pinned: false, line: 1 }]; + const groups = groupByStation(rows); + assert.equal(groups.length, 1); + assert.equal(groups[0].station, "Memory"); +}); +``` + +- [ ] **Step 2: Run the tests to verify they fail** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar/.obsidian/plugins/webinar-dash" +node --test test/coverage.test.js +``` + +Expected: FAIL — `parseCoverageTable is not a function`. + +- [ ] **Step 3: Implement the parser** + +Insert into `main.js` below `derivePipeline`. The `inTable` flag flips on the `|---|` separator, which is what distinguishes the header row from data rows. + +```js +const VALID_STATUS = new Set(["covered", "partial", "absent"]); +const SEPARATOR_RE = /^\|?\s*:?-{2,}/; + +function parseCoverageTable(markdown) { + const text = String(markdown); + const meta = { script: null, lastSynced: null }; + + const scriptM = text.match(/^\s*-\s*\*\*Script:\*\*\s*`([^`]+)`/m); + if (scriptM) meta.script = scriptM[1].trim(); + const syncM = text.match(/^\s*-\s*\*\*Last synced:\*\*\s*(\S+)/m); + if (syncM) meta.lastSynced = syncM[1].trim(); + + const rows = []; + const errors = []; + let inTable = false; + + text.split(/\r?\n/).forEach((line, i) => { + const t = line.trim(); + if (!t.startsWith("|")) { + inTable = false; + return; + } + if (SEPARATOR_RE.test(t)) { + inTable = true; + return; + } + if (!inTable) return; + + const body = t.endsWith("|") ? t.slice(1, -1) : t.slice(1); + const cells = body.split("|").map((c) => c.trim()); + + if (cells.length < 3) { + errors.push({ line: i + 1, text: t, reason: "expected at least 3 columns" }); + return; + } + + const status = cells[1].toLowerCase(); + if (!VALID_STATUS.has(status)) { + errors.push({ line: i + 1, text: t, reason: `invalid status "${cells[1]}"` }); + return; + } + + // Capture up to the first ] | or backslash. Obsidian escapes the pipe in a + // piped wikilink inside a table cell, so the raw cell reads [[name\|alias]] — + // excluding the backslash is what keeps the trailing "\" out of the name. + const linkM = cells[0].match(/\[\[([^\]|\\]+)/); + const stationCell = cells[2]; + + rows.push({ + concept: linkM ? linkM[1].trim() : cells[0], + status, + stations: + stationCell === "—" || stationCell === "-" || stationCell === "" + ? [] + : stationCell.split(",").map((s) => s.trim()).filter(Boolean), + pinned: (cells[3] || "").toLowerCase() === "yes", + line: i + 1, + }); + }); + + return { meta, rows, errors }; +} + +function groupByStation(rows) { + const order = ["All stations", ...STATIONS, "No station"]; + const buckets = new Map(order.map((k) => [k, []])); + + for (const row of rows) { + let key; + if (row.stations.includes("all")) key = "All stations"; + else if (row.stations.length === 0) key = "No station"; + else key = row.stations[0]; + if (!buckets.has(key)) buckets.set(key, []); + buckets.get(key).push(row); + } + + const known = order.filter((k) => buckets.get(k).length > 0); + const unknown = [...buckets.keys()].filter((k) => !order.includes(k) && buckets.get(k).length > 0); + return [...known, ...unknown].map((station) => ({ station, rows: buckets.get(station) })); +} +``` + +The `\\|` in the alias test is an escaped pipe inside a JS string, which reaches the parser as a literal `|` — matching how Obsidian escapes piped wikilinks inside table cells. + +- [ ] **Step 4: Export them** + +```js +module.exports.__test__ = { + parseConfig, extractRawPath, derivePipeline, + parseCoverageTable, groupByStation, + STATIONS, DEFAULTS, +}; +``` + +- [ ] **Step 5: Run the tests to verify they pass** + +```bash +node --test test/coverage.test.js +``` + +Expected: PASS, 11 tests. + +- [ ] **Step 6: Commit** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar" +git add .obsidian/plugins/webinar-dash +git commit -m "feat: parse the script coverage table" +``` + +--- + +### Task 5: Coverage data file and CLAUDE.md contract + +This is the wiki-side task. It creates the file the renderer reads and installs the rule that keeps it current. No plugin code changes. + +**Files:** +- Create: `wiki/script-coverage.md` +- Modify: `CLAUDE.md` (Folder Convention, Tagging Rules, Standard Workflows, Operational Commands) +- Modify: `index.md` +- Modify: `log.md` + +**Interfaces:** +- Consumes: the row format defined in Task 4 +- Produces: `wiki/script-coverage.md` conforming to that format, with one row per page in `wiki/concepts/` + +- [ ] **Step 1: Create `wiki/script-coverage.md`** + +Statuses below are the assessment made during design, read from `raw/sources/Webinar script.md` against each concept page. All 19 concept pages are present. + +```markdown +# Script coverage + +#coverage + +## Metadata + +- **Script:** `raw/sources/Webinar script.md` +- **Last synced:** 2026-07-28 +- **Stations:** Chat box · ReAct · Tools · Memory · Skills · Process · OS + +## Coverage + +| Concept | Status | Station | Pinned | +|---|---|---|---| +| [[harness]] | covered | Tools | | +| [[evolution-of-agent-tooling]] | covered | Tools | | +| [[skills-as-memory]] | covered | Skills | | +| [[solve-first-then-skillify]] | covered | Skills | | +| [[personal-ai-operating-system]] | covered | OS | | +| [[context-as-scarce-resource]] | partial | Memory | | +| [[agentic-loops]] | partial | Process | | +| [[code-as-throwaway]] | partial | OS | | +| [[levels-of-ai-usage]] | partial | all | | +| [[integration-dead-ends]] | absent | — | | +| [[leave-less-room-for-imagination]] | absent | — | | +| [[product-ownership]] | absent | — | | +| [[connections-as-moat]] | absent | — | | +| [[network-from-a-standing-start]] | absent | — | | +| [[seniority-and-the-junior-squeeze]] | absent | — | | +| [[decoupling-identity-from-profession]] | absent | — | | +| [[think-wider-not-bigger]] | absent | — | | +| [[make-more-cheap-code]] | absent | — | | +| [[enterprise-ai-reality]] | absent | — | | + +## Notes + +- The script is entirely machine-side. Every absent concept is human-side or strategy-side. +- The `ReAct` station carries no wiki concept at all. +- Set `Pinned` to `yes` on any row whose status is a deliberate decision. Sync will not touch it. + +## Related Pages + +- [[overview]] +- `raw/sources/Webinar script.md` +``` + +- [ ] **Step 2: Add the file to the folder convention in `CLAUDE.md`** + +In the `## Folder Convention` code block, add below the `wiki/overview.md` line: + +```text + script-coverage.md # machine-maintained: concept coverage vs the webinar script +``` + +- [ ] **Step 3: Add the tag row in `CLAUDE.md`** + +In the Folder → tag table under `## Tagging Rules`, add a row after the `wiki/overview.md` row: + +```text +| `wiki/script-coverage.md` | `#coverage` | +``` + +- [ ] **Step 4: Add Workflow D to `CLAUDE.md`** + +Append to `## Standard Workflows`, after Workflow C: + +```markdown +### Workflow D: Sync Script Coverage + +Maintains `wiki/script-coverage.md` — one row per page in `wiki/concepts/`, judged +against the script named in that file's `**Script:**` metadata field. + +1. Read `wiki/script-coverage.md` and note every row where `Pinned` is `yes`. +2. Read the script and every page in `wiki/concepts/`. +3. For each concept, decide `Status` and `Station`: + - `covered` — the script delivers the idea, whether or not it uses the page's name. + - `partial` — the script gestures at it but never lands it. + - `absent` — the script never reaches it. + - `Station` is one of the seven, a comma-separated list, `all`, or `—` when absent. +4. **Never modify a row whose `Pinned` is `yes`** — not its status, not its station. + A pinned row is the user's judgment and outranks yours. +5. Add rows for concept pages with no row. Remove rows whose concept page no longer exists. +6. Update `**Last synced:**` to today. +7. Update `index.md` and append a `sync` entry to `log.md`. + +Run this workflow: + +- at the end of any ingest that creates or modifies a page in `wiki/concepts/` +- whenever the script file itself changes +- on the explicit `sync script coverage` intent + +The coverage baseline is always the raw script. Ingesting the script into +`wiki/sources/` does not change the baseline. +``` + +- [ ] **Step 5: Add the intent to `CLAUDE.md`** + +In `## Operational Commands (Natural Language)`, add to the supported intents list: + +```markdown +- "sync script coverage" +``` + +- [ ] **Step 6: Update `index.md`** + +Add a section after `## Sources`, and correct the stale not-yet-ingested line. + +```markdown +## Coverage + +- [[script-coverage]] — every concept vs `raw/sources/Webinar script.md`; 5 covered, 4 partial, 10 absent +``` + +Replace the existing `**Raw, not yet ingested:**` line with the accurate set — the two note files live in `raw/notes/`, not `raw/sources/`, and one raw source was missing entirely: + +```markdown +**Raw, not yet ingested:** `raw/sources/Agentic Engineering, explained by a 10x developer.md` · `raw/sources/Webinar Plan - From Chat Box to Your Own OS.md` · `raw/sources/Webinar script.md` +``` + +- [ ] **Step 7: Append to `log.md`** + +```markdown +## 2026-07-28 — sync (script coverage, initial) +- Intent: sync script coverage +- Input: first run of Workflow D, establishing `wiki/script-coverage.md`. +- Pages created: [[script-coverage]] (coverage) — 19 rows, one per concept page. +- Pages updated: `CLAUDE.md` (folder convention, `#coverage` tag row, Workflow D, new intent), `index.md` (new Coverage section; corrected the not-yet-ingested list — `Ideas for webinar.md` and `my theses.md` were listed under `raw/sources/` but live in `raw/notes/`, and `Agentic Engineering, explained by a 10x developer.md` was missing entirely). +- Notes: Initial assessment is 5 covered, 4 partial, 10 absent. Every absent concept is human-side or strategy-side — the script is entirely machine-side. The `ReAct` station carries no wiki concept. No concept pages were edited. +- Next: decide whether the human-side cluster earns a station or is a deliberate cut; pin the rows that are decided so future syncs leave them alone. +``` + +- [ ] **Step 8: Verify the file parses** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar/.obsidian/plugins/webinar-dash" +node -e " +const fs = require('fs'); +const { parseCoverageTable } = require('./main.js').__test__; +const md = fs.readFileSync('../../../wiki/script-coverage.md', 'utf8'); +const r = parseCoverageTable(md); +console.log('rows:', r.rows.length, 'errors:', r.errors.length); +console.log('meta:', r.meta); +if (r.errors.length) { console.log(r.errors); process.exit(1); } +if (r.rows.length !== 19) { console.log('expected 19 rows'); process.exit(1); } +" +``` + +Expected: `rows: 19 errors: 0` and metadata showing the script path and `2026-07-28`. + +- [ ] **Step 9: Commit** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar" +git add wiki/script-coverage.md CLAUDE.md index.md log.md +git commit -m "feat: add script coverage file and Workflow D sync contract" +``` + +--- + +### Task 6: Right pane — coverage rendering + +**Files:** +- Modify: `.obsidian/plugins/webinar-dash/main.js` +- Modify: `.obsidian/plugins/webinar-dash/styles.css` + +**Interfaces:** +- Consumes: `parseCoverageTable`, `groupByStation` from Task 4; `addIcon` from Task 3; `wiki/script-coverage.md` from Task 5 +- Produces: + - `reconcileConcepts(rows, conceptNames) => { rows, unsynced, stale }` where `unsynced` is concept names with no row and `stale` is rows whose concept page is gone + - `renderRightPane(container, parsed, reconciled)` + +- [ ] **Step 1: Add the reconcile helper and its tests** + +Append to `.obsidian/plugins/webinar-dash/test/coverage.test.js`: + +```js +const { reconcileConcepts } = require("../main.js").__test__; + +test("reconcileConcepts finds concept pages with no row", () => { + const rows = [{ concept: "harness", status: "covered", stations: ["Tools"], pinned: false, line: 1 }]; + const out = reconcileConcepts(rows, ["harness", "brand-new-concept"]); + assert.deepEqual(out.unsynced, ["brand-new-concept"]); + assert.deepEqual(out.stale, []); +}); + +test("reconcileConcepts finds rows whose concept page is gone", () => { + const rows = [ + { concept: "harness", status: "covered", stations: ["Tools"], pinned: false, line: 1 }, + { concept: "deleted-idea", status: "absent", stations: [], pinned: false, line: 2 }, + ]; + const out = reconcileConcepts(rows, ["harness"]); + assert.deepEqual(out.stale.map((r) => r.concept), ["deleted-idea"]); + assert.deepEqual(out.unsynced, []); +}); +``` + +- [ ] **Step 2: Run the tests to verify they fail** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar/.obsidian/plugins/webinar-dash" +node --test test/coverage.test.js +``` + +Expected: FAIL — `reconcileConcepts is not a function`. + +- [ ] **Step 3: Implement `reconcileConcepts` and export it** + +Insert into `main.js` below `groupByStation`: + +```js +function reconcileConcepts(rows, conceptNames) { + const named = new Set(conceptNames); + const rowed = new Set(rows.map((r) => r.concept)); + return { + rows, + unsynced: conceptNames.filter((n) => !rowed.has(n)).sort(), + stale: rows.filter((r) => !named.has(r.concept)), + }; +} +``` + +Add `reconcileConcepts` to the `__test__` export object. + +- [ ] **Step 4: Run the tests to verify they pass** + +```bash +node --test test/coverage.test.js +``` + +Expected: PASS, 13 tests. + +- [ ] **Step 5: Add the coverage styles** + +Append to `styles.css`: + +```css +.wd-meter { display: flex; gap: 2px; height: 8px; width: 100%; } +.wd-meter > i { display: block; height: 100%; } +.wd-seg-covered { background: var(--wd-ok); } +.wd-seg-partial { background: var(--wd-warn); } +.wd-seg-absent { background: var(--wd-danger); } + +.wd-key { display: flex; flex-wrap: wrap; gap: 16px; font-size: 12px; color: var(--wd-fg-2); } +.wd-key > span { display: inline-flex; align-items: center; gap: 6px; } +.wd-key i { width: 8px; height: 8px; flex: none; } + +.wd-tbl { width: 100%; border-collapse: collapse; font-size: 13px; } +.wd-tbl th { + font-family: var(--wd-mono); font-size: 10px; letter-spacing: 0.1em; + text-transform: uppercase; color: var(--wd-fg-3); font-weight: 500; + text-align: left; padding: 0 12px 8px 0; + border-bottom: 1px solid var(--wd-border-strong); +} +.wd-tbl td { + padding: 6px 12px 6px 0; border-bottom: 1px solid var(--wd-border-subtle); + vertical-align: baseline; +} +.wd-grp td { + padding-top: 16px; border-bottom: 1px solid var(--wd-border-strong); + font-family: var(--wd-mono); font-size: 10px; letter-spacing: 0.1em; + text-transform: uppercase; color: var(--wd-fg); font-weight: 500; +} +.wd-stat { display: inline-flex; align-items: center; gap: 5px; font-size: 12px; font-weight: 600; } +.wd-stat svg { width: 13px; height: 13px; flex: none; } +.wd-covered { color: var(--wd-ok); } +.wd-partial { color: var(--wd-warn); } +.wd-absent { color: var(--wd-danger); } +.wd-pin { font-family: var(--wd-mono); font-size: 10px; color: var(--wd-fg-4); } +``` + +- [ ] **Step 6: Add the right-pane renderer** + +Insert into `main.js` below `renderLeftPane`: + +```js +const STATUS_ICON = { covered: "check", partial: "minus", absent: "x" }; + +function renderRightPane(container, parsed, reconciled) { + const pane = container.createDiv({ cls: "wd-pane" }); + pane.createDiv({ cls: "wd-eyebrow", text: "Coverage — by station" }); + + const counts = { covered: 0, partial: 0, absent: 0 }; + for (const row of parsed.rows) counts[row.status] += 1; + const total = parsed.rows.length; + + if (total > 0) { + const meter = pane.createDiv({ cls: "wd-meter" }); + meter.setAttr( + "aria-label", + `Coverage: ${counts.covered} covered, ${counts.partial} partial, ${counts.absent} absent of ${total}` + ); + for (const key of ["covered", "partial", "absent"]) { + if (counts[key] === 0) continue; + const seg = meter.createEl("i", { cls: `wd-seg-${key}` }); + seg.style.flex = String(counts[key]); + } + const key = pane.createDiv({ cls: "wd-key" }); + for (const name of ["covered", "partial", "absent"]) { + const span = key.createSpan(); + span.createEl("i", { cls: `wd-seg-${name}` }); + span.createSpan({ text: `${counts[name]} ${name}` }); + } + } + + if (parsed.errors.length > 0) { + const box = pane.createDiv({ cls: "wd-error" }); + box.createDiv({ text: `${parsed.errors.length} unparseable row(s):` }); + for (const e of parsed.errors) { + box.createDiv({ cls: "wd-mono", text: `line ${e.line} — ${e.reason}` }); + } + } + + const table = pane.createEl("table", { cls: "wd-tbl" }); + const head = table.createEl("thead").createEl("tr"); + for (const h of ["Concept", "Status", "Station", ""]) head.createEl("th", { text: h }); + const body = table.createEl("tbody"); + + for (const group of groupByStation(parsed.rows)) { + const gr = body.createEl("tr", { cls: "wd-grp" }); + gr.createEl("td", { attr: { colspan: "4" }, text: `${group.station} — ${group.rows.length}` }); + for (const row of group.rows) { + const tr = body.createEl("tr"); + // Obsidian's click handler resolves internal links via data-href, so both + // attributes are required for the link to open the concept page. + tr.createEl("td").createEl("a", { + cls: "internal-link", + text: row.concept, + attr: { href: row.concept, "data-href": row.concept }, + }); + const stat = tr.createEl("td").createSpan({ cls: `wd-stat wd-${row.status}` }); + addIcon(stat, STATUS_ICON[row.status]); + stat.createSpan({ text: row.status }); + tr.createEl("td", { cls: "wd-mono", text: row.stations.join(", ") || "—" }); + tr.createEl("td", { cls: "wd-pin", text: row.pinned ? "pinned" : "" }); + } + } + + if (reconciled.unsynced.length > 0) { + const box = pane.createDiv({ cls: "wd-block" }); + box.createDiv({ cls: "wd-eyebrow", text: `Unsynced — ${reconciled.unsynced.length}` }); + box.createDiv({ + cls: "wd-note", + text: `Concept pages with no row. Run "sync script coverage": ${reconciled.unsynced.join(", ")}`, + }); + } + + if (reconciled.stale.length > 0) { + const box = pane.createDiv({ cls: "wd-block" }); + box.createDiv({ cls: "wd-eyebrow", text: `Stale — ${reconciled.stale.length}` }); + box.createDiv({ + cls: "wd-note", + text: `Rows whose concept page is gone: ${reconciled.stale.map((r) => r.concept).join(", ")}`, + }); + } + + return pane; +} +``` + +- [ ] **Step 7: Wire it into the plugin class** + +Replace the code-block processor callback and add a reader method: + +```js + this.registerMarkdownCodeBlockProcessor("webinar-dash", async (source, el, ctx) => { + const cfg = parseConfig(source); + const root = el.createDiv({ cls: "webinar-dash" }); + try { + const pipeline = await this.readPipeline(cfg); + renderLeftPane(root, pipeline, () => {}); + } catch (err) { + root.createDiv({ cls: "wd-error", text: `Pipeline failed: ${err.message}` }); + } + try { + const { parsed, reconciled } = await this.readCoverage(cfg); + renderRightPane(root, parsed, reconciled); + } catch (err) { + root.createDiv({ cls: "wd-error", text: `Coverage failed: ${err.message}` }); + } + }); +``` + +The two panes render in separate `try` blocks so a broken coverage file never blanks the source pipeline. + +```js + async readCoverage(cfg) { + const file = this.app.vault.getAbstractFileByPath(cfg.coverage); + if (!file) throw new Error(`no coverage file at ${cfg.coverage}`); + const parsed = parseCoverageTable(await this.app.vault.cachedRead(file)); + + const conceptDir = cfg.conceptDir.replace(/\/+$/, "") + "/"; + const conceptNames = this.app.vault + .getFiles() + .filter((f) => f.path.startsWith(conceptDir) && f.extension === "md") + .map((f) => f.basename); + + return { parsed, reconciled: reconcileConcepts(parsed.rows, conceptNames) }; + } +``` + +- [ ] **Step 8: Verify in Obsidian** + +Reload (`Ctrl+R`) and open `dashboard.md`. + +Expected: a right pane with a meter reading `5 covered`, `4 partial`, `10 absent`; a table grouped `All stations — 1`, `Tools — 2`, `Memory — 1`, `Skills — 2`, `Process — 1`, `OS — 2`, `No station — 10`; no unsynced block; no stale block; concept names clickable through to their pages. + +- [ ] **Step 9: Commit** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar" +git add .obsidian/plugins/webinar-dash +git commit -m "feat: render coverage meter and station-grouped table" +``` + +--- + +### Task 7: Headless ingest + +**Files:** +- Modify: `.obsidian/plugins/webinar-dash/main.js` +- Modify: `.obsidian/plugins/webinar-dash/styles.css` +- Test: `.obsidian/plugins/webinar-dash/test/safety.test.js` + +**Interfaces:** +- Consumes: `renderLeftPane`'s `onIngest(file, rowEl)` callback from Task 3 +- Produces: + - `isSafeFilename(name) => boolean` + - `runIngest(file, rowEl)` as a plugin method + +- [ ] **Step 1: Write the failing tests** + +Create `.obsidian/plugins/webinar-dash/test/safety.test.js`. The accept cases are real filenames from this vault. + +```js +"use strict"; +const test = require("node:test"); +const assert = require("node:assert/strict"); +const { isSafeFilename } = require("../main.js").__test__; + +test("isSafeFilename accepts every filename currently in the vault", () => { + const real = [ + "Agentic Engineering, explained by a 10x developer.md", + "Webinar Plan - From Chat Box to Your Own OS.md", + "Webinar script.md", + "You're reading way too much code.md", + "ИИ глупый!.md", + "Скиллы на базе git — новая память AI-агентов.md", + "sebastian interview - conclusions and insights.md", + "In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible.md", + ]; + for (const name of real) { + assert.equal(isSafeFilename(name), true, `should accept: ${name}`); + } +}); + +test("isSafeFilename rejects shell metacharacters", () => { + for (const bad of ['a".md', "a`b.md", "a$b.md", "a&b.md", "a|b.md", "a;b.md", + "a<b.md", "a>b.md", "a%b.md", "a\nb.md", "a\rb.md"]) { + assert.equal(isSafeFilename(bad), false, `should reject: ${JSON.stringify(bad)}`); + } +}); + +test("isSafeFilename rejects path traversal", () => { + assert.equal(isSafeFilename("../secrets.md"), false); + assert.equal(isSafeFilename("a/../../b.md"), false); +}); + +test("isSafeFilename rejects empty and non-string input", () => { + assert.equal(isSafeFilename(""), false); + assert.equal(isSafeFilename(null), false); + assert.equal(isSafeFilename(undefined), false); + assert.equal(isSafeFilename(42), false); +}); +``` + +- [ ] **Step 2: Run the tests to verify they fail** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar/.obsidian/plugins/webinar-dash" +node --test test/safety.test.js +``` + +Expected: FAIL — `isSafeFilename is not a function`. + +- [ ] **Step 3: Implement the validator and export it** + +Insert into `main.js` below `reconcileConcepts`: + +```js +// `shell: true` is required on Windows to resolve `claude.cmd`, which puts the +// filename into a shell string. Reject anything cmd.exe or a POSIX shell would +// interpret. Apostrophes and cyrillic are safe inside double quotes and are +// present in real filenames, so they stay allowed. +const UNSAFE_CHARS = /["`$&|;<>%\r\n]/; + +function isSafeFilename(name) { + if (typeof name !== "string" || name.length === 0) return false; + if (UNSAFE_CHARS.test(name)) return false; + if (name.includes("..")) return false; + return true; +} +``` + +Add `isSafeFilename` to the `__test__` export object. + +- [ ] **Step 4: Run the tests to verify they pass** + +```bash +node --test test/safety.test.js +``` + +Expected: PASS, 4 tests. + +- [ ] **Step 5: Add ingest-state styles** + +Append to `styles.css`: + +```css +.wd-status { font-family: var(--wd-mono); font-size: 11px; flex: none; } +.wd-status-running { color: var(--wd-warn); } +.wd-status-done { color: var(--wd-ok); } +.wd-status-failed { color: var(--wd-danger); } +.wd-output { + font-family: var(--wd-mono); font-size: 11px; white-space: pre-wrap; + max-height: 220px; overflow: auto; margin-top: 8px; + border: 1px solid var(--wd-border); border-radius: 4px; padding: 8px; + color: var(--wd-fg-2); +} +``` + +- [ ] **Step 6: Implement `runIngest` on the plugin class** + +`getBasePath()` exists on `FileSystemAdapter`; on mobile the adapter is a different class and `child_process` is unavailable, which is why the manifest sets `isDesktopOnly`. + +```js + vaultPath() { + const adapter = this.app.vault.adapter; + if (typeof adapter.getBasePath === "function") return adapter.getBasePath(); + return null; + } + + runIngest(file, rowEl) { + if (rowEl.dataset.wdRunning === "1") return; + + const Notice = OB ? OB.Notice : null; + const notify = (msg) => { if (Notice) new Notice(msg); }; + + if (!isSafeFilename(file.name)) { + rowEl.createDiv({ + cls: "wd-output", + text: `Refused: "${file.name}" contains a character that is unsafe to pass to a shell.`, + }); + return; + } + + const base = this.vaultPath(); + if (!base) { + notify("Ingest needs desktop Obsidian."); + return; + } + + let spawn; + try { + ({ spawn } = require("child_process")); + } catch (_) { + notify("child_process unavailable — ingest needs desktop Obsidian."); + return; + } + + rowEl.dataset.wdRunning = "1"; + const button = rowEl.querySelector("button"); + if (button) button.disabled = true; + + const status = rowEl.createSpan({ cls: "wd-status wd-status-running", text: "running 0s" }); + const started = Date.now(); + const timer = window.setInterval(() => { + status.setText(`running ${Math.round((Date.now() - started) / 1000)}s`); + }, 1000); + + const output = rowEl.createDiv({ cls: "wd-output", text: "" }); + let buffered = ""; + const append = (chunk) => { + buffered += chunk.toString(); + output.setText(buffered.slice(-4000)); + output.scrollTop = output.scrollHeight; + }; + + const child = spawn("claude", ["-p", `ingest "${file.name}"`], { + cwd: base, + shell: true, + }); + + child.stdout.on("data", append); + child.stderr.on("data", append); + + child.on("error", (err) => { + window.clearInterval(timer); + status.className = "wd-status wd-status-failed"; + status.setText("failed"); + append(`\nCould not start claude: ${err.message}\nIs it on PATH?`); + rowEl.dataset.wdRunning = "0"; + if (button) button.disabled = false; + }); + + child.on("close", (code) => { + window.clearInterval(timer); + const secs = Math.round((Date.now() - started) / 1000); + if (code === 0) { + status.className = "wd-status wd-status-done"; + status.setText(`done in ${secs}s`); + notify(`Ingested ${file.name}. Reopen the dashboard to refresh.`); + } else { + status.className = "wd-status wd-status-failed"; + status.setText(`failed - exit ${code}`); + } + rowEl.dataset.wdRunning = "0"; + if (button) button.disabled = false; + }); + } +``` + +- [ ] **Step 7: Pass the real handler into the left pane** + +In the code-block processor, replace the no-op: + +```js + renderLeftPane(root, pipeline, (file, rowEl) => this.runIngest(file, rowEl)); +``` + +- [ ] **Step 8: Verify the refusal path without spawning anything** + +Temporarily rename a raw file to include a shell metacharacter, reload, and click Ingest. + +```bash +cd "D:/Projects/Notes/Webinar/Webinar/raw/sources" +cp "Webinar script.md" 'bad&name.md' +``` + +Expected in Obsidian: the row shows `Refused: "bad&name.md" contains a character that is unsafe to pass to a shell.` and no process starts. + +Then remove it: + +```bash +rm 'bad&name.md' +``` + +- [ ] **Step 9: Verify a real ingest** + +Reload Obsidian and click **Ingest** on `Agentic Engineering, explained by a 10x developer.md`. + +Expected: the button disables, the status ticks `running 1s`, `running 2s`, …, streamed output appears below the row, and on completion the status reads `done in Ns`. Reopen `dashboard.md`: the queue drops to 2 and the ingested list rises to 10. + +This writes to the vault unsupervised. Everything is committed, so `git diff HEAD` shows exactly what the agent changed and `git checkout -- .` reverts it. + +- [ ] **Step 10: Run the whole suite** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar/.obsidian/plugins/webinar-dash" +node --test test/ +``` + +Expected: PASS, 24 tests across three files. + +- [ ] **Step 11: Commit** + +```bash +cd "D:/Projects/Notes/Webinar/Webinar" +git add .obsidian/plugins/webinar-dash +git commit -m "feat: spawn headless claude ingest with filename validation" +``` + +--- + +## Self-Review + +**Spec coverage.** Every section of the spec maps to a task: + +| Spec section | Task | +|---|---| +| Architecture, config block, no build step | 1 | +| Source pipeline derivation, `**Raw path:**` join | 2 | +| Left pane, tesanti styling, dark mode | 3 | +| Coverage file format, parsing rules | 4 | +| Coverage data file, four `CLAUDE.md` changes, `index.md`, `log.md` | 5 | +| Two-pane layout, meter, station grouping, `unsynced` / `stale` | 6 | +| Ingest spawn, filename rejection list, per-row states, preflight | 7 | +| Failure modes table | 3 (orphaned), 6 (parse errors, unsynced, stale), 7 (no adapter, no `claude`) | + +The spec's "v1 does not write the coverage file from the plugin" is honored — no task adds a pin toggle. + +**Placeholder scan.** No `TBD`, no "add error handling", no "similar to Task N". Every code step carries runnable code. + +**Type consistency.** `rawFiles` items are `{path, name, size}` in Tasks 2 and 3. `sourcePages` items are `{path, name, rawPath}` in both. Coverage rows are `{concept, status, stations, pinned, line}` in Tasks 4, 5, and 6. `onIngest(file, rowEl)` is declared in Task 3 and implemented with the same signature in Task 7. `addIcon(parent, name)` is defined in Task 3 and reused in Task 6. `STATIONS` is defined in Task 1 and consumed by `groupByStation` in Task 4. + +**Test count.** Task 2 adds 7, Task 4 adds 11, Task 6 adds 2, Task 7 adds 4 — 24 total, matching Step 10 of Task 7. diff --git a/docs/superpowers/specs/2026-07-28-webinar-dashboard-design.md b/docs/superpowers/specs/2026-07-28-webinar-dashboard-design.md new file mode 100644 index 0000000..e2b4ceb --- /dev/null +++ b/docs/superpowers/specs/2026-07-28-webinar-dashboard-design.md @@ -0,0 +1,253 @@ +# Webinar vault dashboard — design + +Date: 2026-07-28 +Status: approved, ready for implementation planning + +## Context + +The vault is an LLM-maintained wiki governed by `CLAUDE.md`. It currently holds 12 raw +sources, 9 ingested source summaries, 19 concept pages, and one webinar script +(`raw/sources/Webinar script.md`) that the concepts are supposed to feed. + +Two problems motivated this work: + +1. **The manual catalog drifts.** `index.md` lists `Ideas for webinar.md` and + `my theses.md` under `raw/sources/`, but both live in `raw/notes/`. It does not + mention `Agentic Engineering, explained by a 10x developer.md` at all, which sits + un-ingested in `raw/sources/`. Nothing detects this. +2. **No view of script coverage.** There is no way to see which concept pages the + webinar script actually delivers. A manual read shows the script is entirely + machine-side: all human-side and strategy-side concepts are absent. + +## Goals + +- Show processed and unprocessed sources, with a one-click ingest on the unprocessed. +- Show every concept and whether the webinar script mentions it, plus which script + station it lands in. +- Keep coverage status in a separate markdown file, kept synchronized by a rule in + `CLAUDE.md`. + +## Non-goals + +- Replacing `index.md` or `log.md`. Both stay exactly as they are. +- A general-purpose Obsidian dashboard framework. This is one vault-specific plugin. +- Publishing the plugin to the community plugin registry. + +## Decisions taken + +| Decision | Choice | Rationale | +|---|---|---| +| Buttons | Own plugin, not Meta Bind | Needs are narrow and vault-specific; Meta Bind's expensive half (inline CM6 widgets, two-way frontmatter binding) is unused here | +| Coverage status source | Claude judges; user can pin | Sync sets status automatically, but a row marked `Pinned: yes` is never overwritten | +| Ingest mechanism | Headless `claude -p` via `child_process` | One click, fully automatic. Chosen over a queue file with the unsupervised-write trade-off understood | +| Granularity | Status + script station | Turns the table into a pacing map, not just a checklist | +| Layout | Two-pane (Option B) | Sources and coverage both first-class; coverage grouped by station recovers most of the station-board view | + +## Architecture + +``` +.obsidian/plugins/webinar-dash/ + manifest.json + main.js # plain CommonJS, no build step + styles.css # tesanti tokens scoped to .webinar-dash + +dashboard.md # vault root, beside index.md +wiki/script-coverage.md # the coverage table +``` + +`dashboard.md` holds only a config block; the plugin renders everything: + +````markdown +# Webinar dashboard + +```webinar-dash +script: raw/sources/Webinar script.md +coverage: wiki/script-coverage.md +``` +```` + +Config keys are optional and fall back to those two defaults. + +### Where truth lives + +| Data | Source of truth | Mechanism | +|---|---|---| +| Which sources are processed | Filesystem, read live | Diff `raw/sources/*.md` against the `**Raw path:**` value in every `wiki/sources/*.md` | +| Concept coverage status | `wiki/script-coverage.md` | Written by Claude on sync, read by the plugin | + +Mechanical facts come from the filesystem, judgment comes from the markdown file. +This makes the `index.md` class of drift structurally impossible on the sources half: +the dashboard cannot disagree with the filesystem because it derives from it. + +**The plugin never writes to the vault.** It reads files and spawns one subprocess. +Nothing else. It also never reads `index.md` — the catalog is a human-facing artifact, +and treating it as input would reintroduce exactly the drift this design removes. + +### Source pipeline derivation + +1. List `raw/sources/*.md`. +2. For each `wiki/sources/*.md`, extract the backticked path from the line matching + `**Raw path:** \`<path>\``. Verified consistent across all 9 existing source pages. +3. A raw file claimed by some source page is **processed**; unclaimed is **unprocessed**. +4. A source page whose raw path no longer exists is reported as **orphaned**. + +`raw/notes/` is out of scope — those are notes, not sources. + +## Coverage file format + +```markdown +# Script coverage + +#coverage + +## Metadata + +- **Script:** `raw/sources/Webinar script.md` +- **Last synced:** 2026-07-28 +- **Stations:** Chat box · ReAct · Tools · Memory · Skills · Process · OS + +## Coverage + +| Concept | Status | Station | Pinned | +|---|---|---|---| +| [[harness]] | covered | Tools | | +| [[agentic-loops]] | partial | Process | | +| [[levels-of-ai-usage]] | partial | all | | +| [[connections-as-moat]] | absent | — | yes | +``` + +Field rules: + +- **Concept** — an Obsidian wikilink to a page in `wiki/concepts/`. The plugin extracts + the page name from inside the brackets. +- **Status** — exactly one of `covered`, `partial`, `absent`. Any other value renders as + `invalid` rather than being silently coerced. +- **Station** — one of the seven station names, a comma-separated list of them, `all`, + or `—` for none. +- **Pinned** — `yes`, or blank. Blank is the default. + +The seven stations are the `#` headings of the script that represent technology levels: +Chat box, ReAct, Tools, Memory, Skills, Process, OS. The script's `Intro`, +`Mail from boss`, and `Notes` headings are setup and are not stations. + +v1 does not write this file from the plugin. Pinning is a hand-edit of one cell — a pin +toggle button would make the plugin a writer and risk clobbering concurrent user edits, +which is not worth it for a one-word change. + +## Rendering — two-pane layout + +Left pane (38%): +- **Queue** — unprocessed sources, each row showing filename, byte size, and an + **Ingest** button. Files missing from `index.md` need no special flag: they appear + here purely because no source page claims them, which is how + `Agentic Engineering, explained by a 10x developer.md` surfaces despite being absent + from the catalog. +- **Ingested** — processed sources as compact rows: date from the source page filename + prefix, plus title. + +Right pane (62%): +- Coverage meter — a stacked bar of covered / partial / absent with a 2px gap between + segments, plus a counted key. +- Coverage table grouped by station, with `No station` last. + +Collapses to a single column below 820px so a narrow Obsidian pane stays usable. + +Styling follows the tesanti design system: black / white / red only, Space Grotesk +display, Inter body, JetBrains Mono for eyebrows and data, radii at most 6px, 1px +hairlines instead of shadows, Lucide stroke icons, no emoji. Status colors use the +system's `--ok` / `--warn` / `--danger` tokens and always ship with a text label, never +color alone. Dark mode is derived from the same ink ramp, with the red lifted to +`#ff4a3d` so small text clears contrast on near-black. + +## Ingest mechanism + +```js +const { spawn } = require("child_process"); +spawn("claude", ["-p", `ingest "${file}"`], { cwd: vaultPath, shell: true }); +``` + +`shell: true` is required on Windows to resolve `claude.cmd`, which places the filename +inside a shell string. Before spawning, the filename is rejected if it contains any of: +`"` `` ` `` `$` `&` `|` `;` `<` `>` `%` or a newline. Existing filenames include +Cyrillic, spaces, and `!`, all of which pass. A rejected filename shows an error in its +row and does not spawn. + +Vault path comes from `app.vault.adapter.getBasePath()` on `FileSystemAdapter`. + +Per-row states: `idle` → `running` with elapsed seconds → `done` or `failed · exit <n>` +with captured stderr in an expandable block. On success the pipeline is re-derived and +the row moves to the ingested list. A second click while running is ignored. + +A global **Sync coverage** button spawns `claude -p "sync script coverage"`. + +Preflight: if `claude` is not resolvable on PATH, all buttons render disabled with that +reason stated. + +### Accepted risk + +Headless ingest writes source summaries, concept pages, `index.md`, and `log.md` without +the user watching. This was chosen deliberately over a review checkpoint. Mitigations: +one file per click rather than a batch, captured output retained per row, and visible +per-row status. The writes land before the user reads them; this is understood and +accepted. + +## CLAUDE.md changes + +1. **Folder convention** — add `wiki/script-coverage.md` to the tree with a note that it + is machine-maintained. +2. **Tagging rules** — add the row `wiki/script-coverage.md` → `#coverage`. No existing + page type fits: it is generated tabular data, not prose analysis. +3. **Workflow D: Sync Script Coverage** — re-read the script and every + `wiki/concepts/*.md`; set `Status` and `Station` for each; never modify a row whose + `Pinned` is `yes`; add rows for new concept pages; remove rows for deleted ones; + update `Last synced`; then update `index.md` and append to `log.md`. +4. **Sync triggers** — Workflow D runs at the end of any ingest that creates or modifies + a concept page, whenever `Webinar script.md` changes, and on the explicit + `sync script coverage` intent, which is added to Operational Commands. + +The coverage baseline is always the raw script at `raw/sources/Webinar script.md`. +Ingesting the script into `wiki/sources/` later does not change the baseline. + +## Failure modes + +| Condition | Behavior | +|---|---| +| Coverage file missing or table malformed | Sources pane renders normally; coverage pane shows a parse error with the offending line | +| Concept page exists with no table row | Rendered as `unsynced`, so a stale sync is visible rather than silent | +| Table row points at a nonexistent concept page | Rendered as `stale`, kept in place, not auto-removed | +| Source page whose raw path is missing | Listed under `orphaned` in the left pane | +| `child_process` unavailable (mobile) | Buttons render disabled with the reason | +| `claude` not on PATH | Buttons render disabled with the reason | + +## Initial coverage assessment + +Read manually while designing; the first real sync will regenerate it. 19 concepts: +5 covered, 4 partial, 10 absent. + +- **covered** — harness (Tools), skills-as-memory (Skills), solve-first-then-skillify + (Skills), personal-ai-operating-system (OS), evolution-of-agent-tooling (Tools) +- **partial** — agentic-loops (Process), context-as-scarce-resource (Memory), + levels-of-ai-usage (all), code-as-throwaway (OS) +- **absent** — connections-as-moat, product-ownership, seniority-and-the-junior-squeeze, + decoupling-identity-from-profession, network-from-a-standing-start, + think-wider-not-bigger, make-more-cheap-code, enterprise-ai-reality, + integration-dead-ends, leave-less-room-for-imagination + +Every absent concept is human-side or strategy-side. The `ReAct` station carries no wiki +concept at all. + +## Out of scope for v1 + +- Pin toggle button (hand-edit instead). +- Alternate station-board view toggle. The data file is layout-independent, so this is a + render change if wanted later. +- Coverage for entities, sources, or queries — concepts only. +- Any view of `raw/notes/`. + +## Note on spec location + +This file introduces a `docs/` folder at the vault root, which is not part of the +`CLAUDE.md` folder convention and will appear in Obsidian's file explorer. It can be +moved or deleted without affecting the implementation. + +The vault is not a git repository, so this spec is not committed. diff --git a/index.md b/index.md new file mode 100644 index 0000000..4efddbb --- /dev/null +++ b/index.md @@ -0,0 +1,85 @@ +# Wiki Index + +Content catalog for this vault. Updated after every ingest / query / lint operation that changes the wiki. + +See [[overview]] for the top-level synthesis and navigation. + +Every wiki page carries a page-type tag under its H1 (`#source`, `#entity`, `#concept`, `#timeline`, `#comparison`, `#query`, `#lint-report`, `#overview`) — see "Tagging Rules" in `CLAUDE.md`. + +## Sources + +- [[2026-07-14-everything-we-knew-about-software-has-changed]] — Theo Browne (AIE): model eras, think wider, code as throwaway _(raw: Everything we knew about software has changed.md)_ +- [[2026-07-14-gap-between-ai-users-irreversible]] — Allie Miller: personal AI OS, foundation docs, skills, proactive workflows _(raw: In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible.md)_ +- [[2026-07-14-sebastian-eugene-interview]] — Sebastian + Eugene: harness, team collapse, connections, enterprise reality _(raw: sebastian interview - conclusions and insights.md)_ +- [[2026-07-14-skills-based-on-git]] — Konstantin (Sber): git skills as agent memory, harness, agent loops _(raw: Скиллы на базе git — новая память AI-агентов.md)_ +- [[2026-07-14-nina-interview]] — Eugene + Nina (HR): transcript > summary, friction not resistance, skills as handoff _(raw: Nina interview.md)_ +- [[2026-07-14-yulia-interview]] — Eugene + Yulia (HR lead): levels of AI usage, candidate knowledge base, solve-first _(raw: Yulia interview.md)_ +- [[2026-07-21-larysa-interview]] — Eugene + Larysa (BA/PM): memory loss, integration dead-ends, less room for imagination _(raw: Larysa interview.md)_ +- [[2026-07-22-ai-is-stupid]] — YouTube short (author unknown): "stupid AI" = model minus context minus harness; Nobel-vs-employee analogy _(raw: ИИ глупый!.md)_ +- [[2026-07-24-youre-reading-way-too-much-code]] — Theo Browne (video): make more cheap code, four tiers of code, 100:1 slop-to-ship verification _(raw: You're reading way too much code.md)_ + +**Raw, not yet ingested:** `raw/sources/Ideas for webinar.md` · `raw/sources/Webinar Plan - From Chat Box to Your Own OS.md` · `raw/sources/Webinar script.md` · `raw/sources/my theses.md` + +## Entities + +### People +- [[theo-browne]] — developer/educator (t3.gg); "think wider", "make more cheap code" +- [[allie-miller]] — ex-Amazon AI leader; personal AI OS +- [[sebastian]] — founder of Virtido; enterprise/connections lens +- [[eugene]] — developer, harness-builder, webinar author; interviewer (likely vault owner, tentative) +- [[konstantin]] — Sber/GigaChat R&D; skills-as-memory +- [[nina]] — HR recruiter at Virtido; webinar-audience proxy, use-case supplier +- [[yulia]] — HR/recruiting lead; webinar organizer (name/affiliation tentative) +- [[larysa]] — technical BA/PM, ex-mobile dev; advanced user blocked by memory + integrations + +### Tools / Orgs +- [[claude-code]] — reference harness (all sources) +- [[hermes]] — skills-first, self-curating harness +- [[virtido]] — Sebastian's outsourcing company; its HR team is the webinar audience +- [[inspectron]] — Eugene's employer (Edge Compute / IoT) + +## Concepts + +**Machine side** +- [[harness]] — universal agent = LLM + small toolset + loop +- [[skills-as-memory]] — git skills (SKILL.md + tools + data) as agent memory +- [[evolution-of-agent-tooling]] — tools → MCP → skills +- [[agentic-loops]] — inner (ReAct) / outer (Ralph) / meta +- [[context-as-scarce-resource]] — the binding constraint; the "smart zone" +- [[personal-ai-operating-system]] — Allie's context docs + skills + proactive workflows +- [[levels-of-ai-usage]] — Eugene's ladder: chatbot → … → CLAUDE.md + skills (the non-programmer ceiling) +- [[solve-first-then-skillify]] — solve the task once, then freeze it into a skill +- [[integration-dead-ends]] — agent starts work against connectors the user's account doesn't have +- [[leave-less-room-for-imagination]] — every gap in a spec gets filled, invisibly; tighten it + +**Human side** +- [[product-ownership]] — own outcomes, frame problems not tickets +- [[connections-as-moat]] — in-person relationships as the last non-commoditized asset +- [[network-from-a-standing-start]] — tentative from-zero networking protocol (v0, to be validated) +- [[seniority-and-the-junior-squeeze]] — judgment as risk-reduction +- [[decoupling-identity-from-profession]] — separate who you are from what you do + +**Strategy side** +- [[think-wider-not-bigger]] — breadth over depth; match ambition to the model +- [[code-as-throwaway]] — cost of code → zero +- [[make-more-cheap-code]] — Theo: four tiers of code; generate never-shipped slop to verify/explore; there's always another layer +- [[enterprise-ai-reality]] — compliance lock-down; the company-managed-harness market + +## Timelines + +- [[ai-agent-evolution]] — agent/tooling timeline + Theo's model eras + +## Comparisons + +- [[theo-konstantin-allie]] — Theo vs Konstantin vs Allie: three lenses (strategy / engineering / personal-OS) on the same shift; shared markdown-as-unit and system-over-model, differing altitude + +## Queries + +- [[2026-07-14-best-first-skill-for-beginner]] — best first skill for a Claude beginner: skill-creator (meta) + tone-of-voice/anti-AI-language; foundation docs first +- [[2026-07-14-network-from-standing-start]] — network-from-zero: tentative protocol + Sebastian round-2 interview instrument (10 questions) +- [[2026-07-22-webinar-theses]] — 14 candidate theses for the webinar, grouped spine / stakes / obstacles / method / tensions +- [[2026-07-24-non-engineer-throwaway-verification]] — non-engineer analog of throwaway verification code: generated checks not content; checker skills; drift as diagnostic + +## Lint Reports + +_None yet._ diff --git a/log.md b/log.md new file mode 100644 index 0000000..a9be385 --- /dev/null +++ b/log.md @@ -0,0 +1,149 @@ +# Operation Log + +Append-only chronological record of wiki operations. Newest entries at the bottom. + +Entry format: + +``` +## YYYY-MM-DD — <operation> +- Intent: ingest | query | lint | maintenance +- Input: <source path / question / scope> +- Pages changed: [[...]], [[...]] +- Notes: <what changed, uncertainty, next steps> +``` + +--- + +## 2026-07-14 — maintenance +- Intent: maintenance +- Input: Initialize vault folder structure. +- Pages changed: created `index.md`, `log.md`, `wiki/overview.md`; created `raw/{sources,assets}` and `wiki/{sources,entities,concepts,timelines,comparisons,queries,lint-reports}`. +- Notes: Empty vault scaffolded per the LLM Wiki Schema in `CLAUDE.md`. No sources ingested yet. Ready for first "ingest <source>". + +## 2026-07-14 — ingest (batch, 4 sources) +- Intent: ingest +- Input: The 4 talk/interview docs (user-selected scope; "Ideas for webinar" + "HR Contacts" left as raw reference). + - `raw/sources/Everything we knew about software has changed.md` + - `raw/sources/In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible.md` + - `raw/sources/sebastian interview - conclusions and insights.md` + - `raw/sources/Скиллы на базе git — новая память AI-агентов.md` +- Pages created — sources (4): [[2026-07-14-everything-we-knew-about-software-has-changed]], [[2026-07-14-gap-between-ai-users-irreversible]], [[2026-07-14-sebastian-eugene-interview]], [[2026-07-14-skills-based-on-git]]. +- Pages created — entities (8): [[theo-browne]], [[allie-miller]], [[sebastian]], [[eugene]], [[konstantin]], [[claude-code]], [[hermes]], [[virtido]]. +- Pages created — concepts (13): [[harness]], [[skills-as-memory]], [[evolution-of-agent-tooling]], [[agentic-loops]], [[context-as-scarce-resource]], [[personal-ai-operating-system]], [[product-ownership]], [[connections-as-moat]], [[seniority-and-the-junior-squeeze]], [[decoupling-identity-from-profession]], [[think-wider-not-bigger]], [[code-as-throwaway]], [[enterprise-ai-reality]]. +- Pages created — timelines (1): [[ai-agent-evolution]]. +- Pages updated: [[overview]] (added the cross-source through-line + agree/diverge), `index.md` (full catalog). +- Notes: Strong cross-source convergence (skills-as-memory: Konstantin ↔ Allie; connections: Sebastian ↔ Allie; code-as-throwaway: Theo ↔ Sebastian). Recorded contradictions (Eugene vs Sebastian on BYO- vs company-managed harness, online vs in-person networking, OSS motivation). Tentative claims flagged: Theo's model-era names, Eugene = vault owner, Hermes/Ralph heuristics, Allie's self-learning-models prediction. +- Next: consider ingesting "Ideas for webinar" (connects corpus → webinar plan) and "HR Contacts" (the HR-search demo); consider a `wiki/comparisons/` page for the BYO-vs-managed-harness debate; run "lint wiki" to check link health. + +## 2026-07-14 — maintenance (tagging convention) +- Intent: maintenance +- Input: user request — add per-type hashtags to the wiki schema and existing pages. +- Pages changed: `CLAUDE.md` (new "Tagging Rules" section, rule 9, templates + lint checklist updated); all 26 wiki pages received a page-type tag line under their H1 — [[overview]] `#overview`, 4 source pages `#source`, 8 entity pages `#entity`, 13 concept pages `#concept`, [[ai-agent-evolution]] `#timeline`; `index.md` (noted the convention). +- Notes: Tag mapping is folder-driven (`#source`, `#entity`, `#concept`, `#timeline`, `#comparison`, `#query`, `#lint-report`, `#overview`). Exactly one type tag per page, first on the tag line; topical tags may follow. Lint now checks for missing/mismatched type tags. + +## 2026-07-14 -- query +- Intent: query +- Input: "what would be the best claude skill to give to a claude beginner user?" +- Pages changed: created [[2026-07-14-best-first-skill-for-beginner]]; updated [[skills-as-memory]] (Next Questions item answered + linked), `index.md` (Queries section). +- Notes: Answer synthesized from Allie Miller (skill-creator, tone-of-voice/anti-AI-language starter set, foundation-docs-first) and Konstantin (>5-tool-calls auto-creation heuristic). Follow-up: contents of a good tone-of-voice SKILL.md; foundation-doc templates. + +## 2026-07-14 — maintenance (authorized raw edit) +- Intent: maintenance +- Input: user explicitly authorized editing `raw/sources/Webinar script.md` this session (exception to rule 1). +- Pages changed: `raw/sources/Webinar script.md` — completed the dangling Tools→Memory bridge line, wrote the full **# Memory** section (amnesia demo → notebook tool → close/reopen payoff → system-prompt reveal → user.md beat → tiny-notebook limitation as the Skills hook), and renamed "Markus" → "Marcus" to match the demo app's seeded mail (`Marcus Hale`). +- Notes: Memory section is grounded in the actual mini-game behavior (Level 04 in `D:\Projects\Names\Webinars\From_chat_to_os`): frozen snapshot per session (hence the mandatory close/reopen), `memory.md` + `user.md` on disk, ~2200-char budget motivating Skills. No wiki pages changed. Next: draft **# Skills** section (open with on-demand loading answering the phone-book limitation). + +## 2026-07-14 — maintenance (authorized raw edit, Skills section) +- Intent: maintenance +- Input: user request — draft the **# Skills** section in `raw/sources/Webinar script.md` (edit permission granted this session). Corrected flow per user: presenter dictates the operations step by step first, *then* asks AI to package the procedure as a skill. +- Pages changed: `raw/sources/Webinar script.md` — full Skills section (step-by-step dictation → "I was the recipe" → save-as-skill → SKILL.md on disk → fresh-session one-liner → progressive-disclosure reveal → portability beat → "I'm still the alarm clock" hook into Process). +- Notes: Grounded in the app's Skills level (Level 05): `save_skill`/`load_skill`, real `skills/<name>/SKILL.md`, live menu (names+descriptions only) rebuilt per window. No wiki pages changed. Next: draft **# Process** (Level 06 — spawn_process scheduler answers the alarm-clock limitation). + +## 2026-07-14 — maintenance (authorized raw edit, Process section) +- Intent: maintenance +- Input: user request — draft the **# Process** section in `raw/sources/Webinar script.md` (session edit permission). +- Pages changed: `raw/sources/Webinar script.md` — full Process section (goal not task → spawn_process with pid → hands-off heartbeats → Override slider makes the cube move by itself → ps/kill → reveal: the shell authored the worker's prompt (AI managing AI) → closing arc: same model all six levels, only the harness grew; harness is unique to you; "from a chat box to your own Agentic Operating System"). Also two-branch rule fixes earlier this session (Memory convention + Skills dictation). +- Notes: Grounded in Level 06 design (`2026-07-11-process-level-design.md`): single ~5s scheduler, stateless ticks, spawn/list/stop syscalls, live −5…+5 weather offset. The "same model, growing harness" close absorbs the `_ideas:` note at the top of the script. Script now has all sections drafted (Intro → Process). + +## 2026-07-14 — maintenance (authorized raw edit, OS section) +- Intent: maintenance +- Input: user request — add an **# OS** section to `raw/sources/Webinar script.md` (session edit permission): typing removed, mouse-only interaction with the agent. +- Pages changed: `raw/sources/Webinar script.md` — Process now ends with a "still a terminal / most people never will type" hook; new OS section (one-button app → rule baked in → 5-second checkbox → appliance → "the agent became a program / the chat box dissolved into the OS"); the "same model, growing harness" closing arc moved from Process into OS, with the new final callback "a button that already knows what the email said." +- Notes: Grounded in the OS app design (`2026-07-12-os-app-design.md`): tile 07, status bar mirrors the agent's closing sentence, shared scheduler slot, Override interplay, rule baked into the prompt. Script ladder now: Chat box → ReAct → Tools → Memory → Skills → Process → OS. + +## 2026-07-14 — maintenance (authorized raw edit, OS reframing) +- Intent: maintenance +- Input: user correction — the webinar's core idea is "make tools for yourself," not "become a product." +- Pages changed: `raw/sources/Webinar script.md` — Process→OS hook now ends "…and become a tool? A small one. Made for exactly one person."; OS landing gained the intro callback (weekends burned on internal tools → this one took an evening, asked-for not written) and "It dissolved — into the operating system. Into little tools you make for yourself."; closing arc adds "You don't buy it. You build it — one small tool at a time." +- Notes: The OS section now closes the loop with the Intro's internal-tools passion. No wiki pages changed. + +## 2026-07-14 — ingest (batch, 2 sources: Nina + Yulia interviews) +- Intent: ingest +- Input: `raw/sources/Nina interview.md`, `raw/sources/Yulia interview.md` (both are conclusions docs auto-generated by Eugene's record→diarize→transcribe→summarize tool). +- Pages created — sources (2): [[2026-07-14-nina-interview]], [[2026-07-14-yulia-interview]]. +- Pages created — entities (3): [[nina]] (HR recruiter, Virtido), [[yulia]] (HR lead; name/affiliation tentative, inferred from filename + Nina reference), [[inspectron]] (Eugene's employer). +- Pages created — concepts (2): [[levels-of-ai-usage]] (chatbot → memory → Claude Code → CLAUDE.md → skills → KB → RAG; non-programmer ceiling = CLAUDE.md + skills), [[solve-first-then-skillify]] (solve once, then freeze into a skill; ~3-message and >5-tool-call heuristics). +- Pages updated: [[eugene]] (identity evidence strengthened — webinar author/presenter, Inspectron, $200 max plan, tool builder; still tentative), [[virtido]] (HR team = webinar audience, pain points, tooling), [[skills-as-memory]] (handoff/de-risking payoff, ~3-message heuristic, method link), [[connections-as-moat]] (Eugene independently converges: "the human's role is just to be human"), [[overview]] (6 sources, demand-side bullet, agree/diverge, navigation, open questions), `index.md`. +- Notes: Strong convergence — Eugene ↔ Sebastian/Allie on human-connection residual despite their networking-tactics disagreement; Eugene's ~3-message heuristic ↔ Konstantin's >5-tool-call heuristic. New cross-interview finding: adoption blocked by friction, not resistance. Tentative flags: Yulia's name/affiliation; Eugene's price-rise prediction; Inspectron employment-vs-contracting. Skills-IP-vs-work-product dispute (Eugene vs Sebastian) recorded, unresolved. +- Next: ingest "Ideas for webinar" / "Webinar Plan" / "Webinar script" to connect corpus → deliverable; interview Larysa/Larisa (PM use cases, twice flagged); consider a comparison page "personal vs employer ownership of skills". + +## 2026-07-14 — query (network from a standing start) +- Intent: query +- Input: "how does an individual actually build a network from a standing start?" + "go" on the recommended plan (tentative protocol + Sebastian follow-up instrument). +- Pages created: [[network-from-a-standing-start]] (concept, Status: tentative — 5-step protocol: recurring venues → cadence → lead with humanness → engineer second meetings → track second meetings/let referrals work; contested anti-tactics list; webinar flagged as live case study), [[2026-07-14-network-from-standing-start]] (query — 10-question Sebastian round-2 interview instrument in 3 blocks: bootstrap biography / mechanics / falsification of "Big zero"). +- Pages updated: [[connections-as-moat]] (open question → protocol + validation plan), [[overview]] (vault-level open question annotated), `index.md` (Concepts + Queries sections). +- Notes: Corpus cannot answer the question directly — protocol is inferred from Sebastian's principles, Allie's prediction, and Eugene's convergent thesis; every claim marked tentative/contested. Key falsification target: whether Sebastian ever had a true standing start (prior-job network as seed). Deep-research complement (weak ties, mere exposure, from-zero playbooks, scoped to test "Big zero") described but not run. +- Next: run the round-2 Sebastian interview and ingest it; decide on the deep-research run; track webinar → paid-HR-build chain as case-study evidence. + +## 2026-07-16 — query → comparison +- Intent: query +- Input: "Compare Theo's, Konstantin's ('Sonstantine') and Allie's approaches — what they have in common, what they have different?" +- Pages created: [[theo-konstantin-allie]] (first `wiki/comparisons/` page — three-lens side-by-side: at-a-glance table, 6 shared points, differences by altitude/framing/code/learning/register, complementary tensions). +- Pages updated: [[theo-browne]], [[konstantin]], [[allie-miller]] (added inbound "Comparison:" links to avoid orphan); `index.md` (Comparisons section — first entry). +- Notes: Synthesized from the 3 source summaries + entity pages + [[skills-as-memory]]. Common ground: bottleneck moved model→human system; markdown/skills as the atomic unit; infrastructure compounds; system-ready to absorb new models; context as scarce resource; shared [[claude-code]]. Differences framed as *altitude* (Theo strategy/psychology · Konstantin engineering · Allie individual-productivity), not direction — corpus disagreements lie elsewhere. Recorded the throwaway-code (Theo) vs persist-in-git (Konstantin) tension as complementary (artifact vs capability). No new contradictions. Saved as a comparison rather than a query page since the request was explicitly a side-by-side. +- Next: reusable starter template (foundation docs / good SKILL.md) still unresolved across all three — webinar-relevant; consider whether Konstantin's meta-loop (wipe-and-restart) tensions with "persist everything". + +## 2026-07-16 — maintenance (table fix) +- Intent: maintenance +- Input: user report — the table in [[ai-agent-evolution]] "looks broken". +- Pages changed: [[ai-agent-evolution]] — repaired the "Agent architecture & tooling (Konstantin)" table; escaped the `|` inside aliased wiki links (`[[harness\|harnesses]]`, `[[skills-as-memory\|skills]]`, `[[agentic-loops\|agent loops]]`) so Obsidian no longer reads them as column separators, and removed the two phantom trailing columns the unescaped pipes had forced into the header/separator. Now a clean 3-column table (Period / Milestone / Significance). +- Notes: Content unchanged — formatting-only fix. The Theo Browne table was already valid. No `index.md` change (no catalog/structural change). Root cause: piped `[[page|alias]]` links inside GFM/Obsidian table cells require the pipe escaped as `\|`. + +## 2026-07-21 — ingest (Larysa interview) +- Intent: ingest +- Input: "ingest Larysa interview.md" → `raw/sources/Larysa interview.md` (auto-generated interview conclusions doc; Eugene × Larysa, technical BA/PM and ex-mobile dev). +- Pages created: [[2026-07-21-larysa-interview]] (source), [[larysa]] (entity), [[integration-dead-ends]] (concept — agent begins work against connectors gated by account tier / paid seat / missing API; corpus offers no fix, only up-front verification), [[leave-less-room-for-imagination]] (concept — under-specified prompts drift and the collateral damage is *invisible*; skills as the constraint; includes the 4.7-over-4.8 model-choice corollary). +- Pages updated: [[skills-as-memory]] (new "negative case" section — built-in memory as anti-feature, the demand-side reason skills exist; contradiction logged vs Allie), [[harness]] (consolidation-over-tool-hopping section + "before and after" claim marked self-reported), [[code-as-throwaway]] (auth/payments trust carve-out; "safe from 4.6 on"), [[levels-of-ai-usage]] (Larysa as proof the rungs are skippable — technically advanced, architecturally stuck), [[claude-code]] (practitioner-limits section: memory, connectors, 4.6/4.7/4.8, emulator), [[solve-first-then-skillify]], [[personal-ai-operating-system]] (cross-ref to Eugene's convergent OS framing), [[eugene]], [[yulia]] (Larisa open question partially resolved), [[virtido]] (audience extends beyond HR; ClickUp/Figma/Teams/Slack), [[overview]] (6→7 sources, demand-side paragraph, two new divergences, two new vault-level open questions), `index.md`. +- Notes: Closes the "Larysa/Larisa not yet interviewed — PM use cases missing" gap flagged in both HR interviews. Key reframe for the webinar: this source moves the diagnosis from *friction* (Nina/Yulia: people would adopt if it were simple) to *structural walls* for users already past friction — memory, entitlements, drift. Two genuine corpus contradictions recorded rather than smoothed: memory-as-anti-feature (Eugene) vs Allie's untroubled use of persistent context docs, and tight-spec vs [[think-wider-not-bigger]]. Also corrected `index.md`: `HR Contacts.md` was listed as not-yet-ingested but does not exist in `raw/sources/` — removed from the list. +- Next: remaining un-ingested raw are the three webinar-deliverable docs (`Ideas for webinar.md`, `Webinar Plan - From Chat Box to Your Own OS.md`, `Webinar script.md`) — ingesting them would connect the corpus to the actual deliverable and settle whether the script keeps the [[levels-of-ai-usage]] rung order. Candidate query: does the skills rung actually answer Larysa's memory complaint, or is hers a cross-project problem skills don't solve? A first lint pass is also overdue (no lint reports exist; 7 sources, 17 concepts). + +## 2026-07-22 — query (webinar theses) +- Intent: query +- Input: "What theses can I suggest for the webinar ('from chatbox to your own agentic operating system') based on what you already have?" +- Pages changed: created [[2026-07-22-webinar-theses]]; updated `index.md` (Queries section). +- Notes: 14 candidate theses synthesized from [[overview]], the 7 source summaries, and direct reads of the three raw webinar-deliverable docs (Plan, script, Ideas — still raw-only, cited as raw per policy). Grouped: spine (harness-not-model, app-you-open→OS, skills-as-memory, context scarcity, build-not-buy) / stakes (cost→zero, irreversible gap, connections rise) / obstacles (friction-not-resistance, structural walls, less-room-for-imagination) / method (solve-first-then-skillify, research-vs-judgment, walk-in-a-week) / honest tensions (3 recorded contradictions offered as Q&A ammo). Recommended 7-thesis subset for the 30-min format noted in the query page. No concept/entity pages changed. +- Next: ingest the three deliverable docs so theses can cite wiki sources instead of raw; decide whether the "obstacles" theses earn a station on the spine. + +## 2026-07-22 — ingest (ИИ глупый! short) +- Intent: ingest +- Input: "ingest \"ИИ глупый!\"" → `raw/sources/ИИ глупый!.md` (conclusions doc for a 1:28 Russian YouTube Short, author unknown; file was added mid-session after the first lookup found nothing). +- Pages created: [[2026-07-22-ai-is-stupid]] (source). +- Pages updated: [[harness]] (business-facing "engineering wrapper" definition + model+context+harness formula, flagged as webinar language), [[context-as-scarce-resource]] (supply-side facet: "intelligence without context loses to context without intelligence", Nobel-vs-employee analogy; RAG-vs-skills tension logged under Contradictions), [[overview]] (7→8 sources, convergence one-liner, navigation), `index.md` (Sources entry; `my theses.md` added to the not-yet-ingested list). +- Notes: No new concepts — the short *restates* the vault's machine-side spine for a business audience, which makes it webinar-quotable rather than novel. One tension recorded, not smoothed: it recommends RAG/long-term memory as context mechanisms where Konstantin argues skills beat RAG (possibly audience-driven — business data vs procedures). Authorship unknown and marked tentative; its framing matches the corpus closely enough that a connection to someone already in the corpus is worth checking. All ×10…×1000 gain claims are rhetorical, not measured. +- Next: `my theses.md` is new in raw and un-ingested (six webinar thesis one-liners) — small, high-relevance ingest candidate; the three webinar-deliverable docs remain pending; first lint pass still overdue (8 sources, 17 concepts, 0 lint reports). + +## 2026-07-24 — ingest (You're reading way too much code) +- Intent: ingest +- Input: "ingest \"You're reading way too much code\"" → `raw/sources/You're reading way too much code.md` (conclusions doc for Theo Browne's 24:11 video; his second source in the vault). +- Pages created: [[2026-07-24-youre-reading-way-too-much-code]] (source), [[make-more-cheap-code]] (concept — ship/no-ship line, four tiers of code A–D, 100–10,000:1 slop-to-ship verification ratio, always-another-layer, dumb-model agents as API usability testers, reading-costs-attention economics). +- Pages updated: [[code-as-throwaway]] (discipline section; evidence; its "what is the durable artifact" open question partially answered — the verification harness is now a named first-class output), [[theo-browne]] (second talk, recurring author-move noted, self-reported ratios flagged tentative), [[leave-less-room-for-imagination]] (new logged tension: Theo/Dax agent-diff-summaries vs Eugene's invisible-drift claim), [[2026-07-14-everything-we-knew-about-software-has-changed]] (reciprocal related-source link), [[overview]] (8→9 sources; verifying-half of spine given its method; new divergence line; 17→18 concepts), `index.md` (Sources, People, Concepts entries). +- Notes: The source is a *defense with discipline*, not a reversal — Theo explicitly rejects shipping unreviewed slop, which pre-empts the obvious objection to [[code-as-throwaway]]. Strong webinar relevance: "attention, not generation, is the bottleneck" is the engineer-side twin of [[context-as-scarce-resource]], and the tier framework gives audiences a non-binary answer to "can I trust AI code?". One genuine tension recorded rather than smoothed (summaries-hide-drift). Shao's 80%-into-harnesses ratio and all of Theo's daily-line counts are self-reported/uncited — marked tentative. Open framework gap flagged: skills/CLAUDE.md files don't fit the A–D spectrum. +- Next: candidate query — what is the non-engineer's analog of throwaway verification code (HR/BA audience)? `my theses.md` and the three webinar-deliverable docs remain un-ingested; first lint pass still overdue (9 sources, 18 concepts, 0 lint reports). + +## 2026-07-24 — query (non-engineer throwaway verification) +- Intent: query +- Input: "query: what is the non-engineer's analog of throwaway verification code?" (the candidate query flagged in the previous ingest). +- Pages created: [[2026-07-24-non-engineer-throwaway-verification]] (query — answer: disposable AI work that attacks/misreads/simulates the deliverable before a human sees it; one-to-one mapping table from Theo's engineer patterns to HR/BA use cases; "checker skills" as the second species of skill; tier-D-stays-human caveat since non-engineer verification bottoms out in judgment, not tests). +- Pages updated: [[make-more-cheap-code]] (next-question marked answered, link added), [[leave-less-room-for-imagination]] (new next-question: drift harnessed as a sandboxed ambiguity diagnostic — synthesis, tentative), `index.md` (Queries section). +- Notes: Pure synthesis, no new source — every mapped pattern is grounded in corpus use cases (Nina/Yulia job descriptions, candidate KB, sourcing; Larysa spec ambiguity; Allie's anti-AI-language checker-skill precedent). Key reframes with durable value: (1) the fresh-agent misread test inverts [[leave-less-room-for-imagination]] — drift becomes a diagnostic when sandboxed; (2) [[solve-first-then-skillify]] populates skills in two species, producers and checkers. Flagged honestly: the whole mapping is argument-by-analogy with no measured claim; Nina's transcript-beats-summary finding is a standing counterweight to summary-based review. +- Next: decide whether "checker skills" earns a slide on the webinar's skills rung; the webinar-deliverable docs (`Ideas`, `Plan`, `script`, `my theses.md`) remain un-ingested; first lint pass still overdue (9 sources, 18 concepts, 2026-07-24 now has 1 query, 0 lint reports). diff --git a/mockups/README.md b/mockups/README.md new file mode 100644 index 0000000..e69de29 diff --git a/raw/assets/.gitkeep b/raw/assets/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/raw/assets/Dan Martell - Scale Your Business Workbook.pdf b/raw/assets/Dan Martell - Scale Your Business Workbook.pdf new file mode 100644 index 0000000..0eadf2f Binary files /dev/null and b/raw/assets/Dan Martell - Scale Your Business Workbook.pdf differ diff --git a/raw/notes/Ideas for webinar.md b/raw/notes/Ideas for webinar.md new file mode 100644 index 0000000..9ae8e54 --- /dev/null +++ b/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 - возможно, стоит чекнуть \ No newline at end of file diff --git a/raw/notes/introduction.md b/raw/notes/introduction.md new file mode 100644 index 0000000..75294d8 --- /dev/null +++ b/raw/notes/introduction.md @@ -0,0 +1,12 @@ +Каждый из нас делает ручной, рутинный труд и даже не осознаёт это. + +Мы считаем это нормой и делать по-другому нам кажется неоправданно трудозатратно, менее эффективно или даже глупо. + +Это в природе человека и существует с нами всю историю. Люди выбирают то, что привычнее: + +**Чемодан на колёсиках.** Колесо — тысячи лет, чемодан — век, а соединили их только в 1970-м (Бернард Садоу), а удобный вариант с выдвижной ручкой — в 1987-м (Роберт Плат, пилот). До этого миллионы людей просто носили тяжести в руках и считали это нормой. + + + +IPhone... Apple - это один из якрих представителей, которые использовали "привычнось" в дизайне. Скевоморфизм. Этот стиль использует изображение знакомых предметов для обозначения функции: компас, книга, трубка телефона. +А такие вещи как кнопка и дискета в качестве символа сохранения уже на столько привычны, что нам тяжело предстравить как может быть по-другому. \ No newline at end of file diff --git a/raw/notes/my theses.md b/raw/notes/my theses.md new file mode 100644 index 0000000..f479cab --- /dev/null +++ b/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. \ No newline at end of file diff --git a/raw/sources/.gitkeep b/raw/sources/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/raw/sources/Agentic Engineering, explained by a 10x developer.md b/raw/sources/Agentic Engineering, explained by a 10x developer.md new file mode 100644 index 0000000..983490e --- /dev/null +++ b/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 diff --git a/raw/sources/Everything we knew about software has changed.md b/raw/sources/Everything we knew about software has changed.md new file mode 100644 index 0000000..6572b2e --- /dev/null +++ b/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. diff --git a/raw/sources/In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible.md b/raw/sources/In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible.md new file mode 100644 index 0000000..14e383f --- /dev/null +++ b/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. diff --git a/raw/sources/Larysa interview.md b/raw/sources/Larysa interview.md new file mode 100644 index 0000000..8fdf415 --- /dev/null +++ b/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. diff --git a/raw/sources/Nina interview.md b/raw/sources/Nina interview.md new file mode 100644 index 0000000..a8d35e4 --- /dev/null +++ b/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. diff --git a/raw/sources/Webinar Plan - From Chat Box to Your Own OS.md b/raw/sources/Webinar Plan - From Chat Box to Your Own OS.md new file mode 100644 index 0000000..d0000c9 --- /dev/null +++ b/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* diff --git a/raw/sources/Webinar script.md b/raw/sources/Webinar script.md new file mode 100644 index 0000000..e8d6824 --- /dev/null +++ b/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. \ No newline at end of file diff --git a/raw/sources/You're reading way too much code.md b/raw/sources/You're reading way too much code.md new file mode 100644 index 0000000..f2e39b7 --- /dev/null +++ b/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) diff --git a/raw/sources/Yulia interview.md b/raw/sources/Yulia interview.md new file mode 100644 index 0000000..7f9fb40 --- /dev/null +++ b/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. diff --git a/raw/sources/sebastian interview - conclusions and insights.md b/raw/sources/sebastian interview - conclusions and insights.md new file mode 100644 index 0000000..d57bc52 --- /dev/null +++ b/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.) diff --git a/raw/sources/ИИ глупый!.md b/raw/sources/ИИ глупый!.md new file mode 100644 index 0000000..7c71c13 --- /dev/null +++ b/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 во внутренние процессы и разочарованы «общими» ответами; инженерам, строящим корпоративных ассистентов; всем, кто выбирает между «взять модель побольше» и «дать модели правильные данные и правила». diff --git a/raw/sources/Скиллы на базе git — новая память AI-агентов.md b/raw/sources/Скиллы на базе git — новая память AI-агентов.md new file mode 100644 index 0000000..bd8662e --- /dev/null +++ b/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 победителей уже строят решения на харнессах. Догоняйте. diff --git a/tesanti Design System.zip b/tesanti Design System.zip new file mode 100644 index 0000000..2e647da Binary files /dev/null and b/tesanti Design System.zip differ diff --git a/wiki/comparisons/.gitkeep b/wiki/comparisons/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/wiki/comparisons/theo-konstantin-allie.md b/wiki/comparisons/theo-konstantin-allie.md new file mode 100644 index 0000000..5bc430d --- /dev/null +++ b/wiki/comparisons/theo-konstantin-allie.md @@ -0,0 +1,86 @@ +# Theo Browne vs Konstantin vs Allie Miller — Three Lenses on the Same Shift + +#comparison + +## Summary + +Three speakers describe the **same underlying change** — models now improve faster than people can, and the durable advantage has moved from the model to the *system you wrap around it* — but from three non-overlapping vantage points: + +- [[theo-browne]] — **strategy / psychology** (what to build, how big to think) +- [[konstantin]] — **engineering / R&D** (how the machinery works) +- [[allie-miller]] — **individual productivity / business** (how a person operationalizes it daily) + +They agree on the destination and disagree mostly on *altitude*, not direction. + +## At a glance + +| | [[theo-browne]] | [[konstantin]] | [[allie-miller]] | +|---|---|---|---| +| **Source** | [[2026-07-14-everything-we-knew-about-software-has-changed]] | [[2026-07-14-skills-based-on-git]] | [[2026-07-14-gap-between-ai-users-irreversible]] | +| **Lens** | Founder / educator | Model-builder (Sber/GigaChat) | Ex-Amazon AI leader / advisor | +| **Audience** | Engineers & founders | Agent developers | Knowledge workers, non-programmers | +| **Core unit** | Ambition / scope | The [[harness]] + git repo + [[agentic-loops\|loops]] | The [[personal-ai-operating-system]] | +| **One-line thesis** | [[think-wider-not-bigger\|Think wider]] — scope to the new model | Skills+data in git = agent memory | Build the OS once; models slot in | +| **Faces toward** | The market (what to build) | The machine (architecture) | The individual (adoption + judgment) | +| **On code** | [[code-as-throwaway\|Throwaway]], cost → 0 | Commoditized; orchestration is what matters | Barely about code at all | +| **Time posture** | Present shock ("already changed") | Roadmap (tools→MCP→skills→loops; 2027) | Urgency ("irreversible in 12 months") | + +## What they have in common + +1. **The bottleneck moved from the model to the human's system.** Theo frames "models aren't useful for me" as a *scoping* problem on the human side; Konstantin's human evolves prompt-engineer → context-engineer → harness/loop-builder; Allie says winners and losers differ in **mindset and taste**, not expertise. None of them treats raw model capability as the constraint. + +2. **Markdown / skills as the atomic unit.** All three independently converge on plain markdown as the durable building block — Theo's "**G-brain tier**" (a markdown file as an executable service on a cron), Konstantin's `SKILL.md`**+ data in git**, Allie's skills as "**just folders with markdown.**" This is the vault's strongest cross-source thread — see [[skills-as-memory]]. + +3. **Infrastructure compounds; one-off prompting doesn't.** Allie: build foundation docs once and every release "slots into a system you already understand." Konstantin: the git repo + auto-improvement compound over time. Theo: build for **breadth/shape** so others extend you (the Slack effect). Same instinct — invest in a reusable substrate, not individual prompts. + +4. **You only capture a new model's gains if the system is ready to absorb it.** Theo: "push scope to match it." Konstantin: keep the harness constant and swap the LLM underneath. Allie: the new model "slots in." Identical mechanic, three vocabularies. + +5. **[[context-as-scarce-resource\|Context is the real scarce resource]].** Explicit in Konstantin ("smart zone," two-stage skill loading) and Allie ("context engineering, not prompt engineering"); implicit in Theo's orchestration era. + +6. **[[claude-code]] is the shared reference harness** across all three. + +## Where they differ + +**Altitude / question answered** +- **Theo → "what should I build, and how big?"** Strategy and psychology. His deliverable is a *mindset*: shed developer-identity baggage ([[decoupling-identity-from-profession]]), treat code as disposable, pick embarrassingly ambitious ideas. +- **Konstantin → "how does the machinery actually work?"** The deepest technical account: harness definition, `tools → MCP → skills` ([[evolution-of-agent-tooling]]), two-stage loading, CI as back-pressure, pruning windows, inner/outer/meta [[agentic-loops]], demonstrated auto-improvement (GigaChat 1/89 → 11/89 over a weekend). +- **Allie → "how do I, a person, run this day to day?"** Adoption mechanics: 3 foundation docs, 4 Claude surfaces, "just complain," proactive scheduled workflows, trust calibration, team-vs-headcount choices. + +**Framing of the *same* skills idea** (Konstantin ↔ Allie overlap, noted in [[skills-as-memory]]) +- Konstantin gives the **engineering** framing: git, CI/CD, merge-conflict resolution by models, storage ceilings, back-pressure loops. +- Allie gives the **business** framing: folders you can hand to a teammate, compose, "share between agents," portable across ChatGPT/Perplexity/Gemini. +- Theo mostly doesn't discuss skills at all — his nearest equivalent is markdown-**as-service** (the G-brain tier), the same "executable prose" instinct one layer out. + +**On code and craft** +- Theo: code is **throwaway**, cost heading to zero ([[code-as-throwaway]]); no guilt discarding work. +- Konstantin: code/tools are **commoditized**; value is in orchestration and the accumulated skill/data repo. +- Allie: **code is largely absent** — her audience is non-programmers, and her unit of value is context + workflows, not source. + +**Learning / self-improvement** +- Konstantin **demonstrates it today** via the git/skill loop (auto-created skills, weekend self-improvement runs). +- Allie **forecasts it** as a coming shift — "self-learning models with real weight updates," explicitly distinguished from today's memory-file retrieval (Status: tentative). +- Theo doesn't address learning loops; his axis is ambition, not memory. + +**Emotional register** +- Theo: **present shock / identity** ("everything we knew has changed"; the iOS-6 skeuomorphic phase). +- Konstantin: **calm evolutionary roadmap** (each generation named, 2027 forecast). +- Allie: **urgency / FOMO** ("the gap will be irreversible in 1 year"). + +## Tensions worth noting (complementary, not contradictory) + +- **Throw code away (Theo) vs persist everything in git (Konstantin).** Reconciled by distinguishing the *artifact* from the *capability*: discard the throwaway code, but keep the **skill + data** that can regenerate it. Theo keeps the ambition; Konstantin keeps the memory. +- **Deskilling (Theo: code as throwaway) vs re-skilling (Allie: taste is the meta-skill).** Both point at the same relocation of value — away from execution, toward judgment/framing. +- None of the three directly contradicts another; the disagreements in this corpus are elsewhere (e.g. BYO- vs company-managed harness, online vs in-person networking — see [[overview]]). + +## Related Pages + +- Entities: [[theo-browne]] · [[konstantin]] · [[allie-miller]] +- Sources: [[2026-07-14-everything-we-knew-about-software-has-changed]] · [[2026-07-14-skills-based-on-git]] · [[2026-07-14-gap-between-ai-users-irreversible]] +- Concepts: [[skills-as-memory]] · [[personal-ai-operating-system]] · [[harness]] · [[think-wider-not-bigger]] · [[context-as-scarce-resource]] · [[code-as-throwaway]] +- Timeline: [[ai-agent-evolution]] +- Overview synthesis: [[overview]] + +## Open Questions + +- Theo and Allie both gesture at markdown-as-the-unit but neither publishes a **reusable template** (foundation docs / a good `SKILL.md`) — Konstantin has the mechanics but no size/data standards. The three together still leave the *starter template* unresolved (webinar-relevant). +- Does Theo's "throw it away" hold once Konstantin-style accumulated skills become the memory? I.e. is there a point where the repo is too valuable to reset — and does Konstantin's **meta-loop** (periodic wipe-and-restart) actually contradict "persist everything"? diff --git a/wiki/concepts/.gitkeep b/wiki/concepts/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/wiki/concepts/agentic-loops.md b/wiki/concepts/agentic-loops.md new file mode 100644 index 0000000..3e24516 --- /dev/null +++ b/wiki/concepts/agentic-loops.md @@ -0,0 +1,36 @@ +# Agentic Loops (Inner / Outer / Meta) + +#concept + +## Summary + +The next paradigm after the [[harness]] (Konstantin's forecast: dominant in 2027): wrap the agent in progressively larger loops. Three levels — **inner** (ReAct), **outer/Ralph** (infinite `while true`), and **meta** (periodic wipe-and-restart). + +## Current Understanding + +- **Inner loop** = the classic ReAct cycle inside the harness: task → call tools → reflect → … → solved → text answer. +- **Outer / Ralph loop** (attributed to Geoffrey Huntley): `while true; do claude --dangerously-skip-permissions -p "solve" || true; done`. Lets an agent work for days/weeks and — crucially — stay in the **"smart zone"** (roughly the first third of context, where the model is sharpest) by avoiding the context growth → summarization → decay spiral. Guardrails against "slop": **CI/CD as back-pressure** and code-quality validation. See [[context-as-scarce-resource]]. +- **Meta loop** (Konstantin's own, not standard): periodically stop, wipe all agent-created data into an archive the agent can't initially see, and restart from scratch — so it explores a *different* path. Counters **collapse** (Karpathy): asked repeatedly, a model reworks the *same* solution with different words (the "tells the same joke with new characters" example). Good for open-ended research tasks. + +This is the domain of the emerging **loop-engineer** role (after prompt → context → harness engineer). + +## Evidence + +- Three-level loop model, Ralph loop code, smart-zone argument, meta-loop, collapse, back-pressure — [[2026-07-14-skills-based-on-git]]. +- Auto-agent example: weak GigaChat 1/89 → 11/89 over a weekend inside a self-improvement loop (idea from Karpathy's "autoagent"). +- Orchestration-era models that self-verify are the model-side complement — [[2026-07-14-everything-we-knew-about-software-has-changed]]. + +## Related Pages + +- Concepts: [[harness]], [[context-as-scarce-resource]], [[skills-as-memory]], [[evolution-of-agent-tooling]] +- Entity: [[konstantin]] +- Tools: [[claude-code]], [[hermes]] + +## Contradictions / Uncertainty + +- The "smart zone = first third of context" is a rule of thumb, not a measured constant. Status: tentative. +- Meta loop is the author's own construct, "not generally accepted." + +## Next Questions + +- What CI signals make the best back-pressure without over-constraining exploration? diff --git a/wiki/concepts/code-as-throwaway.md b/wiki/concepts/code-as-throwaway.md new file mode 100644 index 0000000..7d3f3b4 --- /dev/null +++ b/wiki/concepts/code-as-throwaway.md @@ -0,0 +1,39 @@ +# Code as Throwaway + +#concept + +## Summary + +When the cost of writing code trends to zero, code stops being a precious asset. Multiple sources converge: kill code without guilt, stop guilt-merging, and move your value up the chain from *producing* code to *directing and verifying* it. + +## Current Understanding + +- **Cost → zero.** Sebastian: "It's not a question *if* AI can write software anymore — it's just a question of *how* you use it." Most code isn't high-value; open source will grow because giving away near-free code costs little. +- **No sunk-cost guilt.** Theo: reset instead of "guilt-merging" a PR someone spent a week on — and an under-appreciated gift of agents is that there's no guilt throwing away an agent's work. "We are not looking at asm anymore." +- **The role shift.** The engineer moves from writing the solution to **framing the problem and verifying the result** — see [[product-ownership]]. Sebastian's printer anecdote: his edge wasn't Java, it was knowing how to *instruct and verify* (Claude Code solved it in ~30 min). +- **New bottom tier.** Theo's "G-brain tier" — a markdown file as executable prose replacing a whole service — is the logical endpoint: if code is disposable, prose that regenerates it is the artifact worth keeping. Connects to [[skills-as-memory]]. +- **The discipline side.** Theo's follow-up talk turns "disposable" from an attitude into a practice: draw the line between code-that-ships and code-that-doesn't, keep (or raise) hand-verification on the ship side, and generate 100–10,000× more never-shipped code to verify and explore — see [[make-more-cheap-code]]. Disposable ≠ ship slop; he explicitly disowns that reading. + +- **The trust carve-out.** Eugene puts a date and a boundary on it: "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." Cheap code does not mean uniformly trusted code; the exceptions are where a silent error is unrecoverable rather than merely wrong. Consistent with the safety-critical exception noted below. + +Caveat: legacy/hobby niches persist (COBOL in banks — no training data; coding "for the love of it, like an old-timer car") — but not where time, quality, and money matter. + +## Evidence + +- Cost-of-code → zero, OSS grows, printer anecdote, COBOL/hobby niches — [[2026-07-14-sebastian-eugene-interview]]. +- Kill code without guilt, guilt-merging, G-brain markdown tier — [[2026-07-14-everything-we-knew-about-software-has-changed]]. +- "Code isn't elite anymore" from 4.6 on; authorization and payments withheld; browser-over-emulator testing note — [[2026-07-21-larysa-interview]]. +- Ship/no-ship line, four tiers, 100-lines-of-slop-per-shipped-line, "make more cheap code" — [[2026-07-24-youre-reading-way-too-much-code]]. + +## Related Pages + +- Concepts: [[make-more-cheap-code]], [[product-ownership]], [[think-wider-not-bigger]], [[skills-as-memory]], [[decoupling-identity-from-profession]], [[leave-less-room-for-imagination]] +- Entities: [[theo-browne]], [[sebastian]], [[eugene]] + +## Contradictions / Uncertainty + +- "Most code isn't high-value" is a generalization; safety-critical/regulated code is a clear exception (see [[enterprise-ai-reality]]). + +## Next Questions + +- If code is throwaway, what *is* the durable artifact — the prose spec, the skill, the tests, or the verification harness? *(Partially answered 2026-07-24: Theo names the verification harness a first-class output — "plan 10,000 lines of AI-generated verification" per critical module — alongside the prose that regenerates the rest. See [[make-more-cheap-code]]. Whether skills or harnesses are the more durable of the two remains open.)* diff --git a/wiki/concepts/connections-as-moat.md b/wiki/concepts/connections-as-moat.md new file mode 100644 index 0000000..ad8f12a --- /dev/null +++ b/wiki/concepts/connections-as-moat.md @@ -0,0 +1,37 @@ +# Connections as the Moat + +#concept + +## Summary + +The standout insight of the [[2026-07-14-sebastian-eugene-interview|Sebastian interview]]: once AI **levels** pure programming skill (a 20-year veteran and a fresh grad on the same subscription produce similar output), the one thing AI cannot commoditize is **real, in-person human connection** — and it grows more valuable as AI floods everything else. + +## Current Understanding + +- **What works for winning business:** showing up in person 2–4 days/week — business lunches, networking events, conferences, open days. Every real long-term customer came through personal network. +- **What doesn't:** sales agencies, cold calling, email marketing, LinkedIn campaigns, content, SEO — "Big zero." +- **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 ("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) — not "I run a software company," which everyone forgets. Because everyone uses the same AI tools, *everything online looks identical*; humanity is the differentiator (Virtido's `humans.verti.com` / "human badge" riff). Soon you won't be able to tell bots from humans on LinkedIn or a phone call ("in 10 years… zero"). +- **Convergent prediction:** Allie independently forecasts that as agents mediate everything, **personal human relationships become more valuable**, and agent-to-agent negotiation handles the rest. +- **Eugene converges too:** despite disagreeing with Sebastian on networking tactics, his own webinar thesis lands on the same residual — "AI can replace all information work; the human's role in this process is just to be human — introductions, communication" ([[2026-07-14-yulia-interview]]). + +This is the durable counterpart to [[code-as-throwaway]]: as the technical work commoditizes, relationships and [[product-ownership|ownership]] hold value. + +## Evidence + +- In-person vs digital outreach ("Big zero"), second-meeting mechanics, be-human advice — [[2026-07-14-sebastian-eugene-interview]]. +- Human relationships become *more* valuable as agents mediate; agent-to-agent comms — [[2026-07-14-gap-between-ai-users-irreversible]]. +- "The human's role is just to be human — introductions, communication" as the webinar's central thesis — [[2026-07-14-yulia-interview]]. + +## Related Pages + +- Concepts: [[decoupling-identity-from-profession]], [[product-ownership]], [[code-as-throwaway]], [[network-from-a-standing-start]] (the tentative how-to) +- Entities: [[eugene]] (his ~6-month unsolved problem), [[sebastian]], [[allie-miller]], [[virtido]] + +## Contradictions / Uncertainty + +- Eugene is invested in LinkedIn/articles; Sebastian calls online outreach a waste. The disagreement is unresolved — Sebastian's is a services-founder's view. + +## Next Questions + +- Concretely, how does an individual build a connections network **from a standing start**? — now has a tentative protocol ([[network-from-a-standing-start]]) and a validation plan ([[2026-07-14-network-from-standing-start]]: Sebastian round-2 interview instrument + optional deep-research complement). Still open until validated. diff --git a/wiki/concepts/context-as-scarce-resource.md b/wiki/concepts/context-as-scarce-resource.md new file mode 100644 index 0000000..0923213 --- /dev/null +++ b/wiki/concepts/context-as-scarce-resource.md @@ -0,0 +1,41 @@ +# Context as the Scarce Resource + +#concept + +## Summary + +Across sources, the binding constraint on agents is **context**, not model IQ. Managing it — what you load, when, and how long the agent stays sharp — is the core engineering discipline. Konstantin: the model has a **"smart zone"** (roughly the first third of context) where it's sharpest; beyond that it dulls, even with a million-token window. + +## Current Understanding + +Context pressure explains several otherwise-separate design choices: + +- **Tool ceilings** — every injected tool costs context, so harnesses cap at ~30–40 tools and >100 confuses even Fable 5. See [[harness]]. +- **Two-stage skill loading** — short descriptions always visible, long `SKILL.md` loaded on demand — is *the* trick that lets hundreds of [[skills-as-memory|skills]] coexist. See [[evolution-of-agent-tooling]]. +- **Ralph loop** keeps the agent in the smart zone by restarting instead of letting context grow → summarize → decay. See [[agentic-loops]]. +- **Skills-as-memory > RAG** — the harness decides what to load *when a skill activates*, rather than RAG pre-injecting facts before the model even starts. +- **Context engineering** (Allie) — "feeding the system who you are" via foundation docs — is the same idea from the user side. See [[personal-ai-operating-system]]. + +The human role has climbed prompt-engineer → **context-engineer** → harness-builder → loop-engineer, tracking exactly this concern. + +**The supply-side facet** ([[2026-07-22-ai-is-stupid]]): before context is *scarce* it is usually *absent*. "Intelligence without context loses to context without intelligence" — ten Nobel laureates asked about your sales month can only cite industry averages, while your rank-and-file employee answers better because they see your funnel, clients, and deals. The default "stupid AI" experience is a strong model given neither business context nor a [[harness]]; the fix is investing in context infrastructure (data, memory, integrations) before reaching for a bigger model. + +## Evidence + +- Smart zone, summarization decay, "context is the most valuable resource," tool/skill loading mechanics — [[2026-07-14-skills-based-on-git]]. +- Context engineering vs prompt engineering; foundation docs as durable context — [[2026-07-14-gap-between-ai-users-irreversible]]. +- "Intelligence without context loses"; Nobel-vs-employee analogy; invest in context before model upgrades — [[2026-07-22-ai-is-stupid]]. + +## Related Pages + +- Concepts: [[harness]], [[skills-as-memory]], [[agentic-loops]], [[evolution-of-agent-tooling]], [[personal-ai-operating-system]] +- Entities: [[konstantin]], [[allie-miller]] + +## Contradictions / Uncertainty + +- "First third = smart zone" is a heuristic, not a measured boundary; likely model-dependent. Status: tentative. +- [[2026-07-22-ai-is-stupid]] names **RAG** and long-term assistant memory as the practical context mechanisms; [[2026-07-14-skills-based-on-git]] argues [[skills-as-memory|skills]] beat RAG (load-on-activation vs pre-injection). Possibly audience-driven (business data vs procedures) rather than a real disagreement. Status: tentative. + +## Next Questions + +- How do you measure where a given model's smart zone actually ends? diff --git a/wiki/concepts/decoupling-identity-from-profession.md b/wiki/concepts/decoupling-identity-from-profession.md new file mode 100644 index 0000000..26bbf0c --- /dev/null +++ b/wiki/concepts/decoupling-identity-from-profession.md @@ -0,0 +1,31 @@ +# Decoupling Identity from Profession + +#concept + +## Summary + +As many professions collapse into "prompt the AI," tying your sense of self to a job title becomes dangerous. Two sources converge: shed the **developer identity baggage** that holds you back (Theo), and **separate who you are from what you do** or "we will feel worthless in a couple of years" (Sebastian/Eugene). + +## Current Understanding + +- **The philosophical turn (Sebastian/Eugene):** older generations tie identity to their job ("I *am* a doctor"). As those professions lose obvious societal value, the advice is to decouple: "Fundamentally I'm Eugene — I'm not a programmer. But I need to work on that." +- **The practical turn (Theo):** engineers are in a "skeuomorphic phase" (iOS 6 imitating physical objects). Symptoms of identity-as-baggage: terminal fetishism, language-as-identity ("he writes JavaScript"), ceremonial git norms (why *can't* we commit `.env`?), guilt-merging. Prescription: **audit** each tool/rule you cling to — right, or just habit? +- **Why it matters now:** the framework/language you pick matters far less than before; skill is [[connections-as-moat|leveled]] by AI; code is [[code-as-throwaway|disposable]]. What remains yours is judgment, [[product-ownership|ownership]], taste, and human relationships — none of which are a job title. + +## Evidence + +- "Decouple identity from profession," "Fundamentally I'm Eugene — I'm not a programmer" — [[2026-07-14-sebastian-eugene-interview]]. +- Skeuomorphic phase, terminal/language/git identity symptoms, "audit your developer identity" — [[2026-07-14-everything-we-knew-about-software-has-changed]]. + +## Related Pages + +- Concepts: [[code-as-throwaway]], [[connections-as-moat]], [[product-ownership]], [[think-wider-not-bigger]] +- Entities: [[sebastian]], [[eugene]], [[theo-browne]] + +## Contradictions / Uncertainty + +- Framed as advice/prediction, not established fact; the emotional cost of the transition is acknowledged but unquantified. Status: tentative. + +## Next Questions + +- What *does* a healthy post-profession identity anchor to — craft, curiosity, relationships, ownership? diff --git a/wiki/concepts/enterprise-ai-reality.md b/wiki/concepts/enterprise-ai-reality.md new file mode 100644 index 0000000..fd8cc0c --- /dev/null +++ b/wiki/concepts/enterprise-ai-reality.md @@ -0,0 +1,33 @@ +# Enterprise AI Reality + +#concept + +## Summary + +The indie/practitioner world and the regulated-enterprise world diverge sharply. Sebastian's key business insight: [[harness|"bring your own harness"]] **cannot survive compliance**, so a scalable, company-managed standard harness is an underserved market — "the interesting market." + +## Current Understanding + +- **Locked-down reality:** at Sebastian's biggest clients, engineers can't use their own laptops — only a centrally-managed VM with **zero ability to install their own tools**. Compliance and liability make ad-hoc, per-developer setups impossible. Reference points: a Roche SAP transformation ran ~1,200 engineers for years; banks first banned AI outright and now cautiously adopt it "because it's just so good." +- **The business opportunity:** *scalable, manageable, company-standard harnesses for larger engineering teams.* The gap between what individuals can do (custom [[harness]]) and what enterprises can allow **is** the product. +- **Governance vs leverage tension:** individuals get maximum leverage from personal harnesses ([[eugene]]); enterprises must standardize and control ([[sebastian]]). Unresolved — and monetizable. +- **Adjacent constraints:** the [[seniority-and-the-junior-squeeze|"read what you approve"]] security concern is amplified at scale; safety-critical/regulated code is the clear exception to [[code-as-throwaway|"most code isn't high-value"]]. + +## Evidence + +- Managed VMs / zero self-install, Roche ~1,200 engineers, banks banned→adopting, "company-managed resource," "the interesting market" — [[2026-07-14-sebastian-eugene-interview]]. + +## Related Pages + +- Concepts: [[harness]], [[seniority-and-the-junior-squeeze]], [[code-as-throwaway]] +- Entities: [[sebastian]], [[virtido]], [[eugene]] +- Tools: [[claude-code]] + +## Contradictions / Uncertainty + +- How AI transforms *huge* (~1,200-engineer, multi-year) programs is explicitly unknown even to Sebastian. +- Whether [[virtido|Virtido]] itself is building the company-managed harness, or just naming the market, is unstated. + +## Next Questions + +- What is the minimal compliant feature set for a centrally-managed enterprise harness? diff --git a/wiki/concepts/evolution-of-agent-tooling.md b/wiki/concepts/evolution-of-agent-tooling.md new file mode 100644 index 0000000..4e8f104 --- /dev/null +++ b/wiki/concepts/evolution-of-agent-tooling.md @@ -0,0 +1,36 @@ +# Evolution of Agent Tooling (Tools → MCP → Skills) + +#concept + +## Summary + +Konstantin's three-generation map of how agents get capabilities: **Tools (2022–2024) → MCP (late 2024–2025) → Skills (2025→)**. Each generation trades off developer cost, context consumption, and flexibility. + +## Current Understanding + +| Generation | What it is | Strength | Weakness | +|---|---|---|---| +| **Tools** | Function tagged and injected into the model call (LangChain/LlamaIndex) | Direct control | Every tool eats context; you write/adapt each yourself | +| **MCP** | Locally-deployed server exposing many tools via a standard protocol (Anthropic); marketplaces exist | Ready-made tools, plug-in | Dozens of tools per server → context blowout (>100 = chaos); network-load = security surface; needs a developer | +| **Skills** | Directory + `SKILL.md` (+ tools + data), two-stage loading | Hundreds without context blowout; author with text in any language; share via git/messenger | No standards yet for data/limits | + +**When to use which:** Skills when tasks are unknown/diverse or tool count is ~5–50; MCP when the agent is narrow, tasks are uniform, and the same small toolset applies every time. The line blurs — Claude Code converts MCP servers *into* skills (file laid down, functions not all injected), erasing most MCP downsides. Konstantin doesn't hate MCP; its problems are largely solved. + +## Evidence + +- Three generations, per-generation problems, skills-vs-MCP decision table, Claude-Code-turns-MCP-into-skills caveat — [[2026-07-14-skills-based-on-git]]. +- Skills as portable markdown folders across Claude/Perplexity/Gemini — [[2026-07-14-gap-between-ai-users-irreversible]]. + +## Related Pages + +- Concepts: [[skills-as-memory]], [[harness]], [[context-as-scarce-resource]] +- Tools: [[claude-code]], [[hermes]] +- Entity: [[konstantin]] + +## Contradictions / Uncertainty + +- "Everything changes every 6 months" — MCP was just ratified and A2A is already wanted; this map may shift quickly. Status: tentative. + +## Next Questions + +- Where does agent-to-agent (A2A) sit in this progression? diff --git a/wiki/concepts/harness.md b/wiki/concepts/harness.md new file mode 100644 index 0000000..0a3e7e7 --- /dev/null +++ b/wiki/concepts/harness.md @@ -0,0 +1,43 @@ +# Harness + +#concept + +## Summary + +A **harness** is a universal agent = LLM + a small standard toolset + a runtime loop. The metaphor (Konstantin): the LLM is the force, the tools are the harness/upness, the data is the field — the LLM "pulls the tools across the data space," turning raw tasks into solved ones. Different tasks, *same* processing method. + +## Current Understanding + +The harness is the de-facto unit of agentic work in 2026. A good one has: a **short** system prompt ("use the tools to solve the task"), ~10–40 standard tools (Read/Edit/Write, Bash, Grep/Glob/WebSearch, TodoWrite, subagent spawn), a ReAct runtime loop, context management (timely summarization, subagents without full context), standardized key files (CLAUDE.md/AGENTS.md, `skills/`), resilience to failures, and an interface (CLI/chat/messenger). It runs in two modes: **interactive** (human-in-the-middle → man-on-the-middle) and **autonomous** fire-and-forget (CLI + task arg, embeddable in CI/CD). + +**Tool ceiling:** >30–40 built-in tools appears in no popular harness; >100 confuses even Fable 5 because every tool is injected into each call — a key reason [[skills-as-memory|skills]] (two-stage loading) beat raw tools. See [[context-as-scarce-resource]]. + +**Consolidation over tool-hopping.** The [[2026-07-21-larysa-interview|Larysa interview]] sharpens Eugene's pitch into its user-facing form: assemble *one* place where all your project agents live and can talk to each other, instead of spinning up the tool in separate folders and juggling apps. The claimed payoff is as much cognitive as productive — "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" — freeing mental overhead he hadn't noticed he was spending. Completion notifications ("done thinking") are part of the claim: they are what make background agents usable without babysitting. This is the engineer's phrasing of the webinar's title arc, chat box → your own OS ([[levels-of-ai-usage]], [[personal-ai-operating-system]]). + +**The business-facing formula.** An anonymous Russian business short ([[2026-07-22-ai-is-stupid]]) independently restates the concept for non-engineers: the harness is an "engineering wrapper" — what the model must verify, which tools to trust, how to shape the answer, what is forbidden — and **strong model + your business context + harness = employee-level answer**. Remove any component and you get "smart but generic," "specific but undisciplined," or "stupid AI." Useful as webinar language: it names what the audience already feels (generic answers) without requiring the engineering vocabulary. + +**The governance fault line:** [[eugene]] argues every developer should **build their own** harness (deep knowledge → more effective). [[sebastian]] counters that "bring your own harness" cannot survive enterprise compliance — it must be a company-managed resource, and *that gap is the business*. See [[enterprise-ai-reality]]. + +## Evidence + +- Definition, toolset, two modes, popular harnesses (Claude Code, Codex CLI, Cursor, OpenClaude, Hermes) — [[2026-07-14-skills-based-on-git]]. +- BYO-harness demo and the enterprise counter-argument — [[2026-07-14-sebastian-eugene-interview]]. +- Orchestration-era models that "spawn sub-models and verify" are the model-side of the same idea — [[2026-07-14-everything-we-knew-about-software-has-changed]]. +- Claude Code as the reference harness across surfaces — [[2026-07-14-gap-between-ai-users-irreversible]]. +- Consolidated multi-project workspace, inter-agent messaging, completion signals, "before and after" claim — [[2026-07-21-larysa-interview]]. +- Harness as "engineering wrapper"; model + context + harness formula; "stupid AI" as the harness-less default — [[2026-07-22-ai-is-stupid]]. + +## Related Pages + +- Tools: [[claude-code]], [[hermes]] +- Concepts: [[skills-as-memory]], [[agentic-loops]], [[evolution-of-agent-tooling]], [[context-as-scarce-resource]], [[enterprise-ai-reality]], [[personal-ai-operating-system]], [[leave-less-room-for-imagination]] +- Entities: [[eugene]], [[sebastian]], [[konstantin]], [[larysa]] + +## Contradictions / Uncertainty + +- Personal vs company-managed harness is an unresolved tension (Eugene vs Sebastian), not a settled answer. +- The "life split into before and after" consolidation payoff is self-reported by its builder and never measured; Larysa, the practitioner it was pitched to, does not yet run one. Status: tentative. + +## Next Questions + +- What is the minimal compliant, centrally-managed harness a regulated team could adopt? diff --git a/wiki/concepts/integration-dead-ends.md b/wiki/concepts/integration-dead-ends.md new file mode 100644 index 0000000..73db7e6 --- /dev/null +++ b/wiki/concepts/integration-dead-ends.md @@ -0,0 +1,41 @@ +# Integration Dead-Ends + +#concept + +## Summary + +A distinct agent failure mode, separate from hallucination: the agent **accepts a task and starts working against a capability the user doesn't actually have** — a connector that isn't implemented, or one gated behind an account tier, paid seat, or corporate plan. The user only finds out after the time and tokens are already spent. [[larysa]]: "That's not hallucination exactly… it just first goes looking for what you don't have." + +## Current Understanding + +The failure is one of **optimistic capability assumption**. The agent reasons about the ideal tool for the job rather than the tools available to *this* user in *this* account, and nothing in the loop checks entitlement before work begins. Cost is asymmetric: the discovery happens late (half an hour in, in Larysa's case), so the whole run is wasted rather than cheaply rejected. + +Three concrete gates seen in the corpus: + +- **No external API at all** — Microsoft Teams. Asserted as an outright dead end for a chat-watching auto-task bot. +- **Paid seat required** — Slack has first-class Claude support from Anthropic, but the seat wasn't granted; Figma's editable access needs a personal paid account. +- **Account type** — the recommended path existed only for corporate, not private, accounts. + +The corpus offers **no fix**, only a discipline: **verify the integration and account requirements up front** (connector exists? private vs. corporate? paid seat?) before letting the agent spend. Both participants explicitly left the general problem unsolved. Structurally this is the mirror image of [[leave-less-room-for-imagination]] — there the agent over-interprets an under-specified *goal*; here it over-assumes an unverified *capability*. + +Note the enterprise angle: entitlement gates are precisely what a centrally-managed harness could encode once for everyone, rather than each user rediscovering them by burning tokens ([[enterprise-ai-reality]]). + +## Evidence + +- The Teams/ClickUp bot dead end, private-vs-corporate account gate, the "half an hour" cost, "I don't know how to fight this" — [[2026-07-21-larysa-interview]]. +- Slack/Figma paid-seat blockers from the same interview. + +## Related Pages + +- Concepts: [[leave-less-room-for-imagination]], [[skills-as-memory]] (a skill can freeze "what we actually have access to"), [[context-as-scarce-resource]], [[enterprise-ai-reality]], [[evolution-of-agent-tooling]] +- Entities: [[larysa]], [[eugene]], [[claude-code]] + +## Contradictions / Uncertainty + +- "Teams has no usable external API" is an assertion by the participants, not a demonstrated finding. Status: tentative. +- Whether this is a harness bug (no entitlement pre-check) or a user-workflow gap is unresolved in the corpus. + +## Next Questions + +- Could a standing "available integrations" context doc or skill — an explicit capability inventory — pre-empt this cheaply? +- Do agents fail this way on *local* capabilities too (missing binaries, no credentials), or is it specific to hosted connectors? diff --git a/wiki/concepts/leave-less-room-for-imagination.md b/wiki/concepts/leave-less-room-for-imagination.md new file mode 100644 index 0000000..0b4fbdd --- /dev/null +++ b/wiki/concepts/leave-less-room-for-imagination.md @@ -0,0 +1,43 @@ +# Leave Less Room for Imagination + +#concept + +## Summary + +[[eugene]]'s prompting principle: **every gap you leave in a specification, the agent will fill — and it will fill it differently than you imagined, invisibly.** "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." The remedy is not longer prompts but **standardized procedures** — [[skills-as-memory|skills]]. + +## Current Understanding + +The claim has two halves, and the second is the sharp one: + +1. Under-specified tasks cause **drift**. +2. The drift causes **collateral damage you don't notice** — which is what makes it expensive. A visibly wrong answer is cheap; a plausibly wrong one that lands in your codebase is not. + +This is Eugene's explicit critique of demo culture: asking Claude to build a whole project in one or two requests is exactly the maximum-imagination case, which is why such demos impress and don't reproduce. The practical form of the principle already appears one rung up the ladder as "narrow the variability of interpretation when prompting" ([[levels-of-ai-usage]]), and it is a large part of *why* [[solve-first-then-skillify]] works: a skill is a spec that has already had its ambiguity beaten out of it by a real correction loop. + +**Model-choice corollary.** Eugene runs **Claude 4.7** rather than 4.8, calling 4.8 "too proactive" — "without the flights of fancy 4.8 has." He treats over-eagerness as a property to select against in the model, not only in the prompt. (Whether that is really a model trait or an unspecified-prompt symptom is unresolved — see below.) + +Tension worth holding: [[think-wider-not-bigger]] argues for giving models *more* latitude across a wider surface. These are compatible only if read as breadth-of-attempts vs. tightness-of-each-spec — many cheap wide attempts, each individually well-constrained. + +## Evidence + +- "The more room for imagination, the more it will exploit it"; the collateral-damage-you-won't-notice framing; the one-or-two-requests demo critique; 4.7 vs 4.8 — [[2026-07-21-larysa-interview]]. +- "Narrow the variability of interpretation when prompting" as a plateau practice — [[2026-07-14-yulia-interview]]. +- Skills as frozen, proven procedure — [[2026-07-14-skills-based-on-git]]. + +## Related Pages + +- Concepts: [[skills-as-memory]], [[solve-first-then-skillify]], [[levels-of-ai-usage]], [[integration-dead-ends]] (the capability-side mirror), [[think-wider-not-bigger]] (tension), [[product-ownership]] +- Entities: [[eugene]], [[larysa]], [[claude-code]] + +## Contradictions / Uncertainty + +- Sits in tension with [[think-wider-not-bigger]]; reconciled above as breadth vs. per-task tightness, but neither source addresses the other. Status: tentative. +- **Diff summaries vs invisible drift** (added 2026-07-24): Theo/Dax recommend routing big diffs through agent per-file summaries instead of line-by-line reads — "anything weird will stick out" ([[2026-07-24-youre-reading-way-too-much-code]]). Eugene's claim here is the opposite: the damage is what you *don't* notice, and a summary is exactly where drift hides. Theo's tier framework partially reconciles it (summaries are a tier-B/C practice; tier-D still reads every line, and slop verification catches what reading misses — see [[make-more-cheap-code]]), but neither source addresses the other. Status: tentative. +- "4.8 is too proactive" is one practitioner's preference from production use, not a benchmark. Status: tentative. + +## Next Questions + +- Is there a floor — a spec so tight the agent stops adding value and you'd have been faster writing it yourself? +- Can drift be *harnessed* as a diagnostic? A fresh zero-context agent's misreading of a spec marks exactly where the spec leaves room for imagination — the sandboxed inverse of this concept's failure mode. Proposed by synthesis at [[2026-07-24-non-engineer-throwaway-verification]]; untested. Status: tentative. +- Does newer-model over-proactivity make skills *more* necessary, or does it get absorbed as models improve at asking clarifying questions? diff --git a/wiki/concepts/levels-of-ai-usage.md b/wiki/concepts/levels-of-ai-usage.md new file mode 100644 index 0000000..50c9a2c --- /dev/null +++ b/wiki/concepts/levels-of-ai-usage.md @@ -0,0 +1,37 @@ +# Levels of AI Usage + +#concept + +## Summary + +Eugene's ladder of AI adoption, mapped for the webinar: **web chatbot → built-in memory → Claude Code/Cowork with local file access → CLAUDE.md → skills → Obsidian knowledge base → RAG**. Most people are stuck at level one; the practical ceiling for non-programmers is **CLAUDE.md + skills** ("that's your maximum"). + +## Current Understanding + +The ladder is a diagnosis tool and a curriculum at once. Each rung adds persistence and leverage: memory makes the chat remember, local file access makes it act, CLAUDE.md makes instructions durable, [[skills-as-memory|skills]] make processes reusable, a knowledge base makes answers compound, and RAG only matters at corporate scale. It is the structural skeleton of the planned webinar (*"From a chat box to your own operating system"* — the title itself names the bottom and top rungs) and the practitioner's version of Allie Miller's [[personal-ai-operating-system]]: her foundation-docs + skills + proactive workflows land at the same CLAUDE.md-plus-skills plateau. + +Supporting practices at the plateau: keep CLAUDE.md self-maintaining ("always keep CLAUDE.md up to date"), narrow the variability of interpretation when prompting ([[leave-less-room-for-imagination]]), and [[solve-first-then-skillify|solve first, skill-ify after]]. + +**The ladder is not strictly sequential — [[larysa]] is the counter-example.** She operates several rungs up (local file access, real PRs, ClickUp/Figma integrations) while missing the skills rung entirely, and her symptoms are exactly what the missing rung predicts: the agent "forgets," so she re-explains every session. This is diagnostically useful for the webinar — users can be *technically* advanced and *architecturally* stuck at the same time, and the fix is a rung they skipped rather than more capability. + +## Evidence + +- The full ladder, the "CLAUDE.md and skills — that's your maximum" ceiling, RAG-only-at-scale — [[2026-07-14-yulia-interview]]. +- Webinar title and non-programmer audience confirm the ladder as the webinar's spine — [[2026-07-14-nina-interview]]. +- Convergent structure (foundation docs + skills as the non-engineer's OS) — [[2026-07-14-gap-between-ai-users-irreversible]]. +- A high-rung user missing the skills rung, and the memory pain that results — [[2026-07-21-larysa-interview]]. + +## Related Pages + +- Concepts: [[personal-ai-operating-system]], [[skills-as-memory]], [[solve-first-then-skillify]], [[harness]] (the engineer's continuation of the same ladder), [[evolution-of-agent-tooling]], [[leave-less-room-for-imagination]] +- Entities: [[eugene]], [[yulia]], [[allie-miller]], [[larysa]] + +## Contradictions / Uncertainty + +- The rung ordering is Eugene's pedagogical framing, not an industry standard; other sources slice the progression differently ([[evolution-of-agent-tooling]] is tool-centric rather than user-centric). Status: tentative. +- Larysa demonstrates the rungs are **skippable**, so the ladder is better read as a checklist of capabilities than as a strict sequence. Status: tentative. + +## Next Questions + +- Does the final webinar script keep this exact rung order? (`raw/sources/Webinar script.md` is not yet ingested.) +- Where do agents/processes (the harness's outer loops) sit for a non-programmer — above skills, or out of reach? diff --git a/wiki/concepts/make-more-cheap-code.md b/wiki/concepts/make-more-cheap-code.md new file mode 100644 index 0000000..f4f4dcc --- /dev/null +++ b/wiki/concepts/make-more-cheap-code.md @@ -0,0 +1,38 @@ +# Make More Cheap Code + +#concept + +## Summary + +[[theo-browne]]'s inversion of the "should you read AI code?" debate: the goal is not to trust AI code more, but to **generate mountains of code that was never meant to be read or shipped** — for verification, exploration, stress-testing, and one-off questions. "I'm not telling you to make your code cheaper. I'm telling you to make more cheap code." The more important your shipped code is, the *more* throwaway code you should generate around it. + +## Current Understanding + +- **The ship/no-ship line.** Draw an explicit line between code-that-ships and code-that-doesn't, and apply discipline separately: same (or more) hand-verification on the ship side; near-zero reading on the throwaway side. The failure mode isn't reading too much — it's a generated-to-read ratio stuck at pre-AI levels. +- **Four tiers of code, four reading disciplines:** **A** slop (never read — exists to answer one question), **B** "I'd like this to work" (skim / agent summary), **C** "trouble if it breaks" (read signatures, APIs, boundaries; lean on tests + AI review), **D** death tier (read every line). Nobody works 100% in D — and tier-D specialists have the biggest untapped upside, because before AI they never used tiers A–B at all. +- **Verification is the killer app.** "Every line of code that goes in should have 100 lines of slop verifying it" — fuzzers, property probes, custom lint rules for a bug you just found, one-off debuggers, alternate implementations, load rigs. Shao's cited ratio: ~80% of AI-generated code goes into test harnesses whose results feed back into the LLM's context. +- **Always another layer.** "Too important for AI to touch" is never terminal: abstract one layer up and generate tooling that verifies (or introspects the verifiers of) the sacred core. +- **Exploration patterns:** slop-port a service to another language just to benchmark it; test 3 theories of an ambiguous PR in parallel; **use dumb-model agents as API usability testers** — if a weak model can't build on your SDK, that's a UX bug in the SDK. +- **Reading economics.** Reading still costs attention (the human-side analog of [[context-as-scarce-resource]]): don't read faster, read *only what's worth reading* — every signature and API always, function bodies rarely, per-file agent summaries instead of giant diffs (via Dax). Have AI review code before humans do. +- **What this is not:** a license to merge unreviewed slop. Theo explicitly keeps hand-verification of shipped code unchanged and disowns vibe-coders who ship slop ("I hate them too"). + +## Evidence + +- All claims, ratios, tier table, slop patterns, Dax/Shao citations — [[2026-07-24-youre-reading-way-too-much-code]]. +- Groundwork (code disposable, kill without guilt, G-brain markdown tier) — [[2026-07-14-everything-we-knew-about-software-has-changed]]. + +## Related Pages + +- Concepts: [[code-as-throwaway]] (parent claim: cost → zero; this page is its *discipline* — what cheap code is actually for), [[think-wider-not-bigger]] (same breadth logic applied to generation volume rather than ambition), [[product-ownership]] (verifying as the human's remaining job), [[solve-first-then-skillify]] (contrast: slop is frozen into nothing; skills freeze the procedure), [[leave-less-room-for-imagination]] (tension — see below), [[context-as-scarce-resource]] +- Entities: [[theo-browne]], [[eugene]] + +## Contradictions / Uncertainty + +- **Diff summaries vs invisible drift.** The Dax/Theo practice "ask the agent to summarize the diff — anything weird sticks out" assumes anomalies surface in summaries; [[eugene]]'s core worry ([[leave-less-room-for-imagination]]) is that drift's collateral damage is precisely what you *don't* notice. Theo's implicit answer is tiering plus generated verification rather than more reading, but neither source addresses the other. Status: tentative. +- Shao's "fewer mistakes overall" is asserted, not measured. All of Theo's ratio numbers are self-reported illustrations. Status: tentative. +- Where do persistent steering artifacts (skills, CLAUDE.md, prompts) sit on the A–D spectrum? They are cheap to write yet compound like tier-C/D assets — the framework doesn't say. + +## Next Questions + +- What does the throwaway-verification bucket look like in a non-engineer's workflow (the webinar audience) — is there an HR/BA analog of "10,000 lines of slop to verify one line"? *(Answered by synthesis 2026-07-24: generated checks, not generated content — fresh-agent misread tests, parallel interpretations, checker skills, synthetic-candidate simulations. See [[2026-07-24-non-engineer-throwaway-verification]].)* +- Does tier-A slop generation stay cheap once context is accounted for — or does reviewing *agent behavior* replace reviewing code as the attention sink? diff --git a/wiki/concepts/network-from-a-standing-start.md b/wiki/concepts/network-from-a-standing-start.md new file mode 100644 index 0000000..1ba1c9f --- /dev/null +++ b/wiki/concepts/network-from-a-standing-start.md @@ -0,0 +1,49 @@ +# Network From a Standing Start + +#concept + +## Summary + +A **tentative, falsifiable protocol** for building a professional network from zero, synthesized from fragments already in the vault (Sebastian's principles, Allie's prediction, Eugene's live experiment). Status: **tentative** throughout — this page exists to be attacked, not trusted. The validation plan lives in [[2026-07-14-network-from-standing-start]]. + +## Current Understanding + +### The protocol (v0) + +1. **Pick recurring venues, not events.** The core mechanic — a connection forms when the *same* person meets you again in *different* circumstances — requires repeated co-presence. One-off conferences can't produce second meetings; a monthly meetup, a standing lunch circuit, or a community you rejoin can. (Derived from Sebastian's second-meeting mechanics.) +2. **Show up on a sustainable cadence.** Sebastian's current system is 2–4 days/week, but that's a founder's full sales motion; the minimum viable cadence for bootstrapping is unknown (key follow-up question). +3. **Lead with something human, not your profession.** "I run a software company" is forgotten; the house renovation, two kids, the cat are remembered. Recognition value is the asset being built — and since everyone's AI-polished online output looks identical, in-person humanness is the differentiator. +4. **Engineer the second meeting in different circumstances.** Don't collect contacts; convert first meetings into a different-context follow-up (a 1:1 coffee after a meetup, a different event you know they attend). Metric to track: **second meetings, not contacts collected.** +5. **Let referrals do the outreach.** The chain is recognition → trust → "there's this guy, I met him a couple of times, he's real" → referral. Cold channels are skipped, not optimized. + +### Anti-tactics (contested) + +Sebastian's "Big zero" list — sales agencies, cold calling, email marketing, LinkedIn campaigns, content, SEO. **Status: contested**, not settled: Eugene invests in LinkedIn/articles and the disagreement is recorded in [[connections-as-moat]]. The protocol treats these as unproven for *relationship formation* while acknowledging they may serve other goals (visibility, hiring). + +### The live experiment + +Eugene's webinar is an unnamed instance of this protocol: the same people ([[nina]], [[yulia]], the [[virtido]] team) encountering him repeatedly in different circumstances (interviews → webinar → possible paid HR build). If the paid build lands, that's a documented recognition → trust → paid-work chain. Worth tracking as the protocol's first case study. + +## Evidence + +- Second-meeting mechanics, humanness advice, "Big zero", referral chain — [[2026-07-14-sebastian-eugene-interview]]. +- Relationships rise in value as agents mediate everything — [[2026-07-14-gap-between-ai-users-irreversible]]. +- Eugene's convergent thesis ("the human's role is just to be human — introductions, communication") and the webinar-as-experiment context — [[2026-07-14-yulia-interview]], [[2026-07-14-nina-interview]]. + +## Related Pages + +- Concepts: [[connections-as-moat]] (why this matters), [[decoupling-identity-from-profession]] (lead-with-human is its practical face), [[product-ownership]] +- Entities: [[sebastian]] (the working system), [[eugene]] (the standing start), [[allie-miller]] +- Query: [[2026-07-14-network-from-standing-start]] (validation plan + interview instrument) + +## Contradictions / Uncertainty + +- Entire protocol is inferred from one founder's retrospective principles plus convergent predictions — no from-zero case has been observed end-to-end. Status: tentative. +- "Big zero" vs Eugene's online investment: unresolved; may be audience-dependent (services sales vs individual reputation). +- Sebastian may never have had a true standing start (prior-job network as seed capital) — the follow-up interview tests this directly. + +## Next Questions + +- All ten questions in the interview instrument — see [[2026-07-14-network-from-standing-start]]. +- What is the minimum viable cadence (the 2–4 days/week number is a founder's, not a bootstrapper's)? +- Does the webinar → paid-build chain complete? (The live case study's outcome.) diff --git a/wiki/concepts/personal-ai-operating-system.md b/wiki/concepts/personal-ai-operating-system.md new file mode 100644 index 0000000..780214a --- /dev/null +++ b/wiki/concepts/personal-ai-operating-system.md @@ -0,0 +1,41 @@ +# Personal AI Operating System + +#concept + +## Summary + +Allie Miller's central idea: the compounding advantage isn't prompting — it's building a **personal AI operating system** = persistent context documents + reusable [[skills-as-memory|skills]] + proactive scheduled workflows that run 24/7. Invest one focused week and, in 12 months, the gap to a chat-box user is irreversible. + +## Current Understanding + +Three layers, built bottom-up: + +1. **Foundation context docs** (spend ~1 hour letting Claude interview you): + - **Personal Constitution** — values, working style, "what makes me tick" (nothing time-bound). + - **Goals doc** — annual → quarterly → monthly → weekly, habits to build/kill. + - **Core Business Strategy doc** — who you serve + the off-website nuance (failed launches, why you live where you live). + - Result: outputs jump from generic to ~50% "your zone." +2. **Skills** — composable markdown folders (tone-of-voice, brand-guidelines, anti-AI-language, role-specific). See [[skills-as-memory]]. +3. **Proactive workflows** — scheduled agents (Morning Brief, Friday Email Recap) that produce and report while you sleep. Schedule the *asking*, not just the task. + +Mindset reframes: AI as **first-class teammate** (not intern), as an **OS** (not a tool you open), and **[[context-as-scarce-resource|context engineering]]** (not prompt engineering). The 4-tier ladder of AI work: Microtask → Companion → Delegate → Teammate. This is the non-engineer's counterpart to the [[harness]]. + +## Evidence + +- 3 foundation docs, 4 surfaces, "just complain," proactive workflows, 4-tier model, trust calibration — [[2026-07-14-gap-between-ai-users-irreversible]]. +- Setup scale: 36 workflows, ~28 master agents, ~100 agents; 2–10× productivity. + +## Related Pages + +- Concepts: [[skills-as-memory]], [[context-as-scarce-resource]], [[connections-as-moat]], [[levels-of-ai-usage]] +- Entity: [[allie-miller]], [[eugene]] +- Tools: [[claude-code]] +- Compare: [[harness]] (engineer's version of the same "universal agent + context" idea — see its *consolidation over tool-hopping* section, where Eugene independently arrives at the same "everything in one place" OS framing from the [[2026-07-21-larysa-interview|Larysa interview]]) + +## Contradictions / Uncertainty + +- "Investment not cost" (1 hour → ~3 hrs/week saved) is Allie's framing; the payback is asserted, not independently measured. Status: tentative. + +## Next Questions + +- Reusable templates for the three foundation docs — a concrete webinar deliverable? diff --git a/wiki/concepts/product-ownership.md b/wiki/concepts/product-ownership.md new file mode 100644 index 0000000..be9bbbb --- /dev/null +++ b/wiki/concepts/product-ownership.md @@ -0,0 +1,32 @@ +# Product Ownership & Problem Framing + +#concept + +## Summary + +The durable human skill in the AI era: **owning outcomes**, not completing tickets. Put yourself in the user's shoes, look at the actual result, and reframe work from "what needs to be done" to "**what problem needs to be solved**." Sebastian: "No one ever needed a programmer… people have problems that you are solving." + +## Current Understanding + +- **The 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 absence is the absence of ownership — a mindset/personality trait, not a task list. +- **Reframe the vocabulary:** stop thinking in tasks/tickets; think in problems and desired outcomes. If you don't understand what to build, "you will simply not be an engineer anymore"; if you *do* get closer to the product, the software gets better (product-wise, even if not always technically). +- **Verification is the new craft.** As [[code-as-throwaway|code becomes disposable]], the engineer's value is *directing and verifying* — Sebastian's printer anecdote: his edge was knowing how to instruct and check the result, not writing Java. This is also the senior's advantage: **read what you approve** ([[seniority-and-the-junior-squeeze]]). +- **Allie's parallel:** the meta-skill is **knowing what good looks like** (taste) — you don't need to do the graphic design to judge whether the ad is good. + +## Evidence + +- Profile-picture story, "problems not programmers," printer anecdote, ownership as mindset — [[2026-07-14-sebastian-eugene-interview]]. +- "Knowing what good looks like" / taste as the meta-skill — [[2026-07-14-gap-between-ai-users-irreversible]]. + +## Related Pages + +- Concepts: [[code-as-throwaway]], [[seniority-and-the-junior-squeeze]], [[connections-as-moat]], [[decoupling-identity-from-profession]] +- Entities: [[sebastian]], [[eugene]], [[allie-miller]] + +## Contradictions / Uncertainty + +- "Get closer to the product" can improve product quality while *reducing* technical quality — the interview flags this trade-off explicitly. + +## Next Questions + +- How do you *teach/hire for* ownership if it's a personality trait, not a checklist? diff --git a/wiki/concepts/seniority-and-the-junior-squeeze.md b/wiki/concepts/seniority-and-the-junior-squeeze.md new file mode 100644 index 0000000..37e5100 --- /dev/null +++ b/wiki/concepts/seniority-and-the-junior-squeeze.md @@ -0,0 +1,31 @@ +# Seniority and the Junior Squeeze + +#concept + +## Summary + +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. The differentiator is **judgment as risk reduction**. + +## Current Understanding + +- **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 senior's real product is judgment — see [[product-ownership]]. +- **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… the codebase — they will [wreck] it in two days." **Read what you approve.** +- **Team shape:** the ~8-person scrum team (scrum master + PM + requirements engineer + big dev team) collapses to **2–3 people** — one coordination/ownership role plus one or two who manage the coding agents, sharing responsibilities. +- **Leveling caveat:** on *pure programming skill*, AI **levels** senior and junior (same output). The senior's edge is entirely in judgment, verification, and knowing failure modes — not typing speed. Contrast with [[connections-as-moat]], where the edge is relationships. + +## Evidence + +- Seniors more valuable, juniors squeezed, "allow-all" security habit, junior-wrecks-it-in-2-days, team collapse to 2–3 — [[2026-07-14-sebastian-eugene-interview]]. + +## Related Pages + +- Concepts: [[product-ownership]], [[enterprise-ai-reality]], [[connections-as-moat]], [[code-as-throwaway]] +- Entities: [[sebastian]], [[eugene]] + +## Contradictions / Uncertainty + +- Tension: if a junior + Claude can match a senior's output, "juniors are irrelevant" may reflect *today's* hiring psychology more than a permanent truth — and it raises an unspoken pipeline problem (where do future seniors come from?). Status: tentative. + +## Next Questions + +- If juniors can't get in, how does the industry produce the next generation of seniors? diff --git a/wiki/concepts/skills-as-memory.md b/wiki/concepts/skills-as-memory.md new file mode 100644 index 0000000..565a27d --- /dev/null +++ b/wiki/concepts/skills-as-memory.md @@ -0,0 +1,42 @@ +# Skills as Memory + +#concept + +## Summary + +A **skill** is a directory + a gentleman's agreement: a `SKILL.md` describing *what to do*, plus optional tools (bash/python) and — Konstantin's key proposal — the **data and usage history** in the same git repo. Combined this way, skills become **the new memory of AI agents**: information about the user lives in skills, loaded exactly when a skill activates, rather than pre-fetched by RAG. + +## Current Understanding + +The unlock is **two-stage loading**: a short description always sits in the system prompt (the agent knows the skill exists); the long `SKILL.md` loads only when the agent enters the directory. This lets a harness hold *hundreds* of skills without blowing [[context-as-scarce-resource|context]] — impossible with raw tools, where a couple of calls exhaust context. Skills also **compose** (one skill calls another) and are **portable** (plain markdown folders migrate Claude → Perplexity → Gemini). + +A classic skill is "**von Neumann without data**" (code, no data). Adding data + history makes the skill self-contained; storing it in **git** enables skill-first architecture (many agents on one skill), CI/CD integration, team sharing, and merge-conflict resolution by models. Skills can **auto-improve**: create a skill after >5 tool calls on a task; a curator prunes unused skills (30/90 days) and consolidates weekly. See [[hermes]]. + +The **method** for populating skills is [[solve-first-then-skillify]]: reach the final solution once, then freeze it (Eugene's variant of the heuristic: any correction loop longer than ~3 messages becomes a skill). The HR interviews add a social payoff: a packaged skill is a **handoff/de-risking asset** — a junior "with not even a third of your HR experience" can deliver a decent result, and the expert can take a vacation. + +**The negative case: built-in memory as anti-feature.** The [[2026-07-21-larysa-interview|Larysa interview]] supplies the demand-side reason this architecture exists. Her core frustration is that the agent doesn't carry context between sessions — she re-explains, and re-pays in time and tokens. Eugene's answer is not "better memory" but *no* memory: "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." The claim is that an opaque, always-on memory that silently decides what to recall is worse than nothing, because the user can neither inspect nor correct it — whereas a skill is a file you can read, edit, version and delete. Skills are the memory you *author*. + +## Evidence + +- Skill definition, two-stage loading, data-in-git proposal, curator, auto-creation — [[2026-07-14-skills-based-on-git]]. +- Skill = folder with one MD + resources; skills compose and transfer across tools/models; built-in skill-creator — [[2026-07-14-gap-between-ai-users-irreversible]]. +- Markdown-file-as-service (G-brain tier) is the same "executable prose" instinct — [[2026-07-14-everything-we-knew-about-software-has-changed]]. +- Skill as zip-and-hand-over onboarding asset; "create a skill for this" — [[2026-07-14-nina-interview]]. +- ~3-message correction-loop heuristic; skills as the non-programmer ceiling (with CLAUDE.md) — [[2026-07-14-yulia-interview]]. +- Cross-session memory loss as the #1 practitioner pain; "memory is the worst thing agents have"; skills committed as the webinar remedy — [[2026-07-21-larysa-interview]]. + +## Related Pages + +- Concepts: [[evolution-of-agent-tooling]] (tools → MCP → skills), [[harness]], [[context-as-scarce-resource]], [[agentic-loops]], [[personal-ai-operating-system]], [[solve-first-then-skillify]], [[levels-of-ai-usage]], [[leave-less-room-for-imagination]] +- Tools: [[hermes]], [[claude-code]] +- Entities: [[konstantin]], [[allie-miller]], [[eugene]], [[larysa]] + +## Contradictions / Uncertainty + +- No standards yet for *what* data to put in a skill or its size limit (Konstantin: 200 GB in one, 100 KB in another, both fine — "ceiling not found"). Status: tentative. +- "Built-in memory is a net negative" is Eugene's strong position, not a corpus consensus — [[allie-miller]]'s [[personal-ai-operating-system]] happily uses persistent context docs and never condemns the memory feature. The two are reconcilable (both prefer *authored* context to *inferred* context), but the blanket "better if it didn't exist" is one voice. Status: tentative. + +## Next Questions + +- ~~What's a starter skill set for a non-engineer?~~ Answered in [[2026-07-14-best-first-skill-for-beginner]] (skill-creator as meta-skill; tone-of-voice + anti-AI-language as first content skill). +- Do skills actually solve *cross-project* context, or only per-procedure recall? Larysa's complaint may be the former, which skills don't obviously address. diff --git a/wiki/concepts/solve-first-then-skillify.md b/wiki/concepts/solve-first-then-skillify.md new file mode 100644 index 0000000..953f8a3 --- /dev/null +++ b/wiki/concepts/solve-first-then-skillify.md @@ -0,0 +1,37 @@ +# Solve First, Then Skill-ify + +#concept + +## Summary + +The core method both HR interviews teach: **don't build a skill speculatively — solve the task with the AI once, correct it until the output is right, then say "now create a skill from this."** The skill freezes a *proven* workflow, not a guess about one. + +## Current Understanding + +The recurring beginner mistake is writing the skill first and then trying to "shove it somewhere." The working loop is: do your real task through the AI → watch the result → correct it → freeze the final state into a reusable skill. Two trigger heuristics exist in the corpus: + +- **Eugene:** turn any correction loop longer than **~3 messages** into a skill. +- **Konstantin:** auto-create a skill after **>5 tool calls** on a task (the [[hermes]] curator variant). + +The payoff goes beyond reuse: a packaged skill is a **handoff and de-risking asset** — "a person with not even a third of your HR experience can deliver a decent result," which cuts onboarding and lets the expert take a vacation. This is how [[skills-as-memory]] gets *populated* in practice — the method side of that architecture, and the fix for "don't teach the AI abstractly." + +## Evidence + +- "You first solve a task with Claude; the moment you reach the final solution, you say — now create a skill from this"; ~3-message heuristic — [[2026-07-14-yulia-interview]]. +- Do-the-task-then-freeze framing; skill-as-handoff to a junior hire; vacation/de-risking angle — [[2026-07-14-nina-interview]]. +- >5-tool-calls auto-creation heuristic and curator pruning — [[2026-07-14-skills-based-on-git]]. +- Skills prescribed specifically as the workaround for cross-session memory loss, and as the constraint on drift — [[2026-07-21-larysa-interview]]. + +## Related Pages + +- Concepts: [[skills-as-memory]] (the architecture this method feeds), [[levels-of-ai-usage]] (skills are the top practical rung), [[personal-ai-operating-system]], [[leave-less-room-for-imagination]] (why a *proven* spec beats a written-ahead one) +- Entities: [[eugene]], [[nina]], [[konstantin]], [[larysa]] + +## Contradictions / Uncertainty + +- Whether the resulting skill is personal IP or employer work product is unresolved (Eugene vs [[sebastian]]) — [[2026-07-14-nina-interview]]. + +## Next Questions + +- What does a good "create a skill from this" prompt look like — does the corpus contain a concrete example transcript? +- How do the ~3-message and >5-tool-call heuristics compare in practice; is one strictly better for non-programmers? diff --git a/wiki/concepts/think-wider-not-bigger.md b/wiki/concepts/think-wider-not-bigger.md new file mode 100644 index 0000000..cff5329 --- /dev/null +++ b/wiki/concepts/think-wider-not-bigger.md @@ -0,0 +1,31 @@ +# Think Wider, Not (Just) Bigger + +#concept + +## Summary + +Theo Browne's core reframe: you can't out-improve the models by "getting better" at your craft, so raise ambition instead — and specifically expand **breadth** (range of areas a product covers), not only **depth** (features per area). "If your idea doesn't feel stupid, it isn't big enough." + +## Current Understanding + +- **Match ambition to the model.** New models are qualitative eras (tool-call → long-running → orchestration; see [[ai-agent-evolution]]). You only feel the gain if the task *requires* the new capability. Work that made sense on the prior model won't feel different on the next. +- **The tier shift.** Every project category moved down one slot: yesterday's startup is today's side project; yesterday's "too big" (full-stack cloud) is today's startup; a new bottom tier appeared — **a markdown file** (see [[code-as-throwaway]]). The top ("too big") is genuinely open — train your own model? your own OS? compete with npm? +- **Breadth is now viable for small teams.** Old rule: pick a vertical, go deep (you can't out-breadth an incumbent). New rule: bolt a *serviceable* adjacent layer into your product in a day or two of prompting — cover enough that users can **start**, and be the right **shape** so users extend you (the **Slack effect**: it became everyone's agent platform not because it's good but because its shape invited extension). + +## Evidence + +- Eras, tier-shift table, breadth-vs-depth, Vercel-vs-AWS, Slack-as-accidental-platform, "pick an idea that feels stupid" — [[2026-07-14-everything-we-knew-about-software-has-changed]]. + +## Related Pages + +- Concepts: [[code-as-throwaway]], [[decoupling-identity-from-profession]], [[context-as-scarce-resource]] +- Entity: [[theo-browne]] +- Timeline: [[ai-agent-evolution]] + +## Contradictions / Uncertainty + +- "Bolt a database platform in a day or two" is an ambition claim; reliability parity with incumbents (RDS) is explicitly *not* promised. Status: tentative. + +## Next Questions + +- Which adjacent breadth layer is highest-leverage to add first for a given product? diff --git a/wiki/entities/.gitkeep b/wiki/entities/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/wiki/entities/allie-miller.md b/wiki/entities/allie-miller.md new file mode 100644 index 0000000..7caa064 --- /dev/null +++ b/wiki/entities/allie-miller.md @@ -0,0 +1,31 @@ +# Allie Miller + +#entity + +## Summary + +Ex-Amazon AI leader; advises OpenAI / Google / Anthropic and Fortune 500s. Popularizes the idea of a **[[personal-ai-operating-system]]** — persistent context, reusable skills, and proactive scheduled agents. + +## Current Understanding + +Allie's thesis is that the durable advantage is *infrastructure*, not prompting: build foundation context docs once, layer composable skills and scheduled workflows, and every new model release "slots into a system you already understand." She stresses mindset (agency + taste) over expertise. + +## Evidence + +- Interview "In 1 Year, the Gap… Will Be Irreversible": 3 foundation docs, 4 Claude surfaces, "just complain," proactive workflows, 4-tier model of AI work, trust calibration — [[2026-07-14-gap-between-ai-users-irreversible]]. +- Self-reported setup: 36 proactive workflows, ~28 master agents, ~100 total agents; 2–10× productivity. + +## Related Pages + +- Concepts: [[personal-ai-operating-system]], [[skills-as-memory]], [[context-as-scarce-resource]], [[connections-as-moat]] +- Tools: [[claude-code]] +- Compare: [[konstantin]] (same skills-as-memory idea, engineering framing), [[theo-browne]] +- Comparison: [[theo-konstantin-allie]] — three-lens side-by-side (Theo/Konstantin/Allie) + +## Contradictions / Uncertainty + +- Predicts near-term "self-learning models with real weight updates" — distinguished from today's memory-file retrieval. Forward-looking; Status: tentative. + +## Next Questions + +- Reusable templates for the Personal Constitution / Goals / Business Strategy docs? (Directly webinar-relevant.) diff --git a/wiki/entities/claude-code.md b/wiki/entities/claude-code.md new file mode 100644 index 0000000..49298d8 --- /dev/null +++ b/wiki/entities/claude-code.md @@ -0,0 +1,42 @@ +# Claude Code + +#entity + +## Summary + +Anthropic's agentic coding CLI/harness, cited across all four ingested sources as the reference [[harness]]. Used interactively and in fire-and-forget / scheduled modes. + +## Current Understanding + +Claude Code recurs as the concrete example of the "universal agent" pattern: a short system prompt, ~10–40 file/shell/search tools, a ReAct runtime loop, standardized key files (CLAUDE.md, `skills/`), and native scheduling. It supports both [[skills-as-memory|skills]] and MCP — and notably converts MCP servers *into* skills so their tools don't all hit context at once, erasing most MCP downsides ([[evolution-of-agent-tooling]]). + +**Practitioner limits** (from the [[2026-07-21-larysa-interview|Larysa interview]]) — the corpus's most critical first-hand read: + +- **Built-in memory is judged an anti-feature** by Eugene ("it'd be better if it didn't [exist]"); use skills instead. See [[skills-as-memory]]. +- **Connectors overpromise.** The agent begins work before establishing whether an integration is implemented or available for the user's account tier — see [[integration-dead-ends]]. Slack has first-class Anthropic support (paid seat required); Teams is treated as a dead end; Figma editing needs a paid account. +- **Model selection matters within the family.** Eugene runs **4.7** in production and avoids **4.8** as "too proactive." Code output is considered production-safe from ~**4.6** onward, excluding authorization and payments ([[code-as-throwaway]]). +- **Testing surface:** browser/web testing works; a mobile emulator got badly stuck. + +## Evidence + +- **Allie Miller:** one of "4 Claude surfaces" — the maximum-control one, with native scheduling — [[2026-07-14-gap-between-ai-users-irreversible]]. +- **Konstantin:** used (leaked) as a hackathon backend; example harness; turns MCP into skills — [[2026-07-14-skills-based-on-git]]. +- **Sebastian/Eugene:** Eugene's custom harness is built on Claude Code; solved the printer protocol in ~30 min on-site — [[2026-07-14-sebastian-eugene-interview]]. +- **Theo Browne:** markdown-file service piped to Codex/Claude on a cron — [[2026-07-14-everything-we-knew-about-software-has-changed]]. +- **Larysa/Eugene:** memory critique, connector dead-ends, 4.6/4.7/4.8 model selection, emulator failure — [[2026-07-21-larysa-interview]]. + +## Related Pages + +- Concepts: [[harness]], [[skills-as-memory]], [[agentic-loops]], [[context-as-scarce-resource]], [[integration-dead-ends]], [[leave-less-room-for-imagination]] +- Entities: [[eugene]], [[larysa]] +- Related tools: [[hermes]] (skills-first harness), Codex CLI, OpenClaude (a Claude Code fork), Cursor, Conductor + +## Contradictions / Uncertainty + +- Sources treat Claude Code as the harness baseline but disagree on governance: personal/custom (Eugene) vs company-managed at scale (Sebastian — see [[enterprise-ai-reality]]). +- Model-version judgements (4.7 good / 4.8 too proactive) are one practitioner's production preference at one point in time, not a benchmark, and will date quickly. Status: tentative. + +## Next Questions + +- What does a compliant, company-managed Claude Code deployment look like for regulated teams? +- Is there a supported way to make the agent check integration entitlements *before* starting a task? diff --git a/wiki/entities/eugene.md b/wiki/entities/eugene.md new file mode 100644 index 0000000..a944303 --- /dev/null +++ b/wiki/entities/eugene.md @@ -0,0 +1,39 @@ +# Eugene + +#entity + +## Summary + +Senior software engineer (20+ years, ~20 commercial; computer vision, embedded/firmware, Edge Compute/IoT at [[inspectron]]), content creator, and builder of a custom [[claude-code|Claude Code]] [[harness]]. Author and presenter of the webinar *"From a chat box to your own operating system"*; interviewer of [[sebastian]], [[nina]], [[yulia]], and [[larysa]]. Champions "bring your own harness" and building small AI tools for yourself. + +## Current Understanding + +Eugene argues every developer should build a personal harness because knowing every detail makes it far more effective; he demoed one (Telegram-like UI, one agent per project, inter-agent messaging, per-agent memory, "done thinking" signal). His stated unsolved problem — building a professional network — is what makes [[connections-as-moat]] the interview's emotional center; notably, in [[2026-07-14-yulia-interview]] he independently lands on the same residual ("the human's role is just to be human — introductions, communication"). + +Heavy Claude user on the **$200 max plan**; ran 7 project-agents in parallel; built the record→diarize→transcribe→summarize tool whose output *is* the two HR interview raws. Teaches [[levels-of-ai-usage]] and [[solve-first-then-skillify]] as the non-programmer curriculum. Predicts AI prices rise, not crash ("what I now buy for 200 will cost about 1,000"). A paid build of the HR candidate-base system for Yulia's team is on the table. + +**Positions sharpened in the [[2026-07-21-larysa-interview|Larysa interview]]:** built-in agent memory is an anti-feature, not an unfinished one ("it'd be better if it didn't [exist]") — [[skills-as-memory|skills]] replace it; consolidate into one workspace rather than tool-hopping ("my life just split into before and after"); [[leave-less-room-for-imagination|leave less room for imagination]], which is also his critique of build-a-whole-project-in-two-prompts demos. Runs **Claude 4.7** in production, avoiding 4.8 as "too proactive"; considers AI-written code production-safe from ~4.6 but withholds **authorization and payments**. Claims his diarization + role-inference pipeline is the real differentiator over plain GPT transcription, which "only guesses who spoke." + +**Likely identity:** Eugene appears to be the **owner/author of this vault** and of the webinar being prepared. Status: **tentative but strengthened** — both HR interviews name him as the webinar's author/presenter and the tool-builder; the raw `Ideas for webinar.md` notes share his references. + +## Evidence + +- Interview: BYO-harness demo, tools (Conductor for git-worktree isolation; references [[hermes]]), projects **insin** (apt-get-style edge updater) & **Keller**, the ~6-month networking blocker — [[2026-07-14-sebastian-eugene-interview]]. +- Webinar author/presenter, Inspectron, one-button interview tool, 7 parallel agents, English-first webinar titled *"From a chat box to your own operating system"* — [[2026-07-14-nina-interview]]. +- $200 max plan, levels ladder, solve-first method, price-rise prediction, paid HR-system offer, manager/subordinate framing — [[2026-07-14-yulia-interview]]. +- Memory-as-anti-feature, consolidation pitch, imagination/drift principle, 4.7-over-4.8, auth/payments carve-out, diarization+role-inference claim — [[2026-07-21-larysa-interview]]. + +## Related Pages + +- Entities: [[sebastian]], [[nina]], [[yulia]], [[larysa]] (interview counterparts), [[inspectron]] (employer), [[virtido]] (webinar audience) +- Concepts: [[harness]], [[connections-as-moat]], [[product-ownership]], [[decoupling-identity-from-profession]], [[levels-of-ai-usage]], [[solve-first-then-skillify]], [[leave-less-room-for-imagination]], [[integration-dead-ends]] +- Tools: [[claude-code]], [[hermes]] + +## Contradictions / Uncertainty + +- Disagrees with Sebastian: BYO-harness vs company-managed; OSS as marketing vs growth; LinkedIn/content vs in-person networking. +- Vault-owner identity is inferred; confirm before treating as fact. + +## Next Questions + +- Concretely, how does Eugene build a connections network from a standing start? (The interview's biggest open question.) diff --git a/wiki/entities/hermes.md b/wiki/entities/hermes.md new file mode 100644 index 0000000..041397e --- /dev/null +++ b/wiki/entities/hermes.md @@ -0,0 +1,30 @@ +# Hermes + +#entity + +## Summary + +An AI agent [[harness]] built **entirely around [[skills-as-memory|skills]]** — it not only uses skills but creates and curates them autonomously. Central to [[konstantin]]'s talk; also referenced by [[eugene]] among his tools. + +## Current Understanding + +Hermes is the concrete demonstration of "skills as memory": it auto-creates a skill when a task costs >5 tool calls, and runs a two-layer **curator** — pruning skills unused for 30 days (deactivate) / 90 days (archive) and consolidating small skills weekly so their short-descriptions don't eat context. Konstantin reports it grew from 56 → 100 skills and kept working — impossible with classic tools. + +## Evidence + +- Konstantin's talk: auto-improvement mechanism, curator, Telegram access to shared git skills — [[2026-07-14-skills-based-on-git]]. +- Eugene lists it among his harness tools ("open clock, Hermes, paperclip") — [[2026-07-14-sebastian-eugene-interview]]. + +## Related Pages + +- Entity: [[konstantin]], [[eugene]] +- Concepts: [[skills-as-memory]], [[harness]], [[agentic-loops]], [[context-as-scarce-resource]] +- Related tools: [[claude-code]], OpenClaude, Codex CLI + +## Contradictions / Uncertainty + +- The curator thresholds are Hermes-specific heuristics, not validated standards. Status: tentative. + +## Next Questions + +- How do Hermes' auto-consolidation decisions avoid merging skills that should stay distinct? diff --git a/wiki/entities/inspectron.md b/wiki/entities/inspectron.md new file mode 100644 index 0000000..d47bd35 --- /dev/null +++ b/wiki/entities/inspectron.md @@ -0,0 +1,28 @@ +# Inspectron + +#entity + +## Summary + +The company where [[eugene]] works as a senior software engineer (Edge Compute / IoT). Appears in the corpus only as background context for Eugene's day job, distinct from his webinar/AI-tooling work with the [[virtido]] HR team. + +## Current Understanding + +Both HR interviews identify Eugene as working "at Inspectron" / "on Inspectron and its clients" with ~20 years of commercial experience. No further detail about the company itself is in the corpus. + +## Evidence + +- Eugene described as senior engineer at Inspectron, Edge Compute / IoT — [[2026-07-14-nina-interview]]. +- "Works on Inspectron and its clients" — [[2026-07-14-yulia-interview]]. + +## Related Pages + +- Entities: [[eugene]], [[virtido]] (the other company in the corpus) + +## Contradictions / Uncertainty + +- Nina's summary frames it as employment ("works at"); Yulia's as project work ("works on Inspectron and its clients"). Employment vs contracting is unclear. Status: tentative. + +## Next Questions + +- Is Eugene an employee or contractor? Does Inspectron relate to his **insin** edge-updater project (mentioned in [[2026-07-14-sebastian-eugene-interview]])? diff --git a/wiki/entities/konstantin.md b/wiki/entities/konstantin.md new file mode 100644 index 0000000..df8b893 --- /dev/null +++ b/wiki/entities/konstantin.md @@ -0,0 +1,33 @@ +# Konstantin (Sber / GigaChat) + +#entity + +## Summary + +Engineer on Sber's GigaChat development team, doing R&D on agents. Author of the talk arguing that **git-based [[skills-as-memory|skills]] are the new memory of AI agents**. + +## Current Understanding + +Konstantin brings the model-builder's / R&D lens. His core architectural claim: put tools + data + usage history in one git repo and let the [[harness]] decide what to load. He maps the field's evolution (tools → MCP → skills, then [[agentic-loops|agent loops]]) and demonstrates auto-improvement (a weak GigaChat going 1/89 → 11/89 on a benchmark over a weekend). + +## Evidence + +- Talk "Git-based skills — the new memory of AI agents": harness definition, two-stage skill loading, git rules + CI back-pressure, personal DNA/trip/HR skills, Hermes curator, Ralph/meta loops — [[2026-07-14-skills-based-on-git]]. +- Hackathon record: 7th (Interpress-Ex, infinite-loop harness), 3rd/1st-technical (Snowbase), observed 19/20 top BitGen teams on harnesses. + +## Related Pages + +- Concepts: [[skills-as-memory]], [[harness]], [[evolution-of-agent-tooling]], [[agentic-loops]], [[context-as-scarce-resource]] +- Tools: [[hermes]] (skills-first harness he uses/extends), [[claude-code]] +- Timeline: [[ai-agent-evolution]] +- Compare: [[allie-miller]] (same skills-as-memory idea, business framing), [[theo-browne]] (orchestration era) +- Comparison: [[theo-konstantin-allie]] — three-lens side-by-side (Theo/Konstantin/Allie) + +## Contradictions / Uncertainty + +- Pruning windows (30/90 days) and the ">5 tool calls → make a skill" rule are presented as working heuristics from Hermes, not established standards. Status: tentative. +- No standards yet for what data to put in a skill or its upper size limit. + +## Next Questions + +- How to build world-models / give agents perception (his own "missing piece")? diff --git a/wiki/entities/larysa.md b/wiki/entities/larysa.md new file mode 100644 index 0000000..e06bae9 --- /dev/null +++ b/wiki/entities/larysa.md @@ -0,0 +1,39 @@ +# Larysa + +#entity + +## Summary + +Technical business analyst / project manager and former mobile developer; interviewed by [[eugene]] as the **project-management** voice in the webinar-scoping series (alongside [[nina]] and [[yulia]]). The most technically deep non-engineer in the corpus — and the one whose frustrations are most structural. + +## Current Understanding + +Larysa is a power user by any reasonable measure: she opens pull requests, wires Claude to **ClickUp** (a Jira analog) and **Figma**, builds clickable prototypes, and writes user stories and tests. She is enthusiastic but worn down — not by wrong answers, but by two failure modes that cost her time and tokens: + +1. **No memory between sessions.** She explains something one day; the next day it is gone and she re-pays for the explanation. This is her stated core problem. +2. **[[integration-dead-ends|Integrations that dead-end]].** Claude confidently starts a task, then discovers the connector isn't implemented or isn't available for her *private* (vs. corporate) account — half an hour in. "I don't know how to fight this." + +Her blocked builds are instructive: a Teams bot that would watch a work chat and auto-create ClickUp tasks (Teams offers no usable external API); Slack (first-class Claude support, but needs a paid seat she isn't given); full editable Figma access (needs a personal paid account). + +Diagnostically she sits **high on [[levels-of-ai-usage]]** — well past chatbot, acting on real files and systems — but without the [[skills-as-memory|skills]] rung, which is exactly why her pain reads as "the agent forgot." Skills are the one topic Eugene committed to covering for her in the webinar. + +## Evidence + +- Role, tooling (ClickUp/Figma/PRs/prototypes/user stories/tests), memory complaint, integration dead-ends, Teams/Slack/Figma blockers, emulator-vs-browser testing note — [[2026-07-21-larysa-interview]]. +- Flagged twice as an un-interviewed gap before this ingest — [[2026-07-14-nina-interview]], [[2026-07-14-yulia-interview]]. + +## Related Pages + +- Entities: [[eugene]] (interviewer), [[nina]], [[yulia]] (same interview series), [[virtido]] (affiliation tentative), [[claude-code]] +- Concepts: [[integration-dead-ends]], [[skills-as-memory]], [[leave-less-room-for-imagination]], [[levels-of-ai-usage]], [[solve-first-then-skillify]] + +## Contradictions / Uncertainty + +- Name is taken from the raw filename and the summary's speaker label; spelled "Larisa" in earlier notes. Status: tentative. +- Employer never stated; [[virtido]] inferred from the shared interview series. Status: tentative. + +## Next Questions + +- Does the skills rung actually resolve her memory complaint, or is her problem cross-*project* context (which skills don't solve)? +- Would her employer supply the paid Slack/Figma seats if a working prototype existed — i.e. is the blocker technical or budgetary? +- What was her BA/PM pain point in [[yulia]]'s original three-item list, and does it match what surfaced here? diff --git a/wiki/entities/nina.md b/wiki/entities/nina.md new file mode 100644 index 0000000..0a15d37 --- /dev/null +++ b/wiki/entities/nina.md @@ -0,0 +1,30 @@ +# Nina + +#entity + +## Summary + +HR recruiter at [[virtido]]; among the most AI-forward recruiters on her team. Interviewed by [[eugene]] as a webinar-audience proxy — she supplies the concrete HR use cases (job descriptions, interview write-ups, candidate sourcing) that validate the webinar thesis. Also an ultra-trail runner (50+ km). + +## Current Understanding + +Nina is the enthusiastic practical adopter: uses paid ChatGPT, LinkedIn Recruiter, and Manatal (ATS). Her biggest pain is interview write-ups — note-taking during a call wrecks the conversation, so automatic transcription is the part that actually changes her work ("this transcript is honestly the most important thing"). She estimates going from ~5 to ~25 candidates/day with Eugene's tooling, but values the **cognitive-load reduction** more than the throughput. Her read on colleagues: they aren't resistant, they lack a frictionless path — "they'd use it if it just transcribed everything for them." + +## Evidence + +- Pain points, transcript-over-summary, friction-not-resistance, multiplier framing, 5→25 estimate — [[2026-07-14-nina-interview]]. +- Referenced as a budget-approver contact in [[2026-07-14-yulia-interview]]. + +## Related Pages + +- Entities: [[eugene]] (interviewer), [[yulia]] (team colleague/lead), [[virtido]] +- Concepts: [[solve-first-then-skillify]], [[skills-as-memory]], [[levels-of-ai-usage]] + +## Contradictions / Uncertainty + +- None recorded; her account is first-hand and consistent with Yulia's. + +## Next Questions + +- Would her team actually adopt the transcribe→summarize tool if delivered — and can it integrate with Manatal? +- Multilingual output (EN/DE/UK) was flagged as an unlock — which languages dominate her candidate pool? diff --git a/wiki/entities/sebastian.md b/wiki/entities/sebastian.md new file mode 100644 index 0000000..51db60d --- /dev/null +++ b/wiki/entities/sebastian.md @@ -0,0 +1,30 @@ +# Sebastian + +#entity + +## Summary + +Founder/owner of [[virtido|Virtido]], a ~11-year software outsourcing/engineering company. Interviewed by [[eugene]]. Brings the services-business, client, compliance, and sales lens to how AI reshapes engineering. + +## Current Understanding + +Sebastian agrees AI can write software and that teams collapse to 2–3 people, but his signature contribution is the **enterprise counterpoint**: [[harness|"bring your own harness"]] cannot survive compliance, so a company-managed standard harness is "the interesting market" ([[enterprise-ai-reality]]). His other durable claims: seniors gain / juniors lose ([[seniority-and-the-junior-squeeze]]), and **[[connections-as-moat|in-person relationships are the last non-commoditized asset]]**. + +## Evidence + +- Interview: team collapse, enterprise lock-down (Roche ~1,200 engineers; banks), printer anecdote, profile-picture ownership story, "Big zero" on digital outreach — [[2026-07-14-sebastian-eugene-interview]]. +- Reports enterprise clients on centrally-managed VMs with zero self-install. + +## Related Pages + +- Entity: [[eugene]] (interviewer, counterpart), [[virtido]] +- Concepts: [[harness]], [[enterprise-ai-reality]], [[seniority-and-the-junior-squeeze]], [[product-ownership]], [[connections-as-moat]], [[decoupling-identity-from-profession]], [[code-as-throwaway]] + +## Contradictions / Uncertainty + +- Disagrees with **Eugene** on harness (BYO vs company-managed), on OSS motivation (marketing vs "more OSS as code gets free"), and on networking channels (online vs in-person). +- Disagrees with colleague **Daniel** on returning to waterfall planning. + +## Next Questions + +- How does AI transform ~1,200-engineer, multi-year enterprise programs? (He says he doesn't know.) diff --git a/wiki/entities/theo-browne.md b/wiki/entities/theo-browne.md new file mode 100644 index 0000000..eb7c162 --- /dev/null +++ b/wiki/entities/theo-browne.md @@ -0,0 +1,36 @@ +# Theo Browne (t3.gg) + +#entity + +## Summary + +Developer, educator, and founder (t3.gg / "Ping"); speaker at AIE. Advocates that engineers must radically expand ambition to keep pace with model progress. + +## Current Understanding + +Theo's argument is psychological as much as technical: senior engineers underuse frontier models because they scope work to what the *previous* model could do. His prescription — **[[think-wider-not-bigger|think wider]]**, shed developer-identity baggage, treat code as disposable — frames the "models aren't that useful for me" complaint as a scoping problem on the human's side. + +His second source in the vault sharpens the disposable-code stance into a discipline: **[[make-more-cheap-code]]** — keep hand-verification of shipped code intact (he explicitly rejects shipping unreviewed slop: "I hate them too. We're on the same side") while generating orders of magnitude more never-shipped code for verification and exploration. Recurring author-move across both talks: locate the bottleneck in a *human habit* (scoping, reading ratios), not in the models. + +## Evidence + +- Talk "Everything we knew about software has changed" (AIE): model eras, tier shift, breadth-vs-depth, G-brain markdown tier — [[2026-07-14-everything-we-knew-about-software-has-changed]]. +- Video "You're reading way too much code": four tiers of code, ship/no-ship line, 100:1 slop-to-ship verification ratio, dumb-model agents as API usability testers — [[2026-07-24-youre-reading-way-too-much-code]]. Mentions his current project **Lakebed** (reads every signature/API there, verifies with slop). +- Built "Ping" (YC — "Zoom for streamers"), which he uses as the "startup → now a side project" example. +- Replaced a PR-triage service with a markdown file on a 9 AM cron (Codex/Claude → S3). + +## Related Pages + +- Concepts: [[think-wider-not-bigger]], [[code-as-throwaway]], [[make-more-cheap-code]], [[decoupling-identity-from-profession]] +- Timeline: [[ai-agent-evolution]] +- Compare: [[konstantin]] (model-builder's orchestration view), [[allie-miller]] (personal-OS view) +- Comparison: [[theo-konstantin-allie]] — three-lens side-by-side (Theo/Konstantin/Allie) + +## Contradictions / Uncertainty + +- His model-era names ("Sonnet 3.5", "Opus 4.5", "Mythos/Fable") are rhetorical framing; mapping to shipped model IDs is unverified. Status: tentative. +- His read/write/merge counts (1,000/2,000+/~500 per day) are self-reported illustrations, not measurements. Status: tentative. + +## Next Questions + +- What does *he* now consider "too big"? (He says he no longer knows.) diff --git a/wiki/entities/virtido.md b/wiki/entities/virtido.md new file mode 100644 index 0000000..0329048 --- /dev/null +++ b/wiki/entities/virtido.md @@ -0,0 +1,36 @@ +# Virtido + +#entity + +## Summary + +A ~11-year-old software outsourcing/engineering company founded and owned by [[sebastian]]. Provides the enterprise/services vantage point in the [[2026-07-14-sebastian-eugene-interview|Sebastian interview]]. + +## Current Understanding + +Virtido works with large, often regulated enterprise clients — the setting for Sebastian's claims about compliance-locked environments and the company-managed-harness market ([[enterprise-ai-reality]]). Team sizes cited: 10–15 engineers on big teams, collapsing toward 2–3 with AI. + +Its **HR/recruiting team is the audience for Eugene's webinar**: [[nina]] (recruiter) and [[yulia]] (recruiting lead, affiliation tentative) supplied the concrete pain points — job descriptions, interview write-ups, candidate sourcing — that collapse into "a candidate knowledge base plus search over it." Tooling in use: LinkedIn Recruiter, Manatal (ATS), paid ChatGPT (some team members). + +The audience is not only HR: [[larysa]] (technical BA/PM, affiliation tentative) is the third interviewee in the same scoping series, and she extends the tooling picture to **ClickUp** (Jira analog), **Figma**, **Teams** and **Slack** — with the last three blocked by paid-seat or API limits ([[integration-dead-ends]]). Her account also shows the seat-provisioning question is live: Anthropic supports Slack first-class, but she isn't given a seat. + +## Evidence + +- Interview: 11 years in business, enterprise clients, centrally-managed VMs; playful `humans.verti.com` / LinkedIn "human badge" riff on human differentiation — [[2026-07-14-sebastian-eugene-interview]]. +- HR pain points, team tooling, adoption-friction observation — [[2026-07-14-nina-interview]]. +- Candidate-base conclusion, budget approvers (Nina, Sergiy, "Andryuk"), paid-build discussion — [[2026-07-14-yulia-interview]]. +- BA/PM tooling (ClickUp, Figma) and paid-seat blockers — [[2026-07-21-larysa-interview]]. + +## Related Pages + +- Entities: [[sebastian]] (founder), [[nina]], [[yulia]], [[larysa]], [[eugene]] (webinar presenter) +- Concepts: [[enterprise-ai-reality]], [[connections-as-moat]], [[seniority-and-the-junior-squeeze]], [[levels-of-ai-usage]] + +## Contradictions / Uncertainty + +- Client names are largely illustrative (e.g. Roche cited as an industry reference point, not necessarily a Virtido client). +- [[larysa]]'s employer is never stated; membership is inferred from the shared interview series. Status: tentative. + +## Next Questions + +- Is Virtido itself building/selling a company-managed harness product, or just identifying the market? diff --git a/wiki/entities/yulia.md b/wiki/entities/yulia.md new file mode 100644 index 0000000..e64da5a --- /dev/null +++ b/wiki/entities/yulia.md @@ -0,0 +1,31 @@ +# Yulia + +#entity + +## Summary + +HR/recruiting lead (name inferred from the raw filename, Status: tentative) who brought her team's AI pain points to [[eugene]] and is organizing the webinar on the company side. Self-described beginner; the demand-side counterpart to [[nina]]'s practitioner view. + +## Current Understanding + +Yulia collected three team pain points and got the conclusion that the two recruiting ones collapse into a single build: a **candidate knowledge base** (record interviews → auto-transcribe → standardized profiles) plus search over it. She controls the process socially — refers to Nina, Sergiy and "Andryuk" as budget approvers — and was explicit there is **no deadline** for the webinar plan. A paid build of the HR system by Eugene is on the table. + +## Evidence + +- Pain points, candidate-base conclusion, webinar organization, budget approvers, no-deadline stance — [[2026-07-14-yulia-interview]]. + +## Related Pages + +- Entities: [[eugene]], [[nina]], [[larysa]] (third interviewee in the series she organized), [[virtido]] (affiliation tentative — inferred from shared team with Nina) +- Concepts: [[levels-of-ai-usage]], [[solve-first-then-skillify]] + +## Contradictions / Uncertainty + +- Speaker name is inferred from the filename "Yulia interview.md"; the transcript summary never names SPEAKER_00. Status: tentative. +- Her employer is not stated; Virtido is inferred from the shared team with Nina. Status: tentative. + +## Next Questions + +- Confirm name and affiliation. +- What was the third team pain point (beyond the two recruiting ones)? **Partially answered:** [[larysa]] has now been interviewed ([[2026-07-21-larysa-interview]]) and her pain points are agent memory loss and [[integration-dead-ends]] — but whether these are the same item Yulia had in her original three-point list is unconfirmed. +- Webinar structure and scheduling were deferred back to her at the end of the Larysa interview — still open. diff --git a/wiki/lint-reports/.gitkeep b/wiki/lint-reports/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/wiki/overview.md b/wiki/overview.md new file mode 100644 index 0000000..a069ea9 --- /dev/null +++ b/wiki/overview.md @@ -0,0 +1,46 @@ +# Overview + +#overview + +Top-level synthesis and navigation for this vault. See [[index]] for the full content catalog. + +## Purpose + +A high-signal personal knowledge base. `raw/` holds immutable source materials; `wiki/` holds LLM-authored, continuously maintained pages. The current corpus is **webinar-prep material on how AI is reshaping software engineering**, likely authored by [[eugene]] (Status: tentative). + +## The through-line + +Across nine sources — three talks/videos (two of them Theo's), five interviews, and a business-facing short — one spine recurs: + +> **As the cost of writing code goes to zero, value migrates from *producing* software to *directing and verifying* it — and the durable human assets become judgment, ownership, taste, and in-person relationships.** + +Everything else hangs off that: + +- **The machine side** — how the work gets done now: the [[harness]] (universal agent + small toolset + loop), [[skills-as-memory|skills as the new memory]], the tooling progression [[evolution-of-agent-tooling|tools → MCP → skills]], and [[agentic-loops|inner/outer/meta loops]] — all governed by [[context-as-scarce-resource|context as the scarce resource]]. The non-engineer's version is Allie's [[personal-ai-operating-system]]. +- **The human side** — what stays yours: [[product-ownership]] over outcomes, [[connections-as-moat|in-person connections]] as the last non-commoditized asset, [[seniority-and-the-junior-squeeze|judgment as risk-reduction]], and the need to [[decoupling-identity-from-profession|decouple identity from profession]]. +- **The strategy side** — where to point it: [[think-wider-not-bigger|think wider not bigger]], treat [[code-as-throwaway|code as throwaway]], and mind [[enterprise-ai-reality|enterprise compliance reality]] (the company-managed-harness market). Theo's second video supplies the *verifying* half of the spine its method: [[make-more-cheap-code]] — keep hand-verification of what ships, and generate orders of magnitude more never-shipped code to verify and explore. +- **The demand side** — three interviews ground it all in a real audience. The two HR ones ([[2026-07-14-nina-interview|Nina]], [[2026-07-14-yulia-interview|Yulia]]) supply pain points (interview write-ups, job descriptions, sourcing) that collapse into "a candidate knowledge base plus search," teachable via [[levels-of-ai-usage]] and [[solve-first-then-skillify]]. Their key finding: **adoption is blocked by friction, not resistance.** The [[2026-07-21-larysa-interview|Larysa interview]] adds the *advanced* user's version of the same story: past the friction, the remaining walls are structural — no durable memory, [[integration-dead-ends|integrations that dead-end]], and drift on loose specs ([[leave-less-room-for-imagination]]). Her diagnosis matters because she is technically deep yet skipped the skills rung, which is exactly what her "the agent forgot" complaint reduces to. + +See [[ai-agent-evolution]] for how the capability curve got here. + +## Where sources agree vs diverge + +- **Agree:** code is cheap/disposable; harnesses are the unit of work; skills-as-memory (Konstantin ↔ Allie ↔ Eugene); human relationships rise in value (Sebastian ↔ Allie ↔ Eugene, who lands there independently in the Yulia interview); solve-first-then-skillify (Eugene ↔ Konstantin's heuristics); context is the constraint. The [[2026-07-22-ai-is-stupid|"AI is stupid!" short]] independently compresses the machine-side spine into a business one-liner: **model + context + harness = employee-level answer**. +- **Diverge:** personal vs company-managed harness ([[eugene]] vs [[sebastian]]); online vs in-person networking (same pair); OSS as marketing vs OSS growth; built-in agent memory as anti-feature (Eugene) vs persistent context docs used without complaint (Allie); tight specs ([[leave-less-room-for-imagination]]) vs wide latitude ([[think-wider-not-bigger]]); agent diff-summaries as sufficient review (Theo/Dax) vs invisible drift as the core danger (Eugene). These live under "Contradictions" on the relevant pages. + +## Navigation + +- **[[index]]** — content catalog +- **Sources (9):** [[2026-07-14-everything-we-knew-about-software-has-changed|Theo Browne]] · [[2026-07-14-gap-between-ai-users-irreversible|Allie Miller]] · [[2026-07-14-sebastian-eugene-interview|Sebastian interview]] · [[2026-07-14-skills-based-on-git|Konstantin (git skills)]] · [[2026-07-14-nina-interview|Nina interview]] · [[2026-07-14-yulia-interview|Yulia interview]] · [[2026-07-21-larysa-interview|Larysa interview]] · [[2026-07-22-ai-is-stupid|"AI is stupid!" short]] · [[2026-07-24-youre-reading-way-too-much-code|Theo Browne (reading code)]] +- **People:** [[theo-browne]] · [[allie-miller]] · [[sebastian]] · [[eugene]] · [[konstantin]] · [[nina]] · [[yulia]] · [[larysa]] +- **Tools/orgs:** [[claude-code]] · [[hermes]] · [[virtido]] · [[inspectron]] +- **Concepts:** see the through-line above (18 pages) · **Timeline:** [[ai-agent-evolution]] + +## Open Questions (vault-level) + +- How does an individual build a professional network from a standing start? (Cross-source; the emotional center of the Sebastian interview.) — Tentative protocol drafted at [[network-from-a-standing-start]]; validation instrument at [[2026-07-14-network-from-standing-start]]. +- Reusable templates for Allie's 3 foundation docs — a concrete webinar deliverable? +- Should "Ideas for webinar", "HR Contacts", "Webinar Plan" and "Webinar script" be ingested next to connect the corpus to the actual webinar deliverable? (Currently raw-only, per user's ingest scope.) +- Can the transcribe→summarize tool integrate with Manatal (the HR team's ATS)? And is a paid HR-system build going ahead? (Both open from the HR interviews.) +- How should a user pre-empt [[integration-dead-ends|integrations that aren't available for their account]]? Both participants in the Larysa interview left this explicitly unsolved — the corpus's only wholly unanswered *technical* problem. +- Does the skills rung actually fix cross-*session* and cross-*project* memory, or only per-procedure recall? The webinar's central promise rests on this. diff --git a/wiki/queries/.gitkeep b/wiki/queries/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/wiki/queries/2026-07-14-best-first-skill-for-beginner.md b/wiki/queries/2026-07-14-best-first-skill-for-beginner.md new file mode 100644 index 0000000..8e35e52 --- /dev/null +++ b/wiki/queries/2026-07-14-best-first-skill-for-beginner.md @@ -0,0 +1,35 @@ +# Best First Claude Skill for a Beginner + +#query + +## Question + +What would be the best Claude skill to give to a Claude beginner user? + +## Answer + +The corpus converges on a two-part answer: + +1. **The single best skill is a skill-*making* skill** — the built-in **skill-creator** (or Allie Miller's "just complain" pattern, where rambling frustration is turned into proposed skills). It is the only skill that compounds: instead of one capability, the beginner gets the habit of converting every repeated annoyance into a reusable folder-of-markdown. Konstantin's engineering version is the same idea as an automatic heuristic: *if a task took >5 tool calls, create a skill from it*. For someone who doesn't yet know what skills they need, the meta-skill bootstraps all the rest. + +2. **The best first *content* skill is a tone-of-voice / anti-AI-language skill.** Allie's starter set for non-engineers is tone-of-voice + brand-guidelines + anti-AI-language. It wins as a first skill because the payoff is immediate and visible (every output stops sounding like AI), it requires no technical setup — just examples of the user's own writing — and it demonstrates composition (a LinkedIn-voice skill *calling* the anti-AI-language skill), which teaches how skills work. + +**One important caveat from the same source:** Allie's ordering puts skills *second*. The first hour of a beginner's investment should go to the three foundation context documents (Personal Constitution, Goals, Core Business Strategy), created by letting Claude interview you — that alone moves outputs from generic to ~50% "your zone." A tone skill layered on top of those docs is far more effective than either alone. See [[personal-ai-operating-system]]. + +**Why skills at all (vs. tools/MCP) for a beginner:** skills are authored in plain text in any language, need no developer, load only when relevant (no context blowout), and port across Claude / Perplexity / Gemini — "just folders with markdown." See [[evolution-of-agent-tooling]]. + +## Evidence Trail + +- Starter skill set (tone-of-voice, brand-guidelines, anti-AI-language), built-in skill-creator, "just complain," composition example, foundation-docs-first ordering — [[2026-07-14-gap-between-ai-users-irreversible]] +- ">5 tool calls → create a skill" auto-creation heuristic; skills as agent memory; two-stage loading — [[2026-07-14-skills-based-on-git]], [[skills-as-memory]] +- Skills vs tools vs MCP trade-offs (no developer needed, no context blowout, portable) — [[evolution-of-agent-tooling]] + +## Follow-up Questions + +- What does a good tone-of-voice `SKILL.md` actually contain — how many writing samples are enough? +- Reusable templates for the three foundation docs (already an open question on [[personal-ai-operating-system]]). + +## Changed Existing Pages + +- [[skills-as-memory]] — its "Next Questions" item on a starter skill set for non-engineers is now answered here; link added. +- `index.md`, `log.md` updated. diff --git a/wiki/queries/2026-07-14-network-from-standing-start.md b/wiki/queries/2026-07-14-network-from-standing-start.md new file mode 100644 index 0000000..ed0d7b2 --- /dev/null +++ b/wiki/queries/2026-07-14-network-from-standing-start.md @@ -0,0 +1,55 @@ +# How Does an Individual Build a Network From a Standing Start? + +#query + +## Question Asked + +"How does an individual actually build a network from a standing start?" — the vault-level open question left unresolved by the Sebastian interview (principles offered, mechanics missing), and Eugene's own ~6-month blocker. + +## Answer + +The corpus cannot answer it yet, so this query produces two artifacts instead of a synthesis: + +1. **A tentative protocol** distilled from existing fragments — now at [[network-from-a-standing-start]] (pick recurring venues → sustainable cadence → lead with humanness → engineer second meetings in different circumstances → track second meetings, not contacts → let referrals replace outreach). Marked tentative throughout. +2. **A follow-up interview instrument for Sebastian** (below) — designed to extract *biographical mechanics* rather than principles, because people give principles when asked abstractly and mechanics when asked about their own past. + +### Interview instrument: Sebastian, round 2 + +**A. The bootstrap (tests whether a standing start ever existed)** + +1. Walk me through Virtido's first year. Where did clients #1, #2, #3 actually come from — the specific chain of introductions, person by person? +2. Before Virtido: what network did you inherit from prior jobs or study? How much of year-one business traces back to it? +3. If the inherited network was the seed — what would you have done without it? + +**B. The mechanics (turns principles into steps)** + +4. Month one, week one: what did you literally do? Which events, how did you find them, how did you choose? +5. First conversations with strangers: what did you lead with? What approaches failed? +6. The second-meeting mechanic — do you deliberately re-attend venues to re-meet the same people, or does it happen by accident? +7. Rough funnel numbers for year one: events attended → real conversations → second meetings → clients. How long until the first referral arrived? + +**C. The falsification (tests "Big zero" and the protocol)** + +8. What did you try that failed *before* concluding online outreach is a "Big zero"? Did LinkedIn/content/email ever produce even one client? +9. Dropped in a new city today, zero contacts: what exactly would you do in the first 90 days? +10. Eugene isn't selling a company — he's an employed engineer building individual reputation. What's his equivalent of your business lunches, and what's the minimum viable cadence (your 2–4 days/week is a full sales motion)? + +### Complementary route (not yet run) + +Outside literature via deep research — weak-ties research (Granovetter), mere-exposure effects behind the second-meeting mechanic, and practitioner from-zero playbooks — scoped to *exclude* content marketing and cold outreach so it tests Sebastian's "Big zero" claim rather than ignoring it. Available on request; its output would ingest as a normal source. + +## Evidence Trail + +- Principles-without-mechanics gap, "Big zero", second-meeting mechanics — [[2026-07-14-sebastian-eugene-interview]] +- Eugene's ~6-month blocker and online-tactics disagreement — [[connections-as-moat]], [[eugene]] +- The live experiment framing (webinar as repeated exposure) — [[2026-07-14-nina-interview]], [[2026-07-14-yulia-interview]] + +## Follow-up Questions + +- Run the round-2 interview (Eugene's existing record→transcribe pipeline makes it a free new source). +- Decide whether to run the deep-research complement. +- Track the webinar → paid-HR-build chain as the protocol's first case study. + +## Did This Change Existing Pages? + +Yes — created [[network-from-a-standing-start]] (concept); updated [[connections-as-moat]] (open question now has a protocol + validation plan), [[overview]] (vault-level open question annotated), `index.md`, `log.md`. diff --git a/wiki/queries/2026-07-22-webinar-theses.md b/wiki/queries/2026-07-22-webinar-theses.md new file mode 100644 index 0000000..3107aa6 --- /dev/null +++ b/wiki/queries/2026-07-22-webinar-theses.md @@ -0,0 +1,59 @@ +# Webinar Theses — From Chat Box to Your Own Agentic OS + +#query + +## Question + +"I need to make some theses for the webinar (theme: 'from chatbox to your own agentic operating system'). What theses can I suggest based on what you already have?" (2026-07-22) + +## Answer — candidate theses + +Grouped by the role they play in the talk. Each thesis is one sentence you could put on a slide; the sub-line is the grounding. + +### The spine (what the talk claims) + +1. **The model isn't the product — the harness is.** Same model at every level of the demo; only the harness around it grows. The journey from chat box to OS is a journey of *harness*, not intelligence. — [[harness]], Webinar script closing arc +2. **A chat box is an app you open; an OS is a system that runs around you.** The perspective shift is stranger → doer → yours → teammate → knows-you → always-on. — Webinar Plan through-line +3. **Skills are the new memory.** A folder plus a plain-text note — no code — is how the assistant stops being stateless and starts sounding like you. — [[skills-as-memory]] (Konstantin ↔ Allie ↔ Eugene convergence) +4. **Context is the scarce resource.** Every capability rung (tools → memory → skills → processes) is really a technique for spending limited context wisely. — [[context-as-scarce-resource]], [[evolution-of-agent-tooling]] +5. **You don't buy your OS — you build it, one small tool at a time.** Tools made for exactly one person, in an evening, asked-for rather than written. — Webinar script (OS section), [[personal-ai-operating-system]] + +### The stakes (why now) + +6. **The cost of producing work is going to zero; value migrates to directing and verifying it.** Judgment, ownership, taste, and relationships are what stay yours. — vault through-line ([[code-as-throwaway]], [[product-ownership]]) +7. **The gap between AI users and everyone else compounds — and is becoming irreversible.** The person who builds their OS this week fears no release, because each new capability slots into a system that already knows them. — [[2026-07-14-gap-between-ai-users-irreversible|Allie Miller]] +8. **The more the world is mediated by AI proxies, the more valuable real human connection becomes.** The "market of one" raises, not lowers, the price of being human. — [[connections-as-moat]] (Sebastian ↔ Allie ↔ Eugene) + +### The obstacles (what the audience actually hits) + +9. **Adoption is blocked by friction, not resistance.** People aren't against AI — the setup is. Remove three clicks and they come. — [[2026-07-14-nina-interview|Nina]], [[2026-07-14-yulia-interview|Yulia]] +10. **Even advanced users hit structural walls: no durable memory, integrations that dead-end, drift on loose specs.** The skills rung is the corpus's answer to the first and third. — [[2026-07-21-larysa-interview|Larysa]], [[integration-dead-ends]] +11. **Leave less room for imagination.** Every gap in your instructions gets filled — invisibly. Tight specs and frozen skills are how you keep the agent honest. — [[leave-less-room-for-imagination]] + +### The method (what to do) + +12. **Solve first, then skillify.** Don't design abstractions up front — solve the task once in conversation, then freeze the working recipe into a skill (~3 messages or >5 tool calls = it's skill time). — [[solve-first-then-skillify]] +13. **The assistant does the research; you do the judgment.** The Insights Collector meta-punchline: this very talk was mined out of AI-processed interview notes. — Webinar Plan §3, [[2026-07-14-sebastian-eugene-interview]] +14. **Walk in a week what took the industry three years.** One hour for foundation docs, one skill from your #1 recurring annoyance, one real file in Claude Desktop tonight. — Webinar Plan §5, [[levels-of-ai-usage]] + +### Honest tensions (if you want a "debates" slide or Q&A ammo) + +- Personal harness (Eugene) vs company-managed harness (Sebastian) — [[enterprise-ai-reality]] +- Built-in agent memory as anti-feature (Eugene/Larysa) vs persistent context docs used happily (Allie) — [[skills-as-memory]] +- Tight specs ([[leave-less-room-for-imagination]]) vs wide latitude ([[think-wider-not-bigger]]) + +## Evidence trail + +- [[overview]] — through-line and agree/diverge map +- Raw deliverables (not yet ingested, read directly): `raw/sources/Webinar Plan - From Chat Box to Your Own OS.md`, `raw/sources/Webinar script.md` (script ladder: Chat box → ReAct → Tools → Memory → Skills → Process → OS), `raw/sources/Ideas for webinar.md` +- Source summaries: [[2026-07-14-skills-based-on-git]], [[2026-07-14-gap-between-ai-users-irreversible]], [[2026-07-14-everything-we-knew-about-software-has-changed]], [[2026-07-14-sebastian-eugene-interview]], [[2026-07-14-nina-interview]], [[2026-07-14-yulia-interview]], [[2026-07-21-larysa-interview]] + +## Follow-up questions + +- Which subset fits the 30-min format? (Recommend: 1, 2, 3, 7, 9, 12, 14 as the seven load-bearing ones — one per talk segment.) +- Should theses 9–11 (obstacles) get their own station on the spine, or live inside "Do this tonight"? +- Ingesting the three webinar deliverable docs would let future queries cite them as wiki sources instead of raw. + +## Changed existing pages? + +No concept/entity pages changed — this is pure synthesis. `index.md` and `log.md` updated. diff --git a/wiki/queries/2026-07-24-non-engineer-throwaway-verification.md b/wiki/queries/2026-07-24-non-engineer-throwaway-verification.md new file mode 100644 index 0000000..820ded2 --- /dev/null +++ b/wiki/queries/2026-07-24-non-engineer-throwaway-verification.md @@ -0,0 +1,49 @@ +# Non-Engineer's Analog of Throwaway Verification Code + +#query + +**Question asked:** What is the non-engineer's analog of throwaway verification code ([[make-more-cheap-code]])? + +**Asked:** 2026-07-24 · **Status:** synthesis from existing pages (no new source) + +## Answer + +**The analog is disposable AI work whose only purpose is to attack, misread, and simulate your real deliverable before a human sees it — generated *checks*, not generated *content*.** + +Theo's engineer version: for every line that ships, generate 100–10,000 lines of never-shipped code that verifies it. The non-engineer's deliverables are documents and decisions — job descriptions, candidate profiles, specs, outreach emails, offer terms — so the analog is: **for every document you ship, generate several documents you never ship, whose job is to find out where the shipped one fails.** The webinar audience mostly uses AI on the *production* side (draft it for me); this points the same firehose at the *verification* side. + +Theo's concrete patterns map one-to-one onto the vault's HR/BA use cases: + +| Theo's engineer move ([[2026-07-24-youre-reading-way-too-much-code]]) | Non-engineer analog (grounded in corpus use cases) | +|---|---| +| Dumb-model agents try to build on your API — their failures are UX bugs in the API | Give your job description or spec to a **fresh agent with zero context** and ask it to restate who is being sought / what is being built. Where its naive reading diverges from your intent, the document is ambiguous. This is [[leave-less-room-for-imagination]] inverted: the AI's "fantasy" becomes an **ambiguity detector** — drift as diagnostic, safe because it happens in a throwaway sandbox instead of your deliverable. | +| Test 3 theories of an ambiguous PR in parallel | Ambiguous stakeholder ask → have the agent draft **3 divergent interpretations** cheaply and compare them, instead of committing to one reading. (Directly serves Larysa's BA work — [[2026-07-21-larysa-interview]].) | +| Generate a custom lint rule for a bug pattern you just found | Every recurring caught mistake (AI-sounding language, tone, missing salary band, unverifiable spec claim) becomes a **checker skill** that reviews future drafts. Allie's anti-AI-language skill is literally this ([[personal-ai-operating-system]]). | +| Load-test rigs; stress the system with throwaway infrastructure | **Simulate before real users arrive:** run 10 synthetic candidate profiles through a new screening process; query the candidate knowledge base ([[2026-07-14-yulia-interview]]) with naive questions to test whether profiles are standardized enough to be findable. | +| Red-team the sacred core with slop | Spawn an agent playing the **skeptical reader** — the picky hiring manager, the candidate deciding whether to reply, the developer misreading the spec — and let it generate the 20 objections before a human raises them. | +| Read every signature/API; skim bodies; agent-summarize diffs | Read the **boundaries**: names, numbers, dates, commitments — the document's "signatures" — by hand; let AI cross-check the body. | +| AI reviews code before humans do | AI reviews the document before your team/candidate does — a pre-human review step, same as Theo's. | + +**The method already exists in the vault — it just runs in one direction.** [[solve-first-then-skillify]] freezes proven *production* workflows into skills. This query adds the second species: **checker skills** — the correction loop you just went through (per Eugene's ~3-message heuristic) is not only a producer skill waiting to be frozen, it is also a *verifier* skill: "here is the mistake pattern; check every future draft for it." That gives the [[levels-of-ai-usage]] skills rung a dual population, producers and checkers, at zero extra conceptual cost for the audience. + +**What does not map.** Engineers verify against ground truth (tests pass or fail); a non-engineer's verification bottoms out in **human judgment** — there is no fuzzer for "is this offer fair." So tier D stays irreducibly human: offer terms, rejection communications, anything compliance-adjacent gets read line-by-line, exactly as Theo keeps hand-verification of shipped code. And Theo's "there's always another layer" still holds in weakened form: if you don't trust AI review of the document, have AI generate the **checklist you apply yourself**. + +**One-line webinar version:** *AI's first job isn't writing your document — it's breaking your document before a person does. What you ship, you still read; what checks it, you never read.* + +## Evidence trail + +- Engineer-side concept and all mapped patterns — [[make-more-cheap-code]], [[2026-07-24-youre-reading-way-too-much-code]] +- Non-engineer use cases (job descriptions, profiles, sourcing, candidate KB) — [[2026-07-14-nina-interview]], [[2026-07-14-yulia-interview]] +- BA/spec ambiguity and invisible drift — [[2026-07-21-larysa-interview]], [[leave-less-room-for-imagination]] +- Checker-skill precedent (anti-AI-language) — [[personal-ai-operating-system]], [[2026-07-14-gap-between-ai-users-irreversible]] +- Method being extended — [[solve-first-then-skillify]], [[levels-of-ai-usage]] + +## Follow-up questions + +- Does a "checker skill" need its own rung in the webinar ladder, or is it a footnote on the skills rung? +- Nina's finding that *the transcript matters more than the summary* cuts against agent-summary review — for non-engineers, when is the raw artifact (transcript, full document) the only safe thing to read? (Cousin of the Theo/Dax-vs-Eugene tension logged in [[leave-less-room-for-imagination]].) +- Is there a measurable claim for the webinar — e.g., "one fresh-agent misread test catches X% of spec ambiguities"? Currently pure assertion by analogy. Status: tentative. + +## Changed existing pages? + +Yes — light pointers only: [[make-more-cheap-code]] (next-question answered with link here), [[leave-less-room-for-imagination]] (drift-as-diagnostic inversion noted in Next Questions), plus `index.md` and `log.md`. diff --git a/wiki/sources/.gitkeep b/wiki/sources/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/wiki/sources/2026-07-14-everything-we-knew-about-software-has-changed.md b/wiki/sources/2026-07-14-everything-we-knew-about-software-has-changed.md new file mode 100644 index 0000000..bcf9a46 --- /dev/null +++ b/wiki/sources/2026-07-14-everything-we-knew-about-software-has-changed.md @@ -0,0 +1,48 @@ +# Everything we knew about software has changed — Theo Browne (AIE) + +#source + +## Source Metadata + +- **Date:** talk at AIE (year not stated in source; references Nov–Dec 2024 as recent past) +- **Raw path:** `raw/sources/Everything we knew about software has changed.md` +- **Source type:** conference talk (conclusions/notes), 16:01 — https://youtu.be/xUnRQ9vLXxo +- **Speaker:** [[theo-browne]] (t3.gg) +- **Ingestion date:** 2026-07-14 + +## Core Claims + +- Models improve faster than developers can. You can't keep pace by "getting better" — you must **[[think-wider-not-bigger|think wider]]** and pick ideas that feel embarrassingly ambitious. "If your idea doesn't feel stupid, it isn't big enough." +- Recent releases are **qualitatively distinct eras**, not increments (see [[ai-agent-evolution]]): tool-call → long-running-task → orchestration. +- You only feel a new model's gain if you **push scope to match it**. Work that made sense on the prior model won't feel different on the new one. +- Long-tenured engineers carry identity baggage (tools, language, git norms, sunk cost) that now actively holds them back — the "skeuomorphic phase" of development. See [[decoupling-identity-from-profession]]. +- Every project category shifted **down exactly one tier**; a brand-new bottom tier appeared: **a markdown file as executable prose**. See [[code-as-throwaway]]. +- Compete on **breadth**, not just depth — breadth is now viable for small teams. Be the right *shape* so users extend you (Slack effect). + +## Key Evidence / Details + +- **Three model eras** (speaker's framing/names): tool-call era = "Sonnet 3.5" (first reliable tool calls in a real codebase); long-running-task era = "Opus 4.5" (multi-hour tasks, self-testing; his "AI psychosis" began Nov–Dec 2024); orchestration era = "Mythos / Fable" (understands *itself*, spawns sub-models, verifies afterward — a prompt replaces a "software factory"). +- **iOS skeuomorphism analogy:** iOS 6 imitated physical objects to convince you the phone could replace them; iOS 7 dropped the pretense and got more useful. Developers are in their iOS-6 phase. +- **Identity symptoms:** terminal fetishism, language-as-identity ("he writes JavaScript"), ceremonial git norms (why *can't* we commit `.env`?), guilt-merging PRs. One gift of agents: no guilt throwing work away. +- **Tier shift table:** side project → shifts down; startup (his "Ping / Zoom for streamers", YC) → becomes a side project; "too big" (full-stack cloud: Vercel + auth + DB) → becomes a startup; new "too big" is unknown (train your own model? your own OS? compete with npm?). +- **"G-brain tier" = a markdown file.** He replaced a PR-triage service with a markdown file piped to Codex/Claude on a 9 AM cron; by 9:15 it read four repos, prioritized the day, and shipped a static HTML file to S3. +- **Breadth vs depth:** old rule — pick a vertical, go deep (Vercel vs AWS). New reality — bolt a serviceable database/platform layer into your product in a day or two of prompting; cover enough that users can *start*. **Slack** accidentally became everyone's agent platform because its *shape* invited extension, not because it's good. + +## Connections + +- **Entity:** [[theo-browne]] +- **Concepts:** [[think-wider-not-bigger]] · [[code-as-throwaway]] · [[decoupling-identity-from-profession]] · [[context-as-scarce-resource]] (implied by orchestration) +- **Timeline:** [[ai-agent-evolution]] (his eras align with Konstantin's tooling timeline) +- **Related sources:** [[2026-07-14-skills-based-on-git]] (orchestration/harness view from the model-builder side); [[2026-07-14-gap-between-ai-users-irreversible]] (markdown-as-skill echoes G-brain tier); [[2026-07-24-youre-reading-way-too-much-code]] (Theo's follow-up: the *discipline* behind code-as-disposable — [[make-more-cheap-code]]) +- **Tools mentioned:** [[claude-code]], Codex, Vercel, AWS, Slack, npm + +## Open Questions + +- What is the new "too big" ceiling now that orchestration models exist? (Speaker explicitly doesn't know.) +- Model names "Mythos / Fable" are the speaker's framing — how do they map to shipped model IDs? (Fable 5 is a real current model; "Mythos"/"Opus 4.5" mapping unverified.) Status: tentative. + +## Change Impact on Wiki + +- Created concept pages [[think-wider-not-bigger]] and [[code-as-throwaway]]; contributed to [[decoupling-identity-from-profession]] (shared with [[2026-07-14-sebastian-eugene-interview]]). +- Seeded the [[ai-agent-evolution]] timeline with the three model eras. +- Added [[theo-browne]] entity. diff --git a/wiki/sources/2026-07-14-gap-between-ai-users-irreversible.md b/wiki/sources/2026-07-14-gap-between-ai-users-irreversible.md new file mode 100644 index 0000000..6a7805e --- /dev/null +++ b/wiki/sources/2026-07-14-gap-between-ai-users-irreversible.md @@ -0,0 +1,50 @@ +# In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible — Allie Miller + +#source + +## Source Metadata + +- **Date:** interview (year not stated; references a "2026 Goals doc") +- **Raw path:** `raw/sources/In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible.md` +- **Source type:** interview (conclusions/notes), 59:16 — https://www.youtube.com/watch?v=YfRkj9kmQf0 +- **Guest:** [[allie-miller]] (ex-Amazon AI leader; advises OpenAI / Google / Anthropic and Fortune 500s) +- **Ingestion date:** 2026-07-14 + +## Core Claims + +- The compounding advantage is no longer *which prompt you write* — it's whether you've built a **[[personal-ai-operating-system]]**: persistent context docs, reusable [[skills-as-memory|skills]], and proactive scheduled workflows. In 12 months the gap between someone who invests one focused week and someone still using AI as a chat-box will be **irreversible**. +- Reframe AI from *intern → first-class teammate*, from *tool I open → OS running 24/7*, from *prompt engineering → [[context-as-scarce-resource|context engineering]]*. +- Winners vs losers don't differ in expertise — they differ in **mindset**: winners use AI to challenge/augment their thinking and keep agency; losers offload judgment. +- Build **3 foundation documents first**, then layer skills and proactive workflows on top. +- The meta-skill of the era is **knowing what good looks like** (taste), not execution skill. + +## Key Evidence / Details + +- **Her setup:** 36 proactive workflows, ~28 master agents, ~100 total agents on schedules; productivity 2×–10× depending on task. +- **4 Claude surfaces:** web chat (Q&A, low action) · Cowork (agentic business work, medium) · [[claude-code]] (max control, scheduled tasks, high) · Chrome extension (drives a browser tab). Skills transfer across surfaces and to ChatGPT/Perplexity/Gemini — "just folders with markdown." See [[skills-as-memory]]. +- **Skill abstraction:** a folder with one MD file (*what to do*) + optional resources; skills **compose** (LinkedIn-voice skill calls anti-AI-language skill) and are shared between agents. Built-in skill-creator skill. +- **3 foundation docs** (spend ~1 hour letting Claude interview you): **Personal Constitution** (values, working style — nothing time-bound), **2026 Goals doc** (annual→quarterly→monthly→weekly), **Core Business Strategy doc** (who you serve + off-website nuance). Outputs jump from generic to ~50% "Allie zone." +- **How to prompt now:** *"Just complain"* — rambling frustration is rich context Claude turns into proposed skills. Two universal patterns: (1) "Ask me questions before doing this" (interview-then-execute); (2) push back when it refuses. +- **Proactive workflows:** ~6 AM Morning Brief (top-3 stories ranked to impress your boss, weather+clothing, local events, per-meeting kickoff notes); Friday Email Recap (urgent unreplied emails ranked, with drafted replies). Scheduling is native to Claude Code / Cowork / Codex. +- **4-tier model of AI work:** Microtask → Companion → Delegate → Teammate. Enterprise super-users get 3–5× and **hoard** the knowledge; treating AI as a *team* asset breaks hoarding. +- **Trust calibration:** high inside your expertise; low outside (pair with a human); legal → AI first-pass + 15-min lawyer review (cautionary tale: founder fired a contractor on ChatGPT-advised contract reading, got sued, owes more). Ground high-stakes work with retrieval, not raw weights. +- **12-month predictions:** self-learning models (real weight updates, not the memory-file trick) · "market of one" (every site rendered for you, e.g. Flint/Nike) · agent-to-agent communication. Side effect: **human relationships become more valuable** (echoes [[connections-as-moat]]). +- **Teams:** Path A (cut headcount 8→2) vs Path B (keep 8, 5–10× output). Income play: AI fluency + diversified income + intelligent frugality; some take a short-term step back to pivot. + +## Connections + +- **Entity:** [[allie-miller]] +- **Concepts:** [[personal-ai-operating-system]] · [[skills-as-memory]] · [[context-as-scarce-resource]] · [[connections-as-moat]] (human-relationship side effect) +- **Related sources:** [[2026-07-14-skills-based-on-git]] (skills-as-memory from the engineering side — strong overlap) · [[2026-07-14-everything-we-knew-about-software-has-changed]] (markdown-as-skill ≈ G-brain markdown tier) +- **Tools mentioned:** [[claude-code]], Claude Cowork, Codex, Flint + +## Open Questions + +- What's actually in a good Personal Constitution vs a Goals doc — a reusable template? (Webinar-relevant deliverable.) +- Are "self-learning models with real weight updates" a near-term reality or aspiration? Status: tentative (speaker's 12-month prediction). + +## Change Impact on Wiki + +- Created [[personal-ai-operating-system]] and contributed to [[skills-as-memory]] and [[context-as-scarce-resource]] (shared with [[2026-07-14-skills-based-on-git]]). +- Added [[allie-miller]] entity; extended [[claude-code]] with the 4-surfaces framing. +- Contributed the human-relationship angle to [[connections-as-moat]]. diff --git a/wiki/sources/2026-07-14-nina-interview.md b/wiki/sources/2026-07-14-nina-interview.md new file mode 100644 index 0000000..3a8373e --- /dev/null +++ b/wiki/sources/2026-07-14-nina-interview.md @@ -0,0 +1,48 @@ +# Nina Interview — HR Use Cases Validate the Webinar Thesis + +#source + +## Source Metadata + +- **Raw path:** `raw/sources/Nina interview.md` +- **Source type:** interview conclusions/insights doc (auto-generated by Eugene's record→diarize→transcribe→summarize tool) +- **Participants:** [[eugene]] (SPEAKER_00, interviewer/webinar author) and [[nina]] (SPEAKER_01, HR recruiter at [[virtido]]) +- **Ingestion date:** 2026-07-14 + +## Core Claims + +- The webinar thesis holds: non-programmers have real, repetitive problems (job descriptions, interview write-ups, LinkedIn sourcing) that small self-built AI tools solve **today**. The old belief "software is slow and expensive" is dead. +- **Adoption is blocked by friction, not resistance.** Nina's colleagues would use these tools "if it were simple" — the missing piece is a simple all-in-one path, not persuasion. +- For recruiters, **the transcript matters more than the AI summary** — note-taking during a call wrecks the conversation ("I don't concentrate on the conversation"), especially on 5 a.m. cross-timezone calls. +- AI is a **multiplier**, not a replacement; "it makes mistakes" is a weak objection when compared with human error rates. +- The deep payoff is **lower cognitive load**, not just more output ("even if your output doesn't change… your life overall gets better"). +- [[skills-as-memory|Skills]] turn personal expertise into a transferable asset: do the task through AI, correct it, then freeze it into a skill a junior hire can run ([[solve-first-then-skillify]]). +- Agents driving a **real browser** beat paid sourcing tools (LinkedIn Sales Navigator end-run), with anti-bot risk at team volume. +- Local + subscription beats API/SaaS for this tool class: no per-call cost, no licensing, no login/security surface. + +## Key Evidence / Details + +- **The demo tool:** one red button → record → diarize + transcribe + analyze → structured report. ~10 min to process 1 hour of audio, locally on GPU, on a Claude subscription. (This very document is its output format.) +- Sourcing demo: "Computer Vision companies under 200 people, most senior reachable contact, save profile link" — runs in the background. +- Nina could go from ~5 to ~25 candidates/day; multilingual output (EN/DE/UK) is a genuine unlock for her. +- Practice notes: one responsible agent per project (Eugene ran 7 in parallel); Karpathy-style Obsidian knowledge base to be shared as a post-webinar "gift"; consent before recording candidates. +- Webinar: first one in English, titled *"From a chat box to your own operating system"*, aimed at non-programmers. + +## Connections + +- Entities: [[eugene]], [[nina]], [[virtido]], [[inspectron]], [[claude-code]] +- Concepts: [[skills-as-memory]], [[solve-first-then-skillify]], [[personal-ai-operating-system]], [[code-as-throwaway]] (the "software is slow and expensive is dead" claim), [[context-as-scarce-resource]] +- Companion interview: [[2026-07-14-yulia-interview]] (same HR team, overlapping pain points) + +## Open Questions + +- How to bridge Eugene's programmer-grade demos to a non-programmer's on-ramp — he admits simple examples "hang in a vacuum." +- Can transcribe→summarize plug into **Manatal** (the team's ATS) and sync across recruiters (e.g., via git)? +- Will LinkedIn flag automated browsing at HR-team volume? Threshold unknown. +- Are skills personal IP or employer work product? Unresolved between Eugene and [[sebastian]]. +- Larysa (project management) not yet interviewed — PM use cases missing. + +## Change Impact on Wiki + +- Created [[nina]], [[inspectron]]; created concept [[solve-first-then-skillify]]. +- Updated [[eugene]] (identity evidence strengthened: webinar author, Inspectron, tool builder), [[virtido]] (HR-team vantage point), [[skills-as-memory]] (skills as handoff/de-risking), [[overview]] (HR-practitioner lens added to through-line). diff --git a/wiki/sources/2026-07-14-sebastian-eugene-interview.md b/wiki/sources/2026-07-14-sebastian-eugene-interview.md new file mode 100644 index 0000000..1b8c407 --- /dev/null +++ b/wiki/sources/2026-07-14-sebastian-eugene-interview.md @@ -0,0 +1,50 @@ +# Sebastian Interview — How AI Is Reshaping Software Engineering + +#source + +## Source Metadata + +- **Date:** pre-webinar conversation (date not stated) +- **Raw path:** `raw/sources/sebastian interview - conclusions and insights.md` +- **Source type:** interview (conclusions/insights), ~56 min. Built from a Whisper large-v3 + speaker-diarized transcript; quotes lightly cleaned. +- **Participants:** [[sebastian]] (founder of [[virtido|Virtido]], ~11-yr outsourcing firm) and [[eugene]] (interviewer; CV/embedded developer, content creator, harness-builder) +- **Ingestion date:** 2026-07-14 + +## Core Claims + +- The debate over *whether* AI can write software is over — the whole game is **how you use it**. Cost of code → zero (see [[code-as-throwaway]]). +- **Teams shrink and roles merge:** the 8-person scrum team collapses to 2–3 who share coordination and agent-wrangling. See [[seniority-and-the-junior-squeeze]]. +- **[[harness|"Bring your own harness"]] hits an enterprise wall** — compliance/liability force a company-managed resource. *That gap is the business opportunity.* See [[enterprise-ai-reality]]. +- Pure coding skill is **leveled** by AI (20-yr veteran ≈ fresh grad output); judgment, [[product-ownership|ownership]], and **human [[connections-as-moat|connections]]** rise in value. +- **[[connections-as-moat|Relationships are the last non-commoditized asset]]** — the standout insight of the interview. +- Learn to **[[decoupling-identity-from-profession|decouple identity from profession]]** or "we will feel worthless in a couple of years." + +## Key Evidence / Details + +- **The question changed:** "It's not a question *if* AI can write software anymore — it's just a question of *how* you use it." +- **Team collapse:** no scrum master + PM + requirements engineer + big dev team — instead one coordination/ownership role + one or two agent-managers sharing roles. +- **Harness at enterprise scale:** Eugene demoed his own (Telegram-like UI, one agent per project, inter-agent messaging, per-agent memory, "done thinking" signal; tools: **Conductor** for git-worktree isolation + auto PRs/merges). Sebastian's counter: "bring-your-own-harness will not be the way forward… it has to be a company-managed resource." Enterprise reality: engineers on centrally-managed VMs, zero self-install (Roche SAP transformation ~1,200 engineers for years; banks moving from banned → cautious adoption "because it's just so good"). +- **Seniors up, juniors out:** seniors know *where things go wrong* ("AI does the same mistakes humans do because it's trained on our mistakes"); the junior "yes… yes… allow for all future" habit is how "API keys are leaked, databases get dumped." "Give a junior… access to this almighty Claude and… the codebase — they will [wreck] it in two days." +- **Ownership 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 result. Reframe: stop thinking "what needs to be done" (tickets); think "what problem needs to be solved." "No one ever needed a programmer… people have problems that you are solving." +- **Planning debate:** colleague **Daniel** floated returning to waterfall; Sebastian disagrees — coordination overhead now exceeds the work. On a 2-person, ~1-day/week project he's *faster alone*. **Printer anecdote:** unfamiliar direct-printing protocol in Java (never written), 2-day deadline — went on-site, Claude Code solved it in ~30 min; his edge was *knowing how to instruct and verify*. +- **Connections (the moat):** in-person 2–4 days/week (lunches, events, conferences) wins business; sales agencies / cold calling / email / LinkedIn campaigns / content / SEO = "Big zero." A connection forms on the *second* meeting in *different* circumstances → recognition → trust → referrals. Be memorable in your **humanness** (renovating a house, two kids, a cat) — because everyone's AI output looks identical (riff: Virtido's `humans.verti.com` "human badge"). +- **Other points:** open source grows as code becomes ~free (Eugene's cynical read: OSS is largely marketing); legacy niches persist (COBOL in banks — no training data); outsourcing economics — low-cost expectation selects for bad code ($10k/mo → excellent people; $800/mo won't beat a good hire). + +## Connections + +- **Entities:** [[sebastian]] · [[eugene]] · [[virtido]] · [[claude-code]] · [[hermes]] (Eugene references it among his tools) +- **Concepts:** [[harness]] · [[enterprise-ai-reality]] · [[seniority-and-the-junior-squeeze]] · [[product-ownership]] · [[connections-as-moat]] · [[decoupling-identity-from-profession]] · [[code-as-throwaway]] +- **Related sources:** [[2026-07-14-skills-based-on-git]] (harness definition + BYO-harness from the practitioner side) · [[2026-07-14-everything-we-knew-about-software-has-changed]] (identity baggage, code-as-throwaway) +- **Raw reference (not ingested):** `raw/sources/Ideas for webinar.md` echoes many of these (harness, connections, "describe problems not waterfalls," Daniel, HR search demo). + +## Open Questions + +- How does AI transform *huge* (~1,200-engineer, multi-year) enterprise programs? (Sebastian: doesn't know.) +- How do you unify wildly different personal workflows into one company process? (Eugene + collaborator spent a month, failed.) +- Concretely, how does an individual build a connections network from a standing start? (Principles offered; step-by-step unresolved — Eugene's ~6-month blocker.) + +## Change Impact on Wiki + +- Created [[harness]], [[enterprise-ai-reality]], [[seniority-and-the-junior-squeeze]], [[product-ownership]], [[connections-as-moat]]; contributed to [[code-as-throwaway]] and [[decoupling-identity-from-profession]]. +- Added entities [[sebastian]], [[eugene]], [[virtido]]. +- [[eugene]] noted as the likely vault owner / webinar author (Status: tentative). diff --git a/wiki/sources/2026-07-14-skills-based-on-git.md b/wiki/sources/2026-07-14-skills-based-on-git.md new file mode 100644 index 0000000..927e43e --- /dev/null +++ b/wiki/sources/2026-07-14-skills-based-on-git.md @@ -0,0 +1,53 @@ +# Git-Based Skills — the New Memory of AI Agents (Konstantin, Sber) + +#source + +> Russian-language source. Summary in English; key terms preserved. + +## Source Metadata + +- **Date:** talk (year not stated; positions "2026 (now)" and forecasts 2027) +- **Raw path:** `raw/sources/Скиллы на базе git — новая память AI-агентов.md` +- **Source type:** conference talk (conclusions), 53:09 — https://www.youtube.com/watch?v=a-NIeMB-Hj8 +- **Speaker:** [[konstantin]] (Sber, GigaChat dev team, agent R&D) +- **Ingestion date:** 2026-07-14 + +## Core Claims + +- **Skills + user data + auto-improvement = the new memory of AI agents**, the architecture all agentic systems will converge on. Tools (how to call), data (what you work on), and usage history live together in one **git repo**; the [[harness]] decides what to load into context. +- **Simplicity beats complexity:** a universal agent with ~10 file-ops functions outperforms elaborate multi-agent graphs. The era of **universal agents = [[harness|harnesses]]**. +- Agent tooling evolved **tools → MCP → skills** (see [[evolution-of-agent-tooling]]); skills' two-stage loading lets you keep *hundreds* of skills without blowing context. +- The classic skill is "**von Neumann without data**" — add data + usage history into the same git repo. +- **[[agentic-loops|Agent loops]]** are the next paradigm (forecast: dominant in 2027): inner (ReAct) → outer (Ralph) → meta. + +## Key Evidence / Details + +- **Harness = harness/upness metaphor:** LLM = the force, tools = the harness, data = the field; the LLM "pulls the tools across the data space." Different tasks, *same* processing method. Standard toolset ~30–40 max (Read/Edit/Write, Bash, Grep/Glob/WebSearch, TodoWrite, subagent spawn); >100 tools = even Fable 5 gets confused. See [[harness]]. +- **Human role evolution:** prompt-engineer → context-engineer → harness-builder → **loop-engineer** (CI/CD, back-pressure, meta-loops). See [[context-as-scarce-resource]]. +- **Hackathon proof:** 19 of 20 top teams at BitGen built on harnesses; his own harness placed 7th (Interpress-Ex, run in an infinite loop over a weekend — *read zero tasks by eye*) and 3rd overall / 1st on technical metrics (Snowbase, leaked Claude Code as backend). +- **tools → MCP → skills:** Tools (2022–24) each consume context; MCP (Anthropic, late-2024→25) adds ready tools via protocol but many servers = dozens of tools = context blowout + network-load security risk (he doesn't hate MCP; issues largely solved). **Skills (2025→)** = directory + gentleman's agreement: `SKILL.md` + tools + (his proposal) **data**. Two-stage loading: short description always in system prompt; long description loaded only when the agent enters the dir. Hermes grew 56 → 100 skills and still works. Cost: MCP needs a developer; a skill needs someone who can write text (any language). Claude Code turns MCP into skills, erasing most MCP downsides. See [[skills-as-memory]] and [[evolution-of-agent-tooling]]. +- **Why git:** skill-first (many agents on one skill — Claude Code, Hermes via Telegram, OpenClaude anywhere) · CI/CD integration · team sharing · merge-conflict resolution now done by models (parallel actors on bare git, no transactional DB — "not for payments, but for much else, yes"). **Mandatory AGENTS.md rules:** `git pull` at start, `push`+`commit` at end, **CI as back-pressure** (returns a drifting agent to spec). +- **His daily skills (with data):** DNA/medicine (~100 GB sequencing for the whole family; Claude analyzed an undescribed mutation, found the gene, called **AlphaFold**, rendered the protein, concluded the fold is fine — own full genome for ~$1000 and an evening vs $3B/13 yrs historically) · recommendations (~1000 ratings) · trip planning (photo a ticket in Telegram → agent git-pulls, files the PDF, commits; "hotel not booked, 2-hr layover — don't even try") · HR/résumé scoring (self-corrected over 10–20 feedback iterations to ~10% error) · finance · team agent-R&D. +- **Auto-improvement (Hermes):** >5 tool calls on a task → candidate skill. Curator: prune unused at 30 days (deactivate) / 90 days (archive); consolidate pairs weekly so short-descriptions don't eat context. Memory is now skills, not RAG-extracted facts. +- **Agent loops:** inner = ReAct. **Outer/Ralph loop** (Geoffrey Huntley): `while true; do claude -p "solve" || true; done` — runs for days, stays in the **"smart zone"** (first ~⅓ of context) avoiding summarization decay. **Meta loop** (his own): periodically wipe all agent-created data to an unseen archive and restart, dodging Karpathy's **collapse** (same solution reworded) — good for research tasks. +- **Auto-agent result:** weak GigaChat went from **1/89 → 11/89** benchmark tasks over a weekend of self-improvement (11× gain, verified no overfit). Idea from Karpathy's "autoagent." +- **Missing piece:** perception / qualia (the "walk vs drive to the car wash" example); maybe world-models — open question. + +## Connections + +- **Entity:** [[konstantin]] · tools: [[claude-code]], [[hermes]], Codex CLI, OpenClaude, Cursor, Conductor, AlphaFold +- **Concepts:** [[skills-as-memory]] · [[harness]] · [[evolution-of-agent-tooling]] · [[agentic-loops]] · [[context-as-scarce-resource]] +- **Timeline:** [[ai-agent-evolution]] +- **Related sources:** [[2026-07-14-gap-between-ai-users-irreversible]] (skills = markdown folders; strong overlap) · [[2026-07-14-sebastian-eugene-interview]] (harness, BYO-harness) · [[2026-07-14-everything-we-knew-about-software-has-changed]] (orchestration era, markdown-as-service) + +## Open Questions + +- What data belongs in a skill, and is there an upper limit? (No standards yet; he loads 200 GB in one skill, 100 KB in another — "haven't found the ceiling.") +- How do you build world-models / give agents perception? (Open.) +- Are the pruning windows (30/90 days) and the >5-tool-call threshold generalizable, or Hermes-specific heuristics? Status: tentative. + +## Change Impact on Wiki + +- Created [[skills-as-memory]], [[agentic-loops]], [[evolution-of-agent-tooling]]; contributed heavily to [[harness]] and [[context-as-scarce-resource]]. +- Added entities [[konstantin]] and [[hermes]]; extended [[claude-code]]. +- Extended the [[ai-agent-evolution]] timeline with the tools→MCP→skills and loop generations. diff --git a/wiki/sources/2026-07-14-yulia-interview.md b/wiki/sources/2026-07-14-yulia-interview.md new file mode 100644 index 0000000..b2755b9 --- /dev/null +++ b/wiki/sources/2026-07-14-yulia-interview.md @@ -0,0 +1,48 @@ +# Yulia Interview — Levels of AI Usage & the Candidate Knowledge Base + +#source + +## Source Metadata + +- **Raw path:** `raw/sources/Yulia interview.md` +- **Source type:** interview conclusions/insights doc (auto-generated summary; speakers unnamed in text) +- **Participants:** [[yulia]] (SPEAKER_00, HR/recruiting lead — name inferred from filename, Status: tentative) and [[eugene]] (SPEAKER_01, senior programmer ~20 years, works on [[inspectron]], $200 Claude max plan) +- **Ingestion date:** 2026-07-14 + +## Core Claims + +- **AI usage has distinct levels, and most people are stuck at level one:** web chatbot → built-in memory → Claude Code/Cowork with local files → CLAUDE.md → skills → Obsidian knowledge base → RAG. The practical ceiling for non-programmers is **CLAUDE.md + skills** ([[levels-of-ai-usage]]). +- **Solve first, skill-ify after** — the recurring mistake is building the skill up front; instead reach the final solution once with Claude, then say "now create a skill from this" ([[solve-first-then-skillify]]). Turn any correction loop longer than ~3 messages into a skill. +- **Both recruiting problems are the same problem:** a candidate database plus search over it — record interviews, auto-transcribe with diarization, generate standardized profiles, then query by skill. +- **AI automates all information work; the human keeps the human parts** — "the human's role in this process is just to be human — introductions, communication." (Converges with [[connections-as-moat]].) +- **AI prices will rise, not crash** — "what I now buy for 200 will cost about 1,000"; the bubble pops *upward*, and leverage shifts to knowing which models to use. Status: tentative (prediction). +- **Renting GPU beats owning** for this workload: ~$0.10/candidate on RunPod vs a $1,500–2,000 machine — though a home GPU transcribes overnight for free. + +## Key Evidence / Details + +- Live demos: RunPod transcription; Claude driving a browser to pull LinkedIn HR contacts into a Markdown list. LinkedIn bans bots — only shallow passes (~20 contacts) are safe. +- Immediate no-tooling practice change: **start recording candidate interviews now**, one file per candidate, named by candidate (consent implied per [[2026-07-14-nina-interview]]). +- Stack recommendation: Claude (Cowork for non-programmers); RAG only matters at corporate scale; cheaper models (e.g. Qwen) do the same tasks "just worse." +- Prompting principle: your job is to "narrow the variability of interpretation" — vague asks invite "fantasy." +- Reusable framing: "Split yourself into two people — one slightly smarter (you, the manager), one slightly dumber (the AI, your subordinate)." +- Deal context: webinar plan to be drafted over a weekend, **no deadline**; a paid build of the HR system is on the table (rough "$5 to $100" per-project range needs scoping), possibly a shared monthly service on Eugene's subscription. +- Company-scale idea: a lightweight AI "assistant" chatting with employees to form an information core — automating much of the PM/status-reporting role. + +## Connections + +- Entities: [[yulia]], [[eugene]], [[nina]] (referenced), [[inspectron]], [[claude-code]], [[virtido]] (Yulia's team affiliation tentative) +- Concepts: [[levels-of-ai-usage]], [[solve-first-then-skillify]], [[skills-as-memory]], [[connections-as-moat]], [[personal-ai-operating-system]], [[context-as-scarce-resource]] +- Companion interview: [[2026-07-14-nina-interview]] (same team's pain points from the recruiter's seat) + +## Open Questions + +- Exact scope, deliverables, and price of the HR system build. +- Webinar date/title (later fixed as *"From a chat box to your own operating system"* per [[2026-07-14-nina-interview]] — this interview likely predates it). +- Rent GPU vs. buy a GPU machine — folded into Yulia's next hardware purchase decision? +- Larisa's Claude memory complaint — fixable via built-in memory/CLAUDE.md, but her actual BA/PM task was never detailed. +- Is SPEAKER_00 really named Yulia, and is she at [[virtido]]? Inferred from filename + references to Nina/Sergiy. Status: tentative. + +## Change Impact on Wiki + +- Created [[yulia]]; created concepts [[levels-of-ai-usage]] and [[solve-first-then-skillify]]. +- Updated [[eugene]] (Inspectron, $200 plan, paid-build offer), [[connections-as-moat]] (Eugene independently lands on the human-connection residual), [[skills-as-memory]] (~3-message correction-loop heuristic), [[overview]]. diff --git a/wiki/sources/2026-07-21-larysa-interview.md b/wiki/sources/2026-07-21-larysa-interview.md new file mode 100644 index 0000000..b8269e4 --- /dev/null +++ b/wiki/sources/2026-07-21-larysa-interview.md @@ -0,0 +1,51 @@ +# Larysa Interview — Memory Loss, Phantom Integrations, and the Case for Skills + +#source + +## Source Metadata + +- **Raw path:** `raw/sources/Larysa interview.md` +- **Source type:** interview conclusions/insights doc (auto-generated by Eugene's record→diarize→transcribe→summarize tool) +- **Participants:** [[eugene]] (SPEAKER_00, webinar host) and [[larysa]] (SPEAKER_01, technical BA/PM, ex-mobile developer) +- **Ingestion date:** 2026-07-21 +- **Note:** closes the "Larysa not yet interviewed / PM use cases missing" gap opened in [[2026-07-14-nina-interview]] and [[2026-07-14-yulia-interview]]. + +## Core Claims + +- **The friction with agentic AI is structural, not accuracy.** Larysa's blockers are not hallucination but (1) no durable memory across sessions, (2) integrations that look available and aren't, (3) over-eager drift on loosely specified tasks. +- **Agent memory, as shipped, is a net negative.** Eugene is blunt: "Memory is the worst thing agents have — it gives no benefit and confuses users to hell… it'd be better if it didn't [exist]." The replacement is [[skills-as-memory|skills]], not a better memory feature. +- **Claude starts work against capabilities it doesn't have.** It accepts a task, then discovers mid-way that a connector isn't implemented or isn't available for a *private* (vs. corporate) account — after half an hour of the user's time and tokens are spent. See [[integration-dead-ends]]. +- **Consolidate, don't tool-hop.** Eugene's central pitch: one personal "operating system" where all project agents live together and can talk to each other beats spinning up Claude in separate folders — "my life just split into before and after." +- **Leave less room for imagination.** Under-specified prompts invite drift, and the drift causes collateral damage you won't notice. Standardized procedures (skills) are the constraint. See [[leave-less-room-for-imagination]]. +- **AI-assisted coding is production-ready as of ~Claude 4.6, with carve-outs.** "Code isn't something elite anymore… though authorization and payments I still wouldn't trust to Claude." +- **Diarization + role inference is the differentiator** in interview automation over plain transcribe-then-summarize. + +## Key Evidence / Details + +- **Larysa's actual usage** (unusually deep for a non-engineer role): opens pull requests, wires Claude to **ClickUp** (Jira analog) and **Figma**, builds clickable prototypes, writes user stories and tests. +- **The dead-end example:** a Teams bot to watch a work chat and auto-create ClickUp tasks. Verdict — Teams is effectively a dead end (Microsoft exposes no usable external API); Slack has first-class Claude support from Anthropic but needs a paid seat she isn't given. Figma is blocked the same way: no personal paid account → no full editable access. +- **Her quote on the failure mode:** "That's not hallucination exactly… it just first goes looking for what you don't have. I don't know how to fight this." — left explicitly unresolved. +- **Model choice:** Eugene runs **Claude 4.7** in production, finding **4.8 "too proactive"** ("without the flights of fancy 4.8 has"). +- **Testing note:** prefer browser/web testing over emulator testing with Claude — the emulator got badly stuck. +- **Tool convergence:** both participants independently landed on recording and auto-processing interviews. Eugene's system adds speaker diarization plus *role* inference from conversation context ("Speaker 0, HR Equity Lead; Speaker 2, Senior Programmer") — ~10–11 min for a one-hour interview. This document is its output. +- **Webinar commitment:** [[skills-as-memory|skills]] are the one topic Eugene commits to covering for Larysa. + +## Connections + +- Entities: [[eugene]], [[larysa]], [[claude-code]], [[inspectron]], [[virtido]] (Larysa's affiliation tentative) +- Concepts: [[skills-as-memory]], [[integration-dead-ends]] (new), [[leave-less-room-for-imagination]] (new), [[harness]], [[levels-of-ai-usage]], [[solve-first-then-skillify]], [[code-as-throwaway]], [[personal-ai-operating-system]] +- Companion interviews (same webinar-scoping series): [[2026-07-14-nina-interview]], [[2026-07-14-yulia-interview]] + +## Open Questions + +- How to reliably pre-empt integrations Claude recommends that aren't available for the user's account type — stated as unsolved by both participants. +- Is a Teams-triggered auto-task bot feasible at all given Microsoft's API surface? (Asserted dead end, not demonstrated.) +- How to get full editable Figma access without a personal paid account. +- Is 4.8's "over-proactivity" a model property or a prompt-specification problem? (It reads as the same drift [[leave-less-room-for-imagination]] blames on loose specs — Eugene treats it as the model's fault.) +- Larysa's employer is never stated; [[virtido]] is inferred from the interview series. Status: tentative. +- Webinar structure and scheduling — deferred to a follow-up with [[yulia]]. + +## Change Impact on Wiki + +- Created [[larysa]] (entity); created concepts [[integration-dead-ends]] and [[leave-less-room-for-imagination]]. +- Updated [[skills-as-memory]] (memory-as-anti-feature: the negative case for why skills exist), [[harness]] (consolidation-over-tool-hopping claim), [[code-as-throwaway]] (the auth/payments trust carve-out), [[levels-of-ai-usage]] (Larysa as a high-rung user still missing the skills rung), [[solve-first-then-skillify]], [[claude-code]] (4.7 vs 4.8; memory and connector limits), [[eugene]], [[yulia]], [[virtido]], [[overview]]. diff --git a/wiki/sources/2026-07-22-ai-is-stupid.md b/wiki/sources/2026-07-22-ai-is-stupid.md new file mode 100644 index 0000000..5ef89f4 --- /dev/null +++ b/wiki/sources/2026-07-22-ai-is-stupid.md @@ -0,0 +1,47 @@ +# ИИ глупый! (AI Is Stupid!) + +#source + +## Source Metadata + +- **Date:** 2026-07-22 (ingestion date; publication date unknown) +- **Raw path:** `raw/sources/ИИ глупый!.md` +- **Source type:** Conclusions doc for a Russian-language YouTube Short (1:28) — https://www.youtube.com/shorts/P4eWd2jvz4k — titled «ИИ глупый! #ии #ai #бизнес» +- **Author:** unknown (business-facing Russian-speaking creator). Status: tentative. +- **Ingested:** 2026-07-22 + +## Core Claims + +1. AI looks "stupid" not because the model is weak, but because it is systematically starved of two things: **context** (memory of *your* specific business) and a **harness** (the rules the model must reason by). Without them, even the strongest model answers like an outside expert, not like your employee. +2. **Intelligence without context loses to context without intelligence.** Analogy: ask "how will our sales month close?" — ten Nobel laureates can only cite industry averages ("~5% up/down across Russia"), while a rank-and-file employee of your company answers better, because they see your funnel, clients, seasonality, and deals. +3. The formula: **strong model + your business context + harness = employee-level answer.** Remove any component and you get "smart but generic," "specific but undisciplined," or "stupid AI." +4. Giving the model your company's context improves answer quality "by orders of magnitude" (author's hyperbole: "tens of times, maybe a million"). +5. Investment advice: before swapping to a "smarter" model, invest in **context infrastructure** (data, memory, integrations — the video names RAG, long-term assistant memory, CRM/ERP/document ingestion) and in the **harness** (rules, checks, tooling). That is where the ×10…×1000 gains are, not in model version bumps. +6. Maturity metric for an AI rollout: *can the model answer a question about your business more accurately than an outside consultant?* If not, context or harness is missing. + +## Key Evidence / Details + +- The harness is defined here as more than a prompt: an "engineering wrapper" — what the model must verify, which tools to trust, how to shape the answer, what is forbidden — turning the LLM from "an encyclopedia of hospital averages" into a **procedural agent**. +- Target audience per the video: business owners and product managers disappointed by generic LLM answers; engineers building corporate assistants; anyone choosing between "get a bigger model" and "give the model the right data and rules." + +## Connections + +- [[harness]] — the video's second ingredient is exactly the vault's harness concept, restated for a business audience; independent convergence with [[konstantin]] and [[eugene]]. +- [[context-as-scarce-resource]] — complements it from the *supply* side: the vault's page says context is the binding constraint inside the window; this source says the default failure is not providing business context at all. +- [[personal-ai-operating-system]] — the Nobel-vs-employee analogy is the business version of Allie's "feed the system who you are" (foundation docs). +- [[skills-as-memory]] — tension: this video names **RAG** as a practical context mechanism, while [[2026-07-14-skills-based-on-git]] argues skills-as-memory beats RAG (see Open Questions). +- [[levels-of-ai-usage]] — "stupid AI" is what the bottom rungs of the ladder feel like; the formula names what the upper rungs add. + +## Open Questions + +- Who is the author, and is the short connected to anyone already in the corpus (its context+harness framing matches the corpus suspiciously well)? Status: tentative. +- The video treats RAG and long-term memory as go-to context mechanisms; Konstantin's source argues skills beat RAG (harness loads on activation instead of pre-injecting). Is the difference audience-driven (business data vs procedures), or a real disagreement? +- The ×10…×1000 improvement claims are rhetorical, not measured. + +## Change Impact on Wiki + +- Created this source page. +- [[harness]] — added the business-facing definition ("engineering wrapper"), the three-part formula, and this source as independent convergent evidence. +- [[context-as-scarce-resource]] — added the supply-side facet ("intelligence without context loses to context without intelligence"), the Nobel-vs-employee analogy, and the RAG tension. +- [[overview]] — source count 7 → 8; convergence note (no change to the spine — this source *restates* it). +- `index.md`, `log.md` updated. diff --git a/wiki/sources/2026-07-24-youre-reading-way-too-much-code.md b/wiki/sources/2026-07-24-youre-reading-way-too-much-code.md new file mode 100644 index 0000000..993dcec --- /dev/null +++ b/wiki/sources/2026-07-24-youre-reading-way-too-much-code.md @@ -0,0 +1,48 @@ +# You're reading way too much code — Theo Browne + +#source + +## Source Metadata + +- **Date:** YouTube video (publication date not stated in source), 24:11 — https://www.youtube.com/watch?v=434cG4g5KLE +- **Raw path:** `raw/sources/You're reading way too much code.md` +- **Source type:** video essay (conclusions/notes) +- **Speaker:** [[theo-browne]] (t3.gg / T3 / Lakebed) +- **Ingestion date:** 2026-07-24 + +## Core Claims + +- The problem isn't reading too much code in absolute terms — it's reading too high a *percentage*, because engineers aren't **generating enough code that doesn't matter**. "I'm not telling you to make your code cheaper. I'm telling you to make more cheap code." See [[make-more-cheap-code]]. +- **The importance-of-code spectrum** runs from "slop website with one viewer" to "pacemaker firmware." The AI-code debate stalls because people (a) overestimate where they sit on it and (b) project every claim they hear onto their own tier. +- **Four tiers of code** (A slop / B "I'd like this to work" / C "trouble if it breaks" / D death tier), each with its own reading discipline — from "never read it" (A) to "read every line" (D). Nobody works 100% in D. +- **Steelman granted, then inverted:** if your production code could kill someone, that's a reason to read every shipped line *and* to generate 100–10,000× more throwaway code to verify it. "Every line of code that goes in should have 100 lines of slop verifying it." +- **There is always another layer:** if the core is too important for AI, abstract up — custom debuggers, runtimes, lint rules, load rigs. If the verification tools are too important, build tools that introspect *them*. +- What changed: writing is nearly free, **reading still costs attention** — so the generated-to-read ratio should skyrocket while hand-verification of shipped code stays the same or increases. +- Explicit anti-endorsements: merging unreviewed slop, reducing verification of shipped code, "move faster" as an end. "I hate them too. We're on the same side" (re: vibe-coders shipping slop). + +## Key Evidence / Details + +- **Ratio shift (his own numbers):** pre-AI ~1,000 read / 200 written / 100 merged per day; now ~1,000 read / 2,000+ written / ~500 merged — the unmerged bulk exists to test ideas and is never reviewed. Reframing chart for a tier-D engineer: read goes *up* in absolute terms (200→400), slop goes 0→800+, merged stays ~100. +- **Shao's ratio (cited approvingly):** ~80% of AI-generated code goes into test harnesses and guardrails, with harness results fed back into the LLM's context — fewer mistakes overall. +- **Concrete slop patterns:** on-demand custom lint rules for a found bug pattern; one-off debuggers; slop-porting a Go service to Rust just to benchmark the test suite; **10 dumb-model agents building on a fresh API — their failures are UX bugs in the API**; agent with AWS access spinning up throwaway load rigs; testing 3 theories of an ambiguous PR in parallel; bespoke one-off test suites. +- **Tier-C reading tricks (via a Dax post):** after a big diff, ask the agent for a per-file summary instead of reading the diff — "anything weird will stick out"; read function signatures and API definitions always, care less about bodies. Theo's Lakebed version: read every signature/API, use slop (the 10-dumb-agents test) to verify them. +- "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." +- Closing principles: code is useful for things other than shipping; draw the ship/no-ship line and apply discipline separately per side; if you can't find slop opportunities "you're not creative enough"; don't read faster — read only what's worth reading; have AI review code before humans do. + +## Connections + +- **Entity:** [[theo-browne]] (his second source in the vault) +- **Concepts:** [[make-more-cheap-code]] (created from this source) · [[code-as-throwaway]] (this source answers its open question: the durable artifact includes the *verification harness*) · [[think-wider-not-bigger]] (same author-move: reframe a human-side habit as the bottleneck) · [[leave-less-room-for-imagination]] (tension: agent-summary-instead-of-diff vs Eugene's invisible collateral damage — logged there) · [[product-ownership]] (verifying as the human's remaining job) · [[context-as-scarce-resource]] (reading costs attention — the human-side analog) +- **Related sources:** [[2026-07-14-everything-we-knew-about-software-has-changed]] (his earlier talk: code disposable, kill without guilt — this source supplies the *discipline* for that stance); [[2026-07-21-larysa-interview]] (Eugene's trust carve-out and invisible-drift worry — the audience this source's tier framework speaks to) +- **Tools/people mentioned:** Codex, AWS, Grok-tier models, Dax, Shao, Lakebed + +## Open Questions + +- Shao's "~80% into harnesses, fewer mistakes overall" is cited without data — is there any measured before/after? Status: tentative. +- The tier framework assumes you can cleanly separate ship-code from slop; where do skills/prompts/CLAUDE.md files (which *do* persist and steer future generations) fall on the A–D spectrum? +- Does the "agent per-file summary instead of the diff" practice survive Eugene's objection that drift is precisely what a summary hides? (Logged as a tension in [[leave-less-room-for-imagination]].) + +## Change Impact on Wiki + +- Created [[make-more-cheap-code]] (concept — throwaway generation for verification/exploration; four tiers; always-another-layer). +- Updated [[code-as-throwaway]] (verification as the durable use of cheap code; partial answer to its "what is the durable artifact" question), [[theo-browne]] (second source; sharpened stance — explicitly anti-slop-shipping), [[leave-less-room-for-imagination]] (new logged tension on diff summaries vs invisible drift), [[2026-07-14-everything-we-knew-about-software-has-changed]] (reciprocal related-source link), [[overview]] (8→9 sources; "verifying" half of the spine deepened). diff --git a/wiki/timelines/.gitkeep b/wiki/timelines/.gitkeep new file mode 100644 index 0000000..e69de29 diff --git a/wiki/timelines/ai-agent-evolution.md b/wiki/timelines/ai-agent-evolution.md new file mode 100644 index 0000000..0035956 --- /dev/null +++ b/wiki/timelines/ai-agent-evolution.md @@ -0,0 +1,43 @@ +# Timeline: AI Agent Evolution + +#timeline + +Chronological reconstruction of how AI agents evolved, combining [[konstantin]]'s tooling/agent timeline with [[theo-browne]]'s model eras. Dates are as stated by the speakers (approximate; some are framing rather than precise release dates). Status: **tentative** where noted. + +## Agent architecture & tooling (Konstantin) + +| Period | Milestone | Significance | +| --------------- | ----------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | +| Early 2023 | LLM / ChatGPT (pre-chat): ask → answer | No memory, no tools, single-turn | +| Summer 2023 | **ReAct agents** — LLM can answer *or* call a function | First "agent loop"; tools give the LLM feedback. See [[agentic-loops]] | +| 2023–2024 | Call chains, roles, first agent SDKs, vector DBs, **RAG**, JSON outputs | Agents use external knowledge | +| 2024 | Chains → **graphs** (LangGraph); multi-agent (planner/critic); AutoGen, CrewAI; heavy **scaffolding** | Peak technical complexity | +| Late 2025 | **Simplification** — a simple agent with ~10 file ops solves hard tasks; era of **universal agents = [[harness\|harnesses]]** | Complexity drops, capability rises | +| 2026 (now) | Harnesses wrapped in outer loops (**Ralph loop**), run for days; **AI factory** (no human-in-the-loop) | human-in-the-middle → man-on-the-middle → no human | +| 2027 (forecast) | Dominance of **[[skills-as-memory\|skills]] + [[agentic-loops\|agent loops]]** | — | + +**Tooling generations** (see [[evolution-of-agent-tooling]]): Tools (2022–2024) → MCP (late 2024–2025) → Skills (2025→). + +**Human-role ladder** (see [[context-as-scarce-resource]]): prompt-engineer → context-engineer → harness-builder → loop-engineer. + +## Model capability eras (Theo Browne) + +Speaker's framing; model-name→ID mapping is **unverified/tentative** (see [[theo-browne]]). + +| Era | Representative model (speaker's term) | Unlocked | +|---|---|---| +| **Tool-call era** | "Sonnet 3.5" | First reliable tool calls inside a real codebase | +| **Long-running-task era** | "Opus 4.5" | Multi-hour tasks; self-run/test (his "AI psychosis" began Nov–Dec 2024) | +| **Orchestration era** | "Mythos / Fable" | Understands *itself*; spawns sub-models; verifies afterward — a prompt replaces a software factory | + +The two timelines rhyme: Konstantin's "universal harness → loops → AI factory" is the *system* view of Theo's "orchestration era" *model* capability. See [[think-wider-not-bigger]]. + +## Related Pages + +- Concepts: [[harness]], [[skills-as-memory]], [[evolution-of-agent-tooling]], [[agentic-loops]], [[context-as-scarce-resource]], [[think-wider-not-bigger]] +- Sources: [[2026-07-14-skills-based-on-git]], [[2026-07-14-everything-we-knew-about-software-has-changed]] + +## Uncertainty + +- Konstantin: "everything changes every 6 months — nothing is fundamental yet." Treat 2027 as a forecast. +- Theo's model-era names are rhetorical; do not treat as official release labels.