chore: initial commit of vault before dashboard work

This commit is contained in:
meels
2026-07-28 13:00:04 +02:00
commit b75730fda3
86 changed files with 7130 additions and 0 deletions

0
wiki/concepts/.gitkeep Normal file
View File

View File

@@ -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?

View File

@@ -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 10010,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.)*

View File

@@ -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 24 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.

View File

@@ -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 ~3040 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?

View File

@@ -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?

View File

@@ -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?

View File

@@ -0,0 +1,36 @@
# Evolution of Agent Tooling (Tools → MCP → Skills)
#concept
## Summary
Konstantin's three-generation map of how agents get capabilities: **Tools (20222024) → MCP (late 20242025) → 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 ~550; 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?

43
wiki/concepts/harness.md Normal file
View File

@@ -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"), ~1040 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:** >3040 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?

View File

@@ -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?

View File

@@ -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?

View File

@@ -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?

View File

@@ -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 AB 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 AD 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?

View File

@@ -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 24 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 24 days/week number is a founder's, not a bootstrapper's)?
- Does the webinar → paid-build chain complete? (The live case study's outcome.)

View File

@@ -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; 210× 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?

View File

@@ -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?

View File

@@ -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 **23 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 23 — [[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?

View File

@@ -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.

View File

@@ -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?

View File

@@ -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?