chore: initial commit of vault before dashboard work
This commit is contained in:
0
wiki/comparisons/.gitkeep
Normal file
0
wiki/comparisons/.gitkeep
Normal file
86
wiki/comparisons/theo-konstantin-allie.md
Normal file
86
wiki/comparisons/theo-konstantin-allie.md
Normal file
@@ -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"?
|
||||
0
wiki/concepts/.gitkeep
Normal file
0
wiki/concepts/.gitkeep
Normal file
36
wiki/concepts/agentic-loops.md
Normal file
36
wiki/concepts/agentic-loops.md
Normal 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?
|
||||
39
wiki/concepts/code-as-throwaway.md
Normal file
39
wiki/concepts/code-as-throwaway.md
Normal 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 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.)*
|
||||
37
wiki/concepts/connections-as-moat.md
Normal file
37
wiki/concepts/connections-as-moat.md
Normal 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 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.
|
||||
41
wiki/concepts/context-as-scarce-resource.md
Normal file
41
wiki/concepts/context-as-scarce-resource.md
Normal 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 ~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?
|
||||
31
wiki/concepts/decoupling-identity-from-profession.md
Normal file
31
wiki/concepts/decoupling-identity-from-profession.md
Normal 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?
|
||||
33
wiki/concepts/enterprise-ai-reality.md
Normal file
33
wiki/concepts/enterprise-ai-reality.md
Normal 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?
|
||||
36
wiki/concepts/evolution-of-agent-tooling.md
Normal file
36
wiki/concepts/evolution-of-agent-tooling.md
Normal 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 (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?
|
||||
43
wiki/concepts/harness.md
Normal file
43
wiki/concepts/harness.md
Normal 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"), ~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?
|
||||
41
wiki/concepts/integration-dead-ends.md
Normal file
41
wiki/concepts/integration-dead-ends.md
Normal 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?
|
||||
43
wiki/concepts/leave-less-room-for-imagination.md
Normal file
43
wiki/concepts/leave-less-room-for-imagination.md
Normal 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?
|
||||
37
wiki/concepts/levels-of-ai-usage.md
Normal file
37
wiki/concepts/levels-of-ai-usage.md
Normal 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?
|
||||
38
wiki/concepts/make-more-cheap-code.md
Normal file
38
wiki/concepts/make-more-cheap-code.md
Normal 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 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?
|
||||
49
wiki/concepts/network-from-a-standing-start.md
Normal file
49
wiki/concepts/network-from-a-standing-start.md
Normal 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 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.)
|
||||
41
wiki/concepts/personal-ai-operating-system.md
Normal file
41
wiki/concepts/personal-ai-operating-system.md
Normal 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; 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?
|
||||
32
wiki/concepts/product-ownership.md
Normal file
32
wiki/concepts/product-ownership.md
Normal 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?
|
||||
31
wiki/concepts/seniority-and-the-junior-squeeze.md
Normal file
31
wiki/concepts/seniority-and-the-junior-squeeze.md
Normal 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 **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?
|
||||
42
wiki/concepts/skills-as-memory.md
Normal file
42
wiki/concepts/skills-as-memory.md
Normal 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.
|
||||
37
wiki/concepts/solve-first-then-skillify.md
Normal file
37
wiki/concepts/solve-first-then-skillify.md
Normal 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?
|
||||
31
wiki/concepts/think-wider-not-bigger.md
Normal file
31
wiki/concepts/think-wider-not-bigger.md
Normal 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?
|
||||
0
wiki/entities/.gitkeep
Normal file
0
wiki/entities/.gitkeep
Normal file
31
wiki/entities/allie-miller.md
Normal file
31
wiki/entities/allie-miller.md
Normal file
@@ -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.)
|
||||
42
wiki/entities/claude-code.md
Normal file
42
wiki/entities/claude-code.md
Normal file
@@ -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?
|
||||
39
wiki/entities/eugene.md
Normal file
39
wiki/entities/eugene.md
Normal file
@@ -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.)
|
||||
30
wiki/entities/hermes.md
Normal file
30
wiki/entities/hermes.md
Normal file
@@ -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?
|
||||
28
wiki/entities/inspectron.md
Normal file
28
wiki/entities/inspectron.md
Normal file
@@ -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]])?
|
||||
33
wiki/entities/konstantin.md
Normal file
33
wiki/entities/konstantin.md
Normal file
@@ -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")?
|
||||
39
wiki/entities/larysa.md
Normal file
39
wiki/entities/larysa.md
Normal file
@@ -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?
|
||||
30
wiki/entities/nina.md
Normal file
30
wiki/entities/nina.md
Normal file
@@ -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?
|
||||
30
wiki/entities/sebastian.md
Normal file
30
wiki/entities/sebastian.md
Normal file
@@ -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.)
|
||||
36
wiki/entities/theo-browne.md
Normal file
36
wiki/entities/theo-browne.md
Normal file
@@ -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.)
|
||||
36
wiki/entities/virtido.md
Normal file
36
wiki/entities/virtido.md
Normal file
@@ -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?
|
||||
31
wiki/entities/yulia.md
Normal file
31
wiki/entities/yulia.md
Normal file
@@ -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.
|
||||
0
wiki/lint-reports/.gitkeep
Normal file
0
wiki/lint-reports/.gitkeep
Normal file
46
wiki/overview.md
Normal file
46
wiki/overview.md
Normal file
@@ -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.
|
||||
0
wiki/queries/.gitkeep
Normal file
0
wiki/queries/.gitkeep
Normal file
35
wiki/queries/2026-07-14-best-first-skill-for-beginner.md
Normal file
35
wiki/queries/2026-07-14-best-first-skill-for-beginner.md
Normal file
@@ -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.
|
||||
55
wiki/queries/2026-07-14-network-from-standing-start.md
Normal file
55
wiki/queries/2026-07-14-network-from-standing-start.md
Normal file
@@ -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`.
|
||||
59
wiki/queries/2026-07-22-webinar-theses.md
Normal file
59
wiki/queries/2026-07-22-webinar-theses.md
Normal file
@@ -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.
|
||||
@@ -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`.
|
||||
0
wiki/sources/.gitkeep
Normal file
0
wiki/sources/.gitkeep
Normal file
@@ -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.
|
||||
50
wiki/sources/2026-07-14-gap-between-ai-users-irreversible.md
Normal file
50
wiki/sources/2026-07-14-gap-between-ai-users-irreversible.md
Normal file
@@ -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]].
|
||||
48
wiki/sources/2026-07-14-nina-interview.md
Normal file
48
wiki/sources/2026-07-14-nina-interview.md
Normal file
@@ -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).
|
||||
50
wiki/sources/2026-07-14-sebastian-eugene-interview.md
Normal file
50
wiki/sources/2026-07-14-sebastian-eugene-interview.md
Normal file
@@ -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).
|
||||
53
wiki/sources/2026-07-14-skills-based-on-git.md
Normal file
53
wiki/sources/2026-07-14-skills-based-on-git.md
Normal file
@@ -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.
|
||||
48
wiki/sources/2026-07-14-yulia-interview.md
Normal file
48
wiki/sources/2026-07-14-yulia-interview.md
Normal file
@@ -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]].
|
||||
51
wiki/sources/2026-07-21-larysa-interview.md
Normal file
51
wiki/sources/2026-07-21-larysa-interview.md
Normal file
@@ -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]].
|
||||
47
wiki/sources/2026-07-22-ai-is-stupid.md
Normal file
47
wiki/sources/2026-07-22-ai-is-stupid.md
Normal file
@@ -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.
|
||||
48
wiki/sources/2026-07-24-youre-reading-way-too-much-code.md
Normal file
48
wiki/sources/2026-07-24-youre-reading-way-too-much-code.md
Normal file
@@ -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).
|
||||
0
wiki/timelines/.gitkeep
Normal file
0
wiki/timelines/.gitkeep
Normal file
43
wiki/timelines/ai-agent-evolution.md
Normal file
43
wiki/timelines/ai-agent-evolution.md
Normal file
@@ -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.
|
||||
Reference in New Issue
Block a user