Compare commits
11 Commits
51c85e6994
...
master
| Author | SHA1 | Date | |
|---|---|---|---|
|
3314112bb9 | ||
|
|
62d0f06a2d | ||
|
|
2685fc9ba2 | ||
|
|
1361dd76f9 | ||
|
|
ef2e2bd14f | ||
|
|
605e57751c | ||
|
|
4803c009a2 | ||
|
|
81676e9daa | ||
|
|
70b9e2a44f | ||
|
|
c374099a12 | ||
|
|
5de50b155a |
7
.gitattributes
vendored
7
.gitattributes
vendored
@@ -1,7 +0,0 @@
|
||||
# Obsidian on Windows writes CRLF; git's default autocrlf then reports files as
|
||||
# modified when only line endings differ. That noise matters here: after a
|
||||
# headless ingest, `git diff HEAD` is the review surface for what the agent
|
||||
# wrote, and it is useless if every untouched file also shows as changed.
|
||||
#
|
||||
# Store bytes exactly as they are on disk, no conversion in either direction.
|
||||
* -text
|
||||
3
.gitignore
vendored
3
.gitignore
vendored
@@ -1,3 +0,0 @@
|
||||
.obsidian/workspace.json
|
||||
.obsidian/workspace-mobile.json
|
||||
.obsidian/cache
|
||||
3
.obsidian/community-plugins.json
vendored
3
.obsidian/community-plugins.json
vendored
@@ -1,3 +0,0 @@
|
||||
[
|
||||
"webinar-dash"
|
||||
]
|
||||
2
.obsidian/graph.json
vendored
2
.obsidian/graph.json
vendored
@@ -17,6 +17,6 @@
|
||||
"repelStrength": 10,
|
||||
"linkStrength": 1,
|
||||
"linkDistance": 250,
|
||||
"scale": 0.999999999999998,
|
||||
"scale": 0.5087618855792575,
|
||||
"close": false
|
||||
}
|
||||
601
.obsidian/plugins/webinar-dash/main.js
vendored
601
.obsidian/plugins/webinar-dash/main.js
vendored
@@ -1,601 +0,0 @@
|
||||
"use strict";
|
||||
|
||||
// Obsidian injects its own module resolver. Under plain `node --test` it is
|
||||
// absent, so guard the require and fall back to an empty base class. This is
|
||||
// what keeps the pure helpers below unit-testable without an Obsidian runtime.
|
||||
let OB = null;
|
||||
try {
|
||||
OB = require("obsidian");
|
||||
} catch (_) {
|
||||
OB = null;
|
||||
}
|
||||
const PluginBase = OB ? OB.Plugin : class {};
|
||||
|
||||
const STATIONS = ["Chat box", "ReAct", "Tools", "Memory", "Skills", "Process", "OS"];
|
||||
|
||||
const DEFAULTS = {
|
||||
script: "raw/sources/Webinar script.md",
|
||||
coverage: "wiki/script-coverage.md",
|
||||
rawDir: "raw/sources",
|
||||
wikiSourceDir: "wiki/sources",
|
||||
conceptDir: "wiki/concepts",
|
||||
};
|
||||
|
||||
const RAW_PATH_RE = /^\s*-\s*\*\*Raw path:\*\*\s*`([^`]+)`/m;
|
||||
|
||||
function extractRawPath(text) {
|
||||
const m = String(text).match(RAW_PATH_RE);
|
||||
return m ? m[1].trim() : null;
|
||||
}
|
||||
|
||||
function derivePipeline({ rawFiles, sourcePages }) {
|
||||
// First claim on a raw path wins. A later page claiming the same file is a
|
||||
// duplicate claim — real catalog drift — and joins `orphaned` rather than
|
||||
// being silently dropped. `orphaned` therefore means "source page not paired
|
||||
// with a raw file", whatever the reason.
|
||||
const claimed = new Map();
|
||||
const duplicates = [];
|
||||
for (const page of sourcePages) {
|
||||
if (!page.rawPath) continue;
|
||||
if (claimed.has(page.rawPath)) duplicates.push(page);
|
||||
else claimed.set(page.rawPath, page);
|
||||
}
|
||||
|
||||
const processed = [];
|
||||
const unprocessed = [];
|
||||
for (const file of rawFiles) {
|
||||
const page = claimed.get(file.path);
|
||||
if (page) processed.push(Object.assign({}, file, { page }));
|
||||
else unprocessed.push(file);
|
||||
}
|
||||
|
||||
// One pass over sourcePages, so a page appears in `orphaned` at most once no
|
||||
// matter how many of the three reasons apply to it. Concatenating a separate
|
||||
// duplicates array here would double-count a losing claimant whose shared raw
|
||||
// path is also missing from disk.
|
||||
const rawPaths = new Set(rawFiles.map((f) => f.path));
|
||||
const duplicateSet = new Set(duplicates);
|
||||
const orphaned = sourcePages.filter(
|
||||
(p) => duplicateSet.has(p) || !p.rawPath || !rawPaths.has(p.rawPath)
|
||||
);
|
||||
|
||||
unprocessed.sort((a, b) => a.name.localeCompare(b.name));
|
||||
processed.sort((a, b) => b.page.name.localeCompare(a.page.name));
|
||||
|
||||
return { processed, unprocessed, orphaned };
|
||||
}
|
||||
|
||||
const VALID_STATUS = new Set(["covered", "partial", "absent"]);
|
||||
const SEPARATOR_RE = /^\|?\s*:?-{2,}/;
|
||||
|
||||
function parseCoverageTable(markdown) {
|
||||
const text = String(markdown);
|
||||
const meta = { script: null, lastSynced: null };
|
||||
|
||||
const scriptM = text.match(/^\s*-\s*\*\*Script:\*\*\s*`([^`]+)`/m);
|
||||
if (scriptM) meta.script = scriptM[1].trim();
|
||||
const syncM = text.match(/^\s*-\s*\*\*Last synced:\*\*\s*(\S+)/m);
|
||||
if (syncM) meta.lastSynced = syncM[1].trim();
|
||||
|
||||
const rows = [];
|
||||
const errors = [];
|
||||
let inTable = false;
|
||||
|
||||
text.split(/\r?\n/).forEach((line, i) => {
|
||||
const t = line.trim();
|
||||
if (!t.startsWith("|")) {
|
||||
inTable = false;
|
||||
return;
|
||||
}
|
||||
if (SEPARATOR_RE.test(t)) {
|
||||
inTable = true;
|
||||
return;
|
||||
}
|
||||
if (!inTable) return;
|
||||
|
||||
const body = t.endsWith("|") ? t.slice(1, -1) : t.slice(1);
|
||||
// Split on unescaped pipes only. Obsidian escapes the pipe of a piped
|
||||
// wikilink inside a table cell as `\|`, and a plain split("|") tears
|
||||
// `[[harness\|alias]]` into two cells, shifting every later column left.
|
||||
const cells = body.split(/(?<!\\)\|/).map((c) => c.trim());
|
||||
|
||||
if (cells.length < 3) {
|
||||
errors.push({ line: i + 1, text: t, reason: "expected at least 3 columns" });
|
||||
return;
|
||||
}
|
||||
|
||||
const status = cells[1].toLowerCase();
|
||||
if (!VALID_STATUS.has(status)) {
|
||||
errors.push({ line: i + 1, text: t, reason: `invalid status "${cells[1]}"` });
|
||||
return;
|
||||
}
|
||||
|
||||
// Capture up to the first ] | or backslash. Obsidian escapes the pipe in a
|
||||
// piped wikilink inside a table cell, so the raw cell reads [[name\|alias]] —
|
||||
// excluding the backslash is what keeps the trailing "\" out of the name.
|
||||
const linkM = cells[0].match(/\[\[([^\]|\\]+)/);
|
||||
const stationCell = cells[2];
|
||||
|
||||
rows.push({
|
||||
concept: linkM ? linkM[1].trim() : cells[0],
|
||||
status,
|
||||
stations:
|
||||
stationCell === "—" || stationCell === "-" || stationCell === ""
|
||||
? []
|
||||
: stationCell.split(",").map((s) => s.trim()).filter(Boolean),
|
||||
pinned: (cells[3] || "").toLowerCase() === "yes",
|
||||
line: i + 1,
|
||||
});
|
||||
});
|
||||
|
||||
return { meta, rows, errors };
|
||||
}
|
||||
|
||||
function groupByStation(rows) {
|
||||
const order = ["All stations", ...STATIONS, "No station"];
|
||||
const buckets = new Map(order.map((k) => [k, []]));
|
||||
|
||||
for (const row of rows) {
|
||||
let key;
|
||||
if (row.stations.includes("all")) key = "All stations";
|
||||
else if (row.stations.length === 0) key = "No station";
|
||||
else key = row.stations[0];
|
||||
if (!buckets.has(key)) buckets.set(key, []);
|
||||
buckets.get(key).push(row);
|
||||
}
|
||||
|
||||
const known = order.filter((k) => buckets.get(k).length > 0);
|
||||
const unknown = [...buckets.keys()].filter((k) => !order.includes(k) && buckets.get(k).length > 0);
|
||||
return [...known, ...unknown].map((station) => ({ station, rows: buckets.get(station) }));
|
||||
}
|
||||
|
||||
function reconcileConcepts(rows, conceptNames) {
|
||||
const named = new Set(conceptNames);
|
||||
const rowed = new Set(rows.map((r) => r.concept));
|
||||
return {
|
||||
rows,
|
||||
unsynced: conceptNames.filter((n) => !rowed.has(n)).sort(),
|
||||
stale: rows.filter((r) => !named.has(r.concept)),
|
||||
};
|
||||
}
|
||||
|
||||
// Defence in depth. The spawn path no longer uses a shell, so nothing here is
|
||||
// load-bearing against injection today — but the guard costs nothing and would
|
||||
// still hold if the single-string `shell: true` form is ever needed for a .cmd
|
||||
// shim. `^` is cmd.exe's escape character; control characters are rejected
|
||||
// because a NUL byte makes spawn() throw synchronously.
|
||||
//
|
||||
// Apostrophes, spaces, cyrillic, em dashes and `!` stay allowed — they appear in
|
||||
// real filenames in this vault.
|
||||
const UNSAFE_CHARS = /["`$&|;<>%^\u0000-\u001f\u007f]/;
|
||||
|
||||
function isSafeFilename(name) {
|
||||
if (typeof name !== "string" || name.length === 0) return false;
|
||||
if (UNSAFE_CHARS.test(name)) return false;
|
||||
if (name.includes("..")) return false;
|
||||
return true;
|
||||
}
|
||||
|
||||
function parseConfig(source) {
|
||||
const cfg = Object.assign({}, DEFAULTS);
|
||||
for (const line of String(source).split(/\r?\n/)) {
|
||||
const m = line.match(/^\s*([A-Za-z][A-Za-z0-9_]*)\s*:\s*(.+?)\s*$/);
|
||||
if (m && Object.prototype.hasOwnProperty.call(DEFAULTS, m[1])) {
|
||||
cfg[m[1]] = m[2];
|
||||
}
|
||||
}
|
||||
return cfg;
|
||||
}
|
||||
|
||||
// Source types CLAUDE.md documents for raw/sources. Anything else in that
|
||||
// folder is not a source and stays out of the queue.
|
||||
const RAW_EXTENSIONS = new Set(["md", "txt", "pdf"]);
|
||||
|
||||
const ICONS = {
|
||||
terminal: "M4 17l6-6-6-6M12 19h8",
|
||||
check: "M20 6 9 17l-5-5",
|
||||
minus: "M5 12h14",
|
||||
x: "M18 6 6 18M6 6l12 12",
|
||||
refresh: "M3 12a9 9 0 0 1 9-9 9 9 0 0 1 6.7 3L21 8M21 3v5h-5 M21 12a9 9 0 0 1-9 9 9 9 0 0 1-6.7-3L3 16M3 21v-5h5",
|
||||
};
|
||||
|
||||
// Built with createElementNS rather than Obsidian's createSvg helper, whose
|
||||
// availability varies by version. This works on any Obsidian build.
|
||||
const SVG_NS = "http://www.w3.org/2000/svg";
|
||||
|
||||
function addIcon(parent, name) {
|
||||
const svg = document.createElementNS(SVG_NS, "svg");
|
||||
svg.setAttribute("viewBox", "0 0 24 24");
|
||||
svg.setAttribute("fill", "none");
|
||||
svg.setAttribute("aria-hidden", "true");
|
||||
const path = document.createElementNS(SVG_NS, "path");
|
||||
path.setAttribute("d", ICONS[name]);
|
||||
path.setAttribute("stroke", "currentColor");
|
||||
path.setAttribute("stroke-width", "1.75");
|
||||
path.setAttribute("stroke-linecap", "round");
|
||||
path.setAttribute("stroke-linejoin", "round");
|
||||
svg.appendChild(path);
|
||||
parent.appendChild(svg);
|
||||
return svg;
|
||||
}
|
||||
|
||||
function formatBytes(n) {
|
||||
return `${n.toLocaleString("en-US")} B`;
|
||||
}
|
||||
|
||||
function renderLeftPane(container, pipeline, onIngest, gate) {
|
||||
const pane = container.createDiv({ cls: "wd-pane" });
|
||||
|
||||
const queue = pane.createDiv({ cls: "wd-block" });
|
||||
queue.createDiv({
|
||||
cls: "wd-eyebrow",
|
||||
text: `Queue — ${pipeline.unprocessed.length} unprocessed`,
|
||||
});
|
||||
if (pipeline.unprocessed.length === 0) {
|
||||
queue.createDiv({ cls: "wd-note", text: "Every raw source has a summary page." });
|
||||
}
|
||||
for (const file of pipeline.unprocessed) {
|
||||
const row = queue.createDiv({ cls: "wd-row" });
|
||||
const main = row.createDiv({ cls: "wd-row-main" });
|
||||
main.createDiv({ cls: "wd-row-name", text: file.name });
|
||||
main.createDiv({ cls: "wd-mono", text: formatBytes(file.size) });
|
||||
const btn = row.createEl("button", { cls: "wd-btn" });
|
||||
addIcon(btn, "terminal");
|
||||
btn.createSpan({ text: "Ingest" });
|
||||
if (gate && !gate.ok) {
|
||||
btn.disabled = true;
|
||||
btn.setAttr("title", gate.reason);
|
||||
} else {
|
||||
btn.addEventListener("click", () => onIngest(file, row));
|
||||
}
|
||||
}
|
||||
|
||||
const done = pane.createDiv({ cls: "wd-block" });
|
||||
done.createDiv({ cls: "wd-eyebrow", text: `Ingested — ${pipeline.processed.length}` });
|
||||
const list = done.createDiv({ cls: "wd-done" });
|
||||
for (const file of pipeline.processed) {
|
||||
const row = list.createDiv({ cls: "wd-done-row" });
|
||||
const date = file.page.name.slice(0, 10);
|
||||
row.createSpan({ cls: "wd-mono", text: /^\d{4}-\d{2}-\d{2}$/.test(date) ? date : "—" });
|
||||
row.createSpan({ cls: "wd-done-name", text: file.name.replace(/\.md$/, "") });
|
||||
}
|
||||
|
||||
if (pipeline.orphaned.length > 0) {
|
||||
const orphan = pane.createDiv({ cls: "wd-block" });
|
||||
orphan.createDiv({
|
||||
cls: "wd-eyebrow",
|
||||
text: `Orphaned — ${pipeline.orphaned.length}`,
|
||||
});
|
||||
for (const page of pipeline.orphaned) {
|
||||
const row = orphan.createDiv({ cls: "wd-done-row" });
|
||||
row.createSpan({ cls: "wd-done-name", text: page.name });
|
||||
row.createSpan({ cls: "wd-mono", text: page.rawPath || "no raw path" });
|
||||
}
|
||||
}
|
||||
|
||||
return pane;
|
||||
}
|
||||
|
||||
const STATUS_ICON = { covered: "check", partial: "minus", absent: "x" };
|
||||
|
||||
function renderRightPane(container, parsed, reconciled, cfg) {
|
||||
const pane = container.createDiv({ cls: "wd-pane" });
|
||||
pane.createDiv({ cls: "wd-eyebrow", text: "Coverage — by station" });
|
||||
|
||||
const meta = parsed.meta || {};
|
||||
pane.createDiv({
|
||||
cls: "wd-mono",
|
||||
text: `${meta.script || "no script recorded"} — last synced ${meta.lastSynced || "never"}`,
|
||||
});
|
||||
if (cfg && cfg.script && meta.script && meta.script !== cfg.script) {
|
||||
pane.createDiv({
|
||||
cls: "wd-error",
|
||||
text: `This dashboard is configured for ${cfg.script}, but the coverage file tracks ${meta.script}.`,
|
||||
});
|
||||
}
|
||||
|
||||
const counts = { covered: 0, partial: 0, absent: 0 };
|
||||
for (const row of parsed.rows) counts[row.status] += 1;
|
||||
const total = parsed.rows.length;
|
||||
|
||||
if (total > 0) {
|
||||
const meter = pane.createDiv({ cls: "wd-meter" });
|
||||
meter.setAttr("role", "img");
|
||||
meter.setAttr(
|
||||
"aria-label",
|
||||
`Coverage: ${counts.covered} covered, ${counts.partial} partial, ${counts.absent} absent of ${total}`
|
||||
);
|
||||
for (const key of ["covered", "partial", "absent"]) {
|
||||
if (counts[key] === 0) continue;
|
||||
const seg = meter.createEl("i", { cls: `wd-seg-${key}` });
|
||||
seg.style.flex = String(counts[key]);
|
||||
}
|
||||
const key = pane.createDiv({ cls: "wd-key" });
|
||||
for (const name of ["covered", "partial", "absent"]) {
|
||||
const span = key.createSpan();
|
||||
span.createEl("i", { cls: `wd-seg-${name}` });
|
||||
span.createSpan({ text: `${counts[name]} ${name}` });
|
||||
}
|
||||
}
|
||||
|
||||
if (parsed.errors.length > 0) {
|
||||
const box = pane.createDiv({ cls: "wd-error" });
|
||||
box.createDiv({ text: `${parsed.errors.length} unparseable row(s):` });
|
||||
for (const e of parsed.errors) {
|
||||
box.createDiv({ cls: "wd-mono", text: `line ${e.line} — ${e.reason}` });
|
||||
}
|
||||
}
|
||||
|
||||
const table = pane.createEl("table", { cls: "wd-tbl" });
|
||||
const head = table.createEl("thead").createEl("tr");
|
||||
for (const h of ["Concept", "Status", "Station", ""]) head.createEl("th", { text: h });
|
||||
const body = table.createEl("tbody");
|
||||
|
||||
for (const group of groupByStation(parsed.rows)) {
|
||||
const gr = body.createEl("tr", { cls: "wd-grp" });
|
||||
gr.createEl("td", { attr: { colspan: "4" }, text: `${group.station} — ${group.rows.length}` });
|
||||
for (const row of group.rows) {
|
||||
const tr = body.createEl("tr");
|
||||
// Obsidian's click handler resolves internal links via data-href, so both
|
||||
// attributes are required for the link to open the concept page.
|
||||
tr.createEl("td").createEl("a", {
|
||||
cls: "internal-link",
|
||||
text: row.concept,
|
||||
attr: { href: row.concept, "data-href": row.concept },
|
||||
});
|
||||
const stat = tr.createEl("td").createSpan({ cls: `wd-stat wd-${row.status}` });
|
||||
addIcon(stat, STATUS_ICON[row.status]);
|
||||
stat.createSpan({ text: row.status });
|
||||
tr.createEl("td", { cls: "wd-mono", text: row.stations.join(", ") || "—" });
|
||||
tr.createEl("td", { cls: "wd-pin", text: row.pinned ? "pinned" : "" });
|
||||
}
|
||||
}
|
||||
|
||||
if (reconciled.unsynced.length > 0) {
|
||||
const box = pane.createDiv({ cls: "wd-block" });
|
||||
box.createDiv({ cls: "wd-eyebrow", text: `Unsynced — ${reconciled.unsynced.length}` });
|
||||
box.createDiv({
|
||||
cls: "wd-note",
|
||||
text: `Concept pages with no row. Run "sync script coverage": ${reconciled.unsynced.join(", ")}`,
|
||||
});
|
||||
}
|
||||
|
||||
if (reconciled.stale.length > 0) {
|
||||
const box = pane.createDiv({ cls: "wd-block" });
|
||||
box.createDiv({ cls: "wd-eyebrow", text: `Stale — ${reconciled.stale.length}` });
|
||||
box.createDiv({
|
||||
cls: "wd-note",
|
||||
text: `Rows whose concept page is gone: ${reconciled.stale.map((r) => r.concept).join(", ")}`,
|
||||
});
|
||||
}
|
||||
|
||||
return pane;
|
||||
}
|
||||
|
||||
class WebinarDashPlugin extends PluginBase {
|
||||
async onload() {
|
||||
this.running = new Set();
|
||||
this.registerMarkdownCodeBlockProcessor("webinar-dash", async (source, el, ctx) => {
|
||||
const cfg = parseConfig(source);
|
||||
const root = el.createDiv({ cls: "webinar-dash" });
|
||||
await this.renderAll(root, cfg);
|
||||
});
|
||||
}
|
||||
|
||||
async renderAll(root, cfg) {
|
||||
root.empty();
|
||||
const gate = this.spawnGate();
|
||||
const refresh = () => { this.renderAll(root, cfg); };
|
||||
|
||||
const bar = root.createDiv({ cls: "wd-bar" });
|
||||
const sync = bar.createEl("button", { cls: "wd-btn wd-btn-ghost" });
|
||||
addIcon(sync, "refresh");
|
||||
sync.createSpan({ text: "Sync coverage" });
|
||||
if (!gate.ok) {
|
||||
sync.disabled = true;
|
||||
sync.setAttr("title", gate.reason);
|
||||
} else {
|
||||
sync.addEventListener("click", () =>
|
||||
this.runClaude("__sync__", "sync script coverage", bar, "sync coverage", refresh)
|
||||
);
|
||||
}
|
||||
|
||||
const grid = root.createDiv({ cls: "wd-grid" });
|
||||
|
||||
try {
|
||||
const pipeline = await this.readPipeline(cfg);
|
||||
renderLeftPane(grid, pipeline, (file, rowEl) => this.runIngest(file, rowEl, refresh), gate);
|
||||
} catch (err) {
|
||||
grid.createDiv({ cls: "wd-error", text: `Pipeline failed: ${err.message}` });
|
||||
}
|
||||
|
||||
try {
|
||||
const { parsed, reconciled } = await this.readCoverage(cfg);
|
||||
renderRightPane(grid, parsed, reconciled, cfg);
|
||||
} catch (err) {
|
||||
grid.createDiv({ cls: "wd-error", text: `Coverage failed: ${err.message}` });
|
||||
}
|
||||
}
|
||||
|
||||
async readCoverage(cfg) {
|
||||
const file = this.app.vault.getAbstractFileByPath(cfg.coverage);
|
||||
if (!file) throw new Error(`no coverage file at ${cfg.coverage}`);
|
||||
const parsed = parseCoverageTable(await this.app.vault.cachedRead(file));
|
||||
|
||||
const conceptDir = cfg.conceptDir.replace(/\/+$/, "") + "/";
|
||||
const conceptNames = this.app.vault
|
||||
.getFiles()
|
||||
.filter((f) => f.path.startsWith(conceptDir) && f.extension === "md")
|
||||
.map((f) => f.basename);
|
||||
|
||||
return { parsed, reconciled: reconcileConcepts(parsed.rows, conceptNames) };
|
||||
}
|
||||
|
||||
async readPipeline(cfg) {
|
||||
const all = this.app.vault.getFiles();
|
||||
const rawDir = cfg.rawDir.replace(/\/+$/, "") + "/";
|
||||
const wikiDir = cfg.wikiSourceDir.replace(/\/+$/, "") + "/";
|
||||
|
||||
// CLAUDE.md documents raw/sources as holding "markdown/text/pdf exports".
|
||||
// Allow-listing only "md" would hide the others from the queue with no
|
||||
// warning — the same silent-invisibility failure this dashboard exists to
|
||||
// remove. Wiki source pages below stay markdown-only; those really are .md.
|
||||
const rawFiles = all
|
||||
.filter((f) => f.path.startsWith(rawDir) && RAW_EXTENSIONS.has(f.extension))
|
||||
.map((f) => ({ path: f.path, name: f.name, size: f.stat.size }));
|
||||
|
||||
const pageFiles = all.filter((f) => f.path.startsWith(wikiDir) && f.extension === "md");
|
||||
const sourcePages = [];
|
||||
for (const f of pageFiles) {
|
||||
const text = await this.app.vault.cachedRead(f);
|
||||
sourcePages.push({ path: f.path, name: f.name, rawPath: extractRawPath(text) });
|
||||
}
|
||||
|
||||
return derivePipeline({ rawFiles, sourcePages });
|
||||
}
|
||||
|
||||
vaultPath() {
|
||||
const adapter = this.app.vault.adapter;
|
||||
if (typeof adapter.getBasePath === "function") return adapter.getBasePath();
|
||||
return null;
|
||||
}
|
||||
|
||||
spawnGate() {
|
||||
if (!this.vaultPath()) {
|
||||
return { ok: false, reason: "Needs desktop Obsidian." };
|
||||
}
|
||||
try {
|
||||
require("child_process");
|
||||
} catch (_) {
|
||||
return { ok: false, reason: "child_process unavailable — needs desktop Obsidian." };
|
||||
}
|
||||
return { ok: true, reason: "" };
|
||||
}
|
||||
|
||||
// One subprocess runner for every button. `key` is what makes a run unique in
|
||||
// `this.running` — a file path for ingest, a constant for sync — so the guard
|
||||
// survives the row re-renders that a DOM-scoped guard could not.
|
||||
runClaude(key, prompt, hostEl, label, onSuccess) {
|
||||
const Notice = OB ? OB.Notice : null;
|
||||
const notify = (msg) => { if (Notice) new Notice(msg); };
|
||||
|
||||
if (this.running.has(key)) {
|
||||
notify(`Already running: ${label}.`);
|
||||
return;
|
||||
}
|
||||
|
||||
const gate = this.spawnGate();
|
||||
if (!gate.ok) {
|
||||
notify(gate.reason);
|
||||
return;
|
||||
}
|
||||
const { spawn } = require("child_process");
|
||||
const base = this.vaultPath();
|
||||
|
||||
// A retry reuses the same host element. Clear the previous run's status and
|
||||
// output so they are replaced rather than stacked.
|
||||
hostEl.querySelectorAll(".wd-status, .wd-output").forEach((el) => el.remove());
|
||||
|
||||
const button = hostEl.querySelector("button");
|
||||
if (button) button.disabled = true;
|
||||
this.running.add(key);
|
||||
|
||||
const status = hostEl.createSpan({ cls: "wd-status wd-status-running", text: "running 0s" });
|
||||
const output = hostEl.createDiv({ cls: "wd-output", text: "" });
|
||||
const started = Date.now();
|
||||
const timer = window.setInterval(() => {
|
||||
status.setText(`running ${Math.round((Date.now() - started) / 1000)}s`);
|
||||
}, 1000);
|
||||
this.registerInterval(timer);
|
||||
|
||||
// Bounded as it accumulates, not only when displayed.
|
||||
let buffered = "";
|
||||
const append = (text) => {
|
||||
buffered = (buffered + text).slice(-8000);
|
||||
output.setText(buffered);
|
||||
output.scrollTop = output.scrollHeight;
|
||||
};
|
||||
|
||||
// Node can emit both `error` and `close` for one failure. `settled` keeps the
|
||||
// first, more specific message instead of letting `exit null` overwrite it.
|
||||
let settled = false;
|
||||
const finish = (cls, text) => {
|
||||
if (settled) return;
|
||||
settled = true;
|
||||
window.clearInterval(timer);
|
||||
this.running.delete(key);
|
||||
status.className = `wd-status ${cls}`;
|
||||
status.setText(text);
|
||||
if (button) button.disabled = false;
|
||||
};
|
||||
|
||||
let child;
|
||||
try {
|
||||
// See the C1 comment in runIngest: no shell, deliberately.
|
||||
child = spawn("claude", ["-p", prompt], { cwd: base });
|
||||
} catch (err) {
|
||||
append(`\nCould not start claude: ${err.message}`);
|
||||
finish("wd-status-failed", "failed");
|
||||
return;
|
||||
}
|
||||
|
||||
child.stdout.setEncoding("utf8");
|
||||
child.stderr.setEncoding("utf8");
|
||||
child.stdout.on("data", append);
|
||||
child.stderr.on("data", append);
|
||||
|
||||
child.on("error", (err) => {
|
||||
append(`\nCould not start claude: ${err.message}\nIs it on PATH?`);
|
||||
finish("wd-status-failed", "failed");
|
||||
});
|
||||
|
||||
child.on("close", (code) => {
|
||||
const secs = Math.round((Date.now() - started) / 1000);
|
||||
if (code === 0) {
|
||||
finish("wd-status-done", `done in ${secs}s`);
|
||||
if (onSuccess) onSuccess();
|
||||
} else {
|
||||
finish("wd-status-failed", `failed - exit ${code}`);
|
||||
}
|
||||
});
|
||||
}
|
||||
|
||||
runIngest(file, rowEl, onSuccess) {
|
||||
const Notice = OB ? OB.Notice : null;
|
||||
|
||||
if (!isSafeFilename(file.name)) {
|
||||
rowEl.querySelectorAll(".wd-status, .wd-output").forEach((el) => el.remove());
|
||||
rowEl.createDiv({
|
||||
cls: "wd-output",
|
||||
text: `Refused: "${file.name}" contains a character that is unsafe to pass to a shell.`,
|
||||
});
|
||||
return;
|
||||
}
|
||||
|
||||
// `claude` resolves to a real .exe here, so libuv finds it via PATH and
|
||||
// PATHEXT with no shell involved. Do NOT add `shell: true`: with a shell,
|
||||
// Node concatenates argv without quoting and cmd.exe re-tokenizes, so the
|
||||
// prompt arrives as two arguments and the filename is silently discarded.
|
||||
// Verified: shell:true yields ["-p","ingest","Webinar script.md"], where the
|
||||
// program sees only "ingest". If a .cmd shim ever needs supporting, use the
|
||||
// single-string form spawn(`claude -p "ingest ${name}"`, { shell: true }).
|
||||
this.runClaude(
|
||||
file.path,
|
||||
`ingest "${file.name}"`,
|
||||
rowEl,
|
||||
file.name,
|
||||
() => {
|
||||
if (Notice) new Notice(`Ingested ${file.name}.`);
|
||||
if (onSuccess) onSuccess();
|
||||
}
|
||||
);
|
||||
}
|
||||
}
|
||||
|
||||
module.exports = WebinarDashPlugin;
|
||||
module.exports.default = WebinarDashPlugin;
|
||||
module.exports.__test__ = {
|
||||
parseConfig, extractRawPath, derivePipeline,
|
||||
parseCoverageTable, groupByStation, reconcileConcepts,
|
||||
STATIONS, DEFAULTS, isSafeFilename,
|
||||
};
|
||||
9
.obsidian/plugins/webinar-dash/manifest.json
vendored
9
.obsidian/plugins/webinar-dash/manifest.json
vendored
@@ -1,9 +0,0 @@
|
||||
{
|
||||
"id": "webinar-dash",
|
||||
"name": "Webinar dashboard",
|
||||
"version": "0.1.0",
|
||||
"minAppVersion": "1.5.0",
|
||||
"description": "Source pipeline and script coverage for the webinar vault.",
|
||||
"author": "meels",
|
||||
"isDesktopOnly": true
|
||||
}
|
||||
239
.obsidian/plugins/webinar-dash/styles.css
vendored
239
.obsidian/plugins/webinar-dash/styles.css
vendored
@@ -1,239 +0,0 @@
|
||||
.webinar-dash {
|
||||
--wd-ink-000: #ffffff; --wd-ink-050: #f7f7f7; --wd-ink-100: #ececec;
|
||||
--wd-ink-200: #d9d9d9; --wd-ink-400: #8a8a8a; --wd-ink-500: #5e5e5e;
|
||||
--wd-ink-700: #262626; --wd-ink-900: #0a0a0a; --wd-ink-999: #000000;
|
||||
--wd-red-500: #e1261c; --wd-red-600: #c31c14;
|
||||
|
||||
--wd-bg: var(--wd-ink-000);
|
||||
--wd-bg-subtle: var(--wd-ink-050);
|
||||
--wd-fg: var(--wd-ink-999);
|
||||
--wd-fg-2: var(--wd-ink-700);
|
||||
--wd-fg-3: var(--wd-ink-500);
|
||||
--wd-fg-4: var(--wd-ink-400);
|
||||
--wd-border: var(--wd-ink-200);
|
||||
--wd-border-strong: var(--wd-ink-999);
|
||||
--wd-border-subtle: var(--wd-ink-100);
|
||||
--wd-accent: var(--wd-red-500);
|
||||
--wd-accent-press: var(--wd-red-600);
|
||||
--wd-accent-on: #ffffff;
|
||||
--wd-ok: #0a8a3f;
|
||||
--wd-warn: #c68a00;
|
||||
--wd-danger: var(--wd-red-500);
|
||||
|
||||
--wd-mono: "JetBrains Mono", ui-monospace, SFMono-Regular, Menlo, Consolas, monospace;
|
||||
--wd-sans: "Inter", ui-sans-serif, system-ui, -apple-system, "Helvetica Neue", Arial, sans-serif;
|
||||
|
||||
font-family: var(--wd-sans);
|
||||
color: var(--wd-fg);
|
||||
display: flex;
|
||||
flex-direction: column;
|
||||
gap: 16px;
|
||||
/* Past roughly this width the two panes stop reading as a pair and table
|
||||
rows get hard to track across. Cap the whole dashboard, not just the
|
||||
grid, so the toolbar stays flush with the panes below it. */
|
||||
max-width: 1600px;
|
||||
/* Makes this element the reference for the @container query further down,
|
||||
so the grid collapses on the pane's width rather than the window's. */
|
||||
container-type: inline-size;
|
||||
}
|
||||
|
||||
.theme-dark .webinar-dash {
|
||||
--wd-bg: var(--wd-ink-900);
|
||||
--wd-bg-subtle: #161616;
|
||||
--wd-fg: var(--wd-ink-000);
|
||||
--wd-fg-2: var(--wd-ink-200);
|
||||
--wd-fg-3: var(--wd-ink-400);
|
||||
--wd-fg-4: var(--wd-ink-500);
|
||||
--wd-border: var(--wd-ink-700);
|
||||
--wd-border-strong: #b8b8b8;
|
||||
--wd-border-subtle: #161616;
|
||||
/* Accent tracks the installed theme at .obsidian/themes/tesanti/theme.css,
|
||||
whose dark section reads "Black canvas, same signal red": --accent-h/-s/-l
|
||||
are declared once at :root and never redeclared under .theme-dark, and only
|
||||
the hover state lifts (#c31c14 light, #ff4d43 dark). Match that exactly. */
|
||||
--wd-accent: var(--wd-red-500);
|
||||
--wd-accent-press: #ff4d43;
|
||||
--wd-accent-on: #ffffff;
|
||||
/* Status tokens are separate from the brand accent by design-system rule, and
|
||||
here they carry small text in a dense table. #e1261c on near-black is about
|
||||
3.8:1, under AA for small text, so these lift where the accent does not. */
|
||||
--wd-ok: #2fbf6a;
|
||||
--wd-warn: #e0a516;
|
||||
--wd-danger: #ff5c50;
|
||||
}
|
||||
|
||||
/* ------------------------------------------------------------------
|
||||
Escape Obsidian's readable-line-length cap.
|
||||
|
||||
With "Readable line length" on (the default), Obsidian caps note
|
||||
content at --file-line-width, roughly 700px. That is right for prose
|
||||
and wrong for a two-pane dashboard, which gets squeezed into a column.
|
||||
|
||||
:has() scopes this to the sizer that actually contains a dashboard, so
|
||||
every other note in the vault keeps its readable width. Both selectors
|
||||
are needed: reading view sizes on .markdown-preview-sizer, live preview
|
||||
on .cm-sizer.
|
||||
|
||||
If you would rather not rely on this, the alternatives are Settings ->
|
||||
Editor -> Readable line length (off, but that widens every note), or
|
||||
adding `cssclasses: wide-dash` to the note's frontmatter and swapping
|
||||
the :has() selectors below for `.wide-dash .markdown-preview-sizer`.
|
||||
------------------------------------------------------------------ */
|
||||
.markdown-preview-sizer:has(.webinar-dash),
|
||||
.markdown-source-view.mod-cm6 .cm-sizer:has(.webinar-dash) {
|
||||
max-width: none;
|
||||
}
|
||||
|
||||
.wd-grid {
|
||||
display: grid;
|
||||
grid-template-columns: minmax(0, 38fr) minmax(0, 62fr);
|
||||
gap: 24px;
|
||||
}
|
||||
.wd-grid > * { min-width: 0; }
|
||||
|
||||
.wd-bar {
|
||||
display: flex;
|
||||
align-items: center;
|
||||
gap: 12px;
|
||||
flex-wrap: wrap;
|
||||
border: 1px solid var(--wd-border);
|
||||
border-radius: 4px;
|
||||
padding: 8px 12px;
|
||||
background: var(--wd-bg-subtle);
|
||||
}
|
||||
|
||||
.wd-btn-ghost {
|
||||
background: transparent;
|
||||
color: var(--wd-fg);
|
||||
border-color: var(--wd-border-strong);
|
||||
}
|
||||
.wd-btn-ghost:hover {
|
||||
background: var(--wd-bg-muted, var(--wd-bg-subtle));
|
||||
border-color: var(--wd-border-strong);
|
||||
}
|
||||
|
||||
/* Collapse to one column on the width that actually matters — the pane's,
|
||||
not the window's. A media query measures the window, so a wide window
|
||||
with the dashboard in a narrow split pane would keep two cramped
|
||||
columns. The container query below responds to the pane itself; the
|
||||
media query stays as a floor for a genuinely narrow window. */
|
||||
@container (max-width: 820px) {
|
||||
.wd-grid { grid-template-columns: minmax(0, 1fr); }
|
||||
}
|
||||
|
||||
@media (max-width: 820px) {
|
||||
.wd-grid { grid-template-columns: minmax(0, 1fr); }
|
||||
}
|
||||
|
||||
.wd-pane { display: flex; flex-direction: column; gap: 20px; }
|
||||
|
||||
.wd-eyebrow {
|
||||
font-family: var(--wd-mono); font-size: 11px; line-height: 1;
|
||||
letter-spacing: 0.12em; text-transform: uppercase;
|
||||
color: var(--wd-fg-3); font-weight: 500;
|
||||
display: flex; align-items: center; gap: 8px;
|
||||
}
|
||||
.wd-eyebrow::before {
|
||||
content: ""; width: 5px; height: 5px; flex: none; background: var(--wd-accent);
|
||||
}
|
||||
|
||||
.wd-block { display: flex; flex-direction: column; gap: 12px; }
|
||||
|
||||
.wd-row {
|
||||
display: flex; align-items: center; gap: 12px; flex-wrap: wrap;
|
||||
border: 1px solid var(--wd-border); border-radius: 4px;
|
||||
padding: 12px 12px 12px 16px; background: var(--wd-bg);
|
||||
}
|
||||
.wd-row + .wd-row { margin-top: -1px; }
|
||||
.wd-row-main { flex: 1; min-width: 0; display: flex; flex-direction: column; gap: 2px; }
|
||||
.wd-row-name {
|
||||
font-size: 14px; font-weight: 600;
|
||||
overflow: hidden; text-overflow: ellipsis; white-space: nowrap;
|
||||
}
|
||||
.wd-mono {
|
||||
font-family: var(--wd-mono); font-size: 11px; color: var(--wd-fg-3);
|
||||
font-variant-numeric: tabular-nums;
|
||||
}
|
||||
|
||||
.wd-btn {
|
||||
display: inline-flex; align-items: center; gap: 6px; flex: none;
|
||||
font-family: var(--wd-sans); font-size: 13px; font-weight: 600;
|
||||
padding: 6px 12px; border-radius: 6px; cursor: pointer;
|
||||
border: 1px solid var(--wd-accent); background: var(--wd-accent);
|
||||
color: var(--wd-accent-on);
|
||||
transition: background 120ms cubic-bezier(0.2, 0, 0, 1);
|
||||
}
|
||||
.wd-btn:hover { background: var(--wd-accent-press); border-color: var(--wd-accent-press); }
|
||||
.wd-btn:focus-visible { outline: 2px solid var(--wd-accent); outline-offset: 2px; }
|
||||
.wd-btn[disabled] {
|
||||
opacity: 0.45; cursor: not-allowed;
|
||||
background: transparent; color: var(--wd-fg-3); border-color: var(--wd-border);
|
||||
}
|
||||
.wd-btn svg { width: 14px; height: 14px; flex: none; }
|
||||
|
||||
.wd-done { display: flex; flex-direction: column; }
|
||||
.wd-done-row {
|
||||
display: flex; align-items: baseline; gap: 12px; padding: 5px 0;
|
||||
border-bottom: 1px solid var(--wd-border-subtle); font-size: 13px;
|
||||
}
|
||||
.wd-done-row:last-child { border-bottom: 0; }
|
||||
.wd-done-name {
|
||||
color: var(--wd-fg-2);
|
||||
overflow: hidden; text-overflow: ellipsis; white-space: nowrap;
|
||||
}
|
||||
|
||||
.wd-note { font-size: 12px; color: var(--wd-fg-3); }
|
||||
.wd-error {
|
||||
font-size: 13px; color: var(--wd-danger);
|
||||
border: 1px solid var(--wd-danger); border-radius: 4px; padding: 12px;
|
||||
}
|
||||
|
||||
@media (prefers-reduced-motion: reduce) {
|
||||
.webinar-dash * { transition-duration: 0.01ms !important; }
|
||||
}
|
||||
|
||||
.wd-meter { display: flex; gap: 2px; height: 8px; width: 100%; }
|
||||
.wd-meter > i { display: block; height: 100%; }
|
||||
.wd-seg-covered { background: var(--wd-ok); }
|
||||
.wd-seg-partial { background: var(--wd-warn); }
|
||||
.wd-seg-absent { background: var(--wd-danger); }
|
||||
|
||||
.wd-key { display: flex; flex-wrap: wrap; gap: 16px; font-size: 12px; color: var(--wd-fg-2); }
|
||||
.wd-key > span { display: inline-flex; align-items: center; gap: 6px; }
|
||||
.wd-key i { width: 8px; height: 8px; flex: none; }
|
||||
|
||||
.wd-tbl { width: 100%; border-collapse: collapse; font-size: 13px; }
|
||||
.wd-tbl th {
|
||||
font-family: var(--wd-mono); font-size: 10px; letter-spacing: 0.1em;
|
||||
text-transform: uppercase; color: var(--wd-fg-3); font-weight: 500;
|
||||
text-align: left; padding: 0 12px 8px 0;
|
||||
border-bottom: 1px solid var(--wd-border-strong);
|
||||
}
|
||||
.wd-tbl td {
|
||||
padding: 6px 12px 6px 0; border-bottom: 1px solid var(--wd-border-subtle);
|
||||
vertical-align: baseline;
|
||||
}
|
||||
.wd-grp td {
|
||||
padding-top: 16px; border-bottom: 1px solid var(--wd-border-strong);
|
||||
font-family: var(--wd-mono); font-size: 10px; letter-spacing: 0.1em;
|
||||
text-transform: uppercase; color: var(--wd-fg); font-weight: 500;
|
||||
}
|
||||
.wd-stat { display: inline-flex; align-items: center; gap: 5px; font-size: 12px; font-weight: 600; }
|
||||
.wd-stat svg { width: 13px; height: 13px; flex: none; }
|
||||
.wd-covered { color: var(--wd-ok); }
|
||||
.wd-partial { color: var(--wd-warn); }
|
||||
.wd-absent { color: var(--wd-danger); }
|
||||
.wd-pin { font-family: var(--wd-mono); font-size: 10px; color: var(--wd-fg-4); }
|
||||
|
||||
.wd-status { font-family: var(--wd-mono); font-size: 11px; flex: none; }
|
||||
.wd-status-running { color: var(--wd-warn); }
|
||||
.wd-status-done { color: var(--wd-ok); }
|
||||
.wd-status-failed { color: var(--wd-danger); }
|
||||
.wd-output {
|
||||
flex-basis: 100%;
|
||||
width: 100%;
|
||||
font-family: var(--wd-mono); font-size: 11px; white-space: pre-wrap;
|
||||
max-height: 220px; overflow: auto; margin-top: 8px;
|
||||
border: 1px solid var(--wd-border); border-radius: 4px; padding: 8px;
|
||||
color: var(--wd-fg-2);
|
||||
}
|
||||
122
.obsidian/plugins/webinar-dash/test/coverage.test.js
vendored
122
.obsidian/plugins/webinar-dash/test/coverage.test.js
vendored
@@ -1,122 +0,0 @@
|
||||
"use strict";
|
||||
const test = require("node:test");
|
||||
const assert = require("node:assert/strict");
|
||||
const { parseCoverageTable, groupByStation } = require("../main.js").__test__;
|
||||
|
||||
const DOC = [
|
||||
"# Script coverage",
|
||||
"",
|
||||
"#coverage",
|
||||
"",
|
||||
"## Metadata",
|
||||
"",
|
||||
"- **Script:** `raw/sources/Webinar script.md`",
|
||||
"- **Last synced:** 2026-07-28",
|
||||
"",
|
||||
"## Coverage",
|
||||
"",
|
||||
"| Concept | Status | Station | Pinned |",
|
||||
"|---|---|---|---|",
|
||||
"| [[harness]] | covered | Tools | |",
|
||||
"| [[agentic-loops]] | partial | Process | |",
|
||||
"| [[levels-of-ai-usage]] | partial | all | |",
|
||||
"| [[connections-as-moat]] | absent | — | yes |",
|
||||
].join("\n");
|
||||
|
||||
test("parseCoverageTable reads metadata", () => {
|
||||
const { meta } = parseCoverageTable(DOC);
|
||||
assert.equal(meta.script, "raw/sources/Webinar script.md");
|
||||
assert.equal(meta.lastSynced, "2026-07-28");
|
||||
});
|
||||
|
||||
test("parseCoverageTable reads every data row and skips the header", () => {
|
||||
const { rows, errors } = parseCoverageTable(DOC);
|
||||
assert.equal(errors.length, 0);
|
||||
assert.equal(rows.length, 4);
|
||||
assert.deepEqual(rows.map((r) => r.concept), [
|
||||
"harness", "agentic-loops", "levels-of-ai-usage", "connections-as-moat",
|
||||
]);
|
||||
});
|
||||
|
||||
test("parseCoverageTable normalises stations", () => {
|
||||
const { rows } = parseCoverageTable(DOC);
|
||||
assert.deepEqual(rows[0].stations, ["Tools"]);
|
||||
assert.deepEqual(rows[2].stations, ["all"]);
|
||||
assert.deepEqual(rows[3].stations, []);
|
||||
});
|
||||
|
||||
test("parseCoverageTable reads the pinned flag", () => {
|
||||
const { rows } = parseCoverageTable(DOC);
|
||||
assert.equal(rows[0].pinned, false);
|
||||
assert.equal(rows[3].pinned, true);
|
||||
});
|
||||
|
||||
test("parseCoverageTable strips a wikilink alias", () => {
|
||||
const doc = "| Concept | Status | Station |\n|---|---|---|\n| [[harness\\|The harness]] | covered | Tools |";
|
||||
const { rows } = parseCoverageTable(doc);
|
||||
assert.equal(rows[0].concept, "harness");
|
||||
});
|
||||
|
||||
test("parseCoverageTable splits a multi-station cell", () => {
|
||||
const doc = "| C | S | St |\n|---|---|---|\n| [[x]] | covered | Tools, Memory |";
|
||||
const { rows } = parseCoverageTable(doc);
|
||||
assert.deepEqual(rows[0].stations, ["Tools", "Memory"]);
|
||||
});
|
||||
|
||||
test("parseCoverageTable rejects an invalid status instead of coercing it", () => {
|
||||
const doc = "| C | S | St |\n|---|---|---|\n| [[x]] | maybe | Tools |";
|
||||
const { rows, errors } = parseCoverageTable(doc);
|
||||
assert.equal(rows.length, 0);
|
||||
assert.equal(errors.length, 1);
|
||||
assert.match(errors[0].reason, /invalid status/);
|
||||
assert.equal(errors[0].line, 3);
|
||||
});
|
||||
|
||||
test("parseCoverageTable reports a row with too few columns", () => {
|
||||
const doc = "| C | S | St |\n|---|---|---|\n| [[x]] | covered |";
|
||||
const { rows, errors } = parseCoverageTable(doc);
|
||||
assert.equal(rows.length, 0);
|
||||
assert.equal(errors.length, 1);
|
||||
assert.match(errors[0].reason, /at least 3 columns/);
|
||||
});
|
||||
|
||||
test("parseCoverageTable returns empty results for a document with no table", () => {
|
||||
const { rows, errors } = parseCoverageTable("# Nothing\n\nJust prose.");
|
||||
assert.equal(rows.length, 0);
|
||||
assert.equal(errors.length, 0);
|
||||
});
|
||||
|
||||
test("groupByStation orders all-stations first and no-station last", () => {
|
||||
const { rows } = parseCoverageTable(DOC);
|
||||
const groups = groupByStation(rows);
|
||||
assert.deepEqual(groups.map((g) => g.station), [
|
||||
"All stations", "Tools", "Process", "No station",
|
||||
]);
|
||||
assert.equal(groups[1].rows[0].concept, "harness");
|
||||
});
|
||||
|
||||
test("groupByStation places a multi-station row under its first station only", () => {
|
||||
const rows = [{ concept: "x", status: "covered", stations: ["Memory", "Skills"], pinned: false, line: 1 }];
|
||||
const groups = groupByStation(rows);
|
||||
assert.equal(groups.length, 1);
|
||||
assert.equal(groups[0].station, "Memory");
|
||||
});
|
||||
|
||||
const { reconcileConcepts } = require("../main.js").__test__;
|
||||
|
||||
test("reconcileConcepts finds concept pages with no row", () => {
|
||||
const rows = [{ concept: "harness", status: "covered", stations: ["Tools"], pinned: false, line: 1 }];
|
||||
const out = reconcileConcepts(rows, ["harness", "brand-new-concept"]);
|
||||
assert.deepEqual(out.unsynced, ["brand-new-concept"]);
|
||||
assert.deepEqual(out.stale, []);
|
||||
});
|
||||
|
||||
test("reconcileConcepts finds rows whose concept page is gone", () => {
|
||||
const rows = [
|
||||
{ concept: "harness", status: "covered", stations: ["Tools"], pinned: false, line: 1 },
|
||||
{ concept: "deleted-idea", status: "absent", stations: [], pinned: false, line: 2 },
|
||||
];
|
||||
const out = reconcileConcepts(rows, ["harness"]);
|
||||
assert.deepEqual(out.stale.map((r) => r.concept), ["deleted-idea"]);
|
||||
assert.deepEqual(out.unsynced, []);
|
||||
});
|
||||
109
.obsidian/plugins/webinar-dash/test/pipeline.test.js
vendored
109
.obsidian/plugins/webinar-dash/test/pipeline.test.js
vendored
@@ -1,109 +0,0 @@
|
||||
"use strict";
|
||||
const test = require("node:test");
|
||||
const assert = require("node:assert/strict");
|
||||
const { extractRawPath, derivePipeline } = require("../main.js").__test__;
|
||||
|
||||
test("extractRawPath pulls the backticked path", () => {
|
||||
const page = [
|
||||
"# You're reading way too much code",
|
||||
"",
|
||||
"#source",
|
||||
"",
|
||||
"## Source Metadata",
|
||||
"",
|
||||
"- **Date:** YouTube video, 24:11",
|
||||
"- **Raw path:** `raw/sources/You're reading way too much code.md`",
|
||||
"- **Source type:** video essay",
|
||||
].join("\n");
|
||||
assert.equal(extractRawPath(page), "raw/sources/You're reading way too much code.md");
|
||||
});
|
||||
|
||||
test("extractRawPath handles cyrillic and em dashes", () => {
|
||||
const page = "- **Raw path:** `raw/sources/Скиллы на базе git — новая память AI-агентов.md`";
|
||||
assert.equal(extractRawPath(page), "raw/sources/Скиллы на базе git — новая память AI-агентов.md");
|
||||
});
|
||||
|
||||
test("extractRawPath returns null when the line is absent", () => {
|
||||
assert.equal(extractRawPath("# A page\n\n#source\n\nNo metadata here."), null);
|
||||
});
|
||||
|
||||
test("derivePipeline splits claimed from unclaimed raw files", () => {
|
||||
const rawFiles = [
|
||||
{ path: "raw/sources/Nina interview.md", name: "Nina interview.md", size: 6614 },
|
||||
{ path: "raw/sources/Webinar script.md", name: "Webinar script.md", size: 15841 },
|
||||
];
|
||||
const sourcePages = [
|
||||
{
|
||||
path: "wiki/sources/2026-07-14-nina-interview.md",
|
||||
name: "2026-07-14-nina-interview.md",
|
||||
rawPath: "raw/sources/Nina interview.md",
|
||||
},
|
||||
];
|
||||
const out = derivePipeline({ rawFiles, sourcePages });
|
||||
assert.equal(out.processed.length, 1);
|
||||
assert.equal(out.processed[0].name, "Nina interview.md");
|
||||
assert.equal(out.processed[0].page.name, "2026-07-14-nina-interview.md");
|
||||
assert.equal(out.unprocessed.length, 1);
|
||||
assert.equal(out.unprocessed[0].name, "Webinar script.md");
|
||||
assert.equal(out.orphaned.length, 0);
|
||||
});
|
||||
|
||||
test("derivePipeline reports source pages whose raw file is gone", () => {
|
||||
const out = derivePipeline({
|
||||
rawFiles: [],
|
||||
sourcePages: [
|
||||
{ path: "wiki/sources/x.md", name: "x.md", rawPath: "raw/sources/deleted.md" },
|
||||
],
|
||||
});
|
||||
assert.equal(out.orphaned.length, 1);
|
||||
assert.equal(out.orphaned[0].name, "x.md");
|
||||
});
|
||||
|
||||
test("derivePipeline treats a page with no raw path as orphaned", () => {
|
||||
const out = derivePipeline({
|
||||
rawFiles: [{ path: "raw/sources/a.md", name: "a.md", size: 10 }],
|
||||
sourcePages: [{ path: "wiki/sources/y.md", name: "y.md", rawPath: null }],
|
||||
});
|
||||
assert.equal(out.orphaned.length, 1);
|
||||
assert.equal(out.unprocessed.length, 1);
|
||||
});
|
||||
|
||||
test("derivePipeline routes a duplicate raw-path claim to orphaned", () => {
|
||||
const out = derivePipeline({
|
||||
rawFiles: [{ path: "raw/sources/a.md", name: "a.md", size: 10 }],
|
||||
sourcePages: [
|
||||
{ path: "wiki/sources/first.md", name: "first.md", rawPath: "raw/sources/a.md" },
|
||||
{ path: "wiki/sources/second.md", name: "second.md", rawPath: "raw/sources/a.md" },
|
||||
],
|
||||
});
|
||||
assert.equal(out.processed.length, 1);
|
||||
assert.equal(out.processed[0].page.name, "first.md");
|
||||
assert.equal(out.unprocessed.length, 0);
|
||||
assert.deepEqual(out.orphaned.map((p) => p.name), ["second.md"]);
|
||||
});
|
||||
|
||||
test("derivePipeline lists a page once when it is both a duplicate claim and missing its raw file", () => {
|
||||
const out = derivePipeline({
|
||||
rawFiles: [{ path: "raw/sources/other.md", name: "other.md", size: 10 }],
|
||||
sourcePages: [
|
||||
{ path: "wiki/sources/first.md", name: "first.md", rawPath: "raw/sources/gone.md" },
|
||||
{ path: "wiki/sources/second.md", name: "second.md", rawPath: "raw/sources/gone.md" },
|
||||
],
|
||||
});
|
||||
assert.deepEqual(out.orphaned.map((p) => p.name), ["first.md", "second.md"]);
|
||||
});
|
||||
|
||||
test("derivePipeline sorts unprocessed by name and processed newest first", () => {
|
||||
const out = derivePipeline({
|
||||
rawFiles: [
|
||||
{ path: "raw/sources/b.md", name: "b.md", size: 1 },
|
||||
{ path: "raw/sources/a.md", name: "a.md", size: 1 },
|
||||
{ path: "raw/sources/c.md", name: "c.md", size: 1 },
|
||||
],
|
||||
sourcePages: [
|
||||
{ path: "wiki/sources/2026-07-14-x.md", name: "2026-07-14-x.md", rawPath: "raw/sources/c.md" },
|
||||
],
|
||||
});
|
||||
assert.deepEqual(out.unprocessed.map((f) => f.name), ["a.md", "b.md"]);
|
||||
assert.equal(out.processed.length, 1);
|
||||
});
|
||||
@@ -1,47 +0,0 @@
|
||||
"use strict";
|
||||
const test = require("node:test");
|
||||
const assert = require("node:assert/strict");
|
||||
const { isSafeFilename } = require("../main.js").__test__;
|
||||
|
||||
test("isSafeFilename accepts every filename currently in the vault", () => {
|
||||
const real = [
|
||||
"Agentic Engineering, explained by a 10x developer.md",
|
||||
"Webinar Plan - From Chat Box to Your Own OS.md",
|
||||
"Webinar script.md",
|
||||
"You're reading way too much code.md",
|
||||
"ИИ глупый!.md",
|
||||
"Скиллы на базе git — новая память AI-агентов.md",
|
||||
"sebastian interview - conclusions and insights.md",
|
||||
"In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible.md",
|
||||
];
|
||||
for (const name of real) {
|
||||
assert.equal(isSafeFilename(name), true, `should accept: ${name}`);
|
||||
}
|
||||
});
|
||||
|
||||
test("isSafeFilename rejects shell metacharacters", () => {
|
||||
for (const bad of ['a".md', "a`b.md", "a$b.md", "a&b.md", "a|b.md", "a;b.md",
|
||||
"a<b.md", "a>b.md", "a%b.md", "a\nb.md", "a\rb.md"]) {
|
||||
assert.equal(isSafeFilename(bad), false, `should reject: ${JSON.stringify(bad)}`);
|
||||
}
|
||||
});
|
||||
|
||||
test("isSafeFilename rejects the cmd.exe escape character and control characters", () => {
|
||||
// `^` escapes the next character in cmd.exe, so it can defuse the closing
|
||||
// quote. NUL additionally makes spawn() throw synchronously.
|
||||
for (const bad of ["a^b.md", "a\u0000b.md", "a\u001bb.md", "a\u007fb.md"]) {
|
||||
assert.equal(isSafeFilename(bad), false, `should reject: ${JSON.stringify(bad)}`);
|
||||
}
|
||||
});
|
||||
|
||||
test("isSafeFilename rejects path traversal", () => {
|
||||
assert.equal(isSafeFilename("../secrets.md"), false);
|
||||
assert.equal(isSafeFilename("a/../../b.md"), false);
|
||||
});
|
||||
|
||||
test("isSafeFilename rejects empty and non-string input", () => {
|
||||
assert.equal(isSafeFilename(""), false);
|
||||
assert.equal(isSafeFilename(null), false);
|
||||
assert.equal(isSafeFilename(undefined), false);
|
||||
assert.equal(isSafeFilename(42), false);
|
||||
});
|
||||
241
.obsidian/workspace.json
vendored
Normal file
241
.obsidian/workspace.json
vendored
Normal file
@@ -0,0 +1,241 @@
|
||||
{
|
||||
"main": {
|
||||
"id": "0ddc67276227899d",
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "898d980991f1e045",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "5463f555de76b7cd",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "markdown",
|
||||
"state": {
|
||||
"file": "raw/sources/Грабли во внедрении ИИ в SDLC.md",
|
||||
"mode": "source",
|
||||
"source": false
|
||||
},
|
||||
"icon": "lucide-file",
|
||||
"title": "Грабли во внедрении ИИ в SDLC"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "2d46e86fefb0f38a",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "release-notes",
|
||||
"state": {
|
||||
"currentVersion": "1.13.4"
|
||||
},
|
||||
"icon": "lucide-book-up",
|
||||
"title": "Release Notes 1.13.4"
|
||||
}
|
||||
}
|
||||
],
|
||||
"currentTab": 1
|
||||
}
|
||||
],
|
||||
"direction": "vertical"
|
||||
},
|
||||
"left": {
|
||||
"id": "bdbe0fd792c2e4fb",
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "e9a3ec3578cd4638",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "d3f791c8588a6b77",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "file-explorer",
|
||||
"state": {
|
||||
"sortOrder": "alphabetical",
|
||||
"autoReveal": false,
|
||||
"showSearch": false,
|
||||
"searchQuery": ""
|
||||
},
|
||||
"icon": "lucide-folder-closed",
|
||||
"title": "Files"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "474340f2dfe84c24",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "search",
|
||||
"state": {
|
||||
"query": "complain",
|
||||
"matchingCase": false,
|
||||
"explainSearch": false,
|
||||
"collapseAll": false,
|
||||
"extraContext": false,
|
||||
"sortOrder": "alphabetical"
|
||||
},
|
||||
"icon": "lucide-search",
|
||||
"title": "Search"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "874a5b4f1ccbbe51",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "bookmarks",
|
||||
"state": {},
|
||||
"icon": "lucide-bookmark",
|
||||
"title": "Bookmarks"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"direction": "horizontal",
|
||||
"width": 397.5
|
||||
},
|
||||
"right": {
|
||||
"id": "e2dfddd4b270c511",
|
||||
"type": "split",
|
||||
"children": [
|
||||
{
|
||||
"id": "7b6dd27eb695f3a5",
|
||||
"type": "tabs",
|
||||
"children": [
|
||||
{
|
||||
"id": "56703b36a8b20302",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "backlink",
|
||||
"state": {
|
||||
"file": "wiki/concepts/solve-first-then-skillify.md",
|
||||
"collapseAll": false,
|
||||
"extraContext": false,
|
||||
"sortOrder": "alphabetical",
|
||||
"showSearch": false,
|
||||
"searchQuery": "",
|
||||
"backlinkCollapsed": false,
|
||||
"unlinkedCollapsed": true
|
||||
},
|
||||
"icon": "links-coming-in",
|
||||
"title": "Backlinks for solve-first-then-skillify"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "61e7b50a5685cf74",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "outgoing-link",
|
||||
"state": {
|
||||
"file": "wiki/concepts/solve-first-then-skillify.md",
|
||||
"linksCollapsed": false,
|
||||
"unlinkedCollapsed": true
|
||||
},
|
||||
"icon": "links-going-out",
|
||||
"title": "Outgoing links from solve-first-then-skillify"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "8cc8fddecfb11df6",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "tag",
|
||||
"state": {
|
||||
"sortOrder": "frequency",
|
||||
"useHierarchy": true,
|
||||
"showSearch": false,
|
||||
"searchQuery": ""
|
||||
},
|
||||
"icon": "lucide-tags",
|
||||
"title": "Tags"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "27970b943d6a03d7",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "all-properties",
|
||||
"state": {
|
||||
"sortOrder": "frequency",
|
||||
"showSearch": false,
|
||||
"searchQuery": ""
|
||||
},
|
||||
"icon": "lucide-archive",
|
||||
"title": "All properties"
|
||||
}
|
||||
},
|
||||
{
|
||||
"id": "2c3dedf9326d2711",
|
||||
"type": "leaf",
|
||||
"state": {
|
||||
"type": "outline",
|
||||
"state": {
|
||||
"file": "wiki/concepts/solve-first-then-skillify.md",
|
||||
"followCursor": false,
|
||||
"showSearch": false,
|
||||
"searchQuery": ""
|
||||
},
|
||||
"icon": "lucide-list",
|
||||
"title": "Outline of solve-first-then-skillify"
|
||||
}
|
||||
}
|
||||
]
|
||||
}
|
||||
],
|
||||
"direction": "horizontal",
|
||||
"width": 300,
|
||||
"collapsed": true
|
||||
},
|
||||
"left-ribbon": {
|
||||
"hiddenItems": {
|
||||
"switcher:Open quick switcher": false,
|
||||
"graph:Open graph view": false,
|
||||
"canvas:Create new canvas": false,
|
||||
"daily-notes:Open today's daily note": false,
|
||||
"templates:Insert template": false,
|
||||
"command-palette:Open command palette": false,
|
||||
"bases:Create new base": false
|
||||
}
|
||||
},
|
||||
"active": "2d46e86fefb0f38a",
|
||||
"lastOpenFiles": [
|
||||
"index.md.tmp.37928.2285b1ab105c",
|
||||
"index.md.tmp.37928.291fc158bc9a",
|
||||
"index.md.tmp.37928.2c928edacabb",
|
||||
"wiki/overview.md.tmp.37928.21bfbe643084",
|
||||
"wiki/overview.md.tmp.37928.58de935b7d14",
|
||||
"wiki/overview.md.tmp.37928.5dfad5760432",
|
||||
"wiki/overview.md.tmp.37928.e9644e4b8e6b",
|
||||
"wiki/overview.md.tmp.37928.fdb65c168940",
|
||||
"wiki/concepts/make-more-cheap-code.md.tmp.37928.96f5312269c7",
|
||||
"wiki/concepts/enterprise-ai-reality.md.tmp.37928.e11badf2e036",
|
||||
"wiki/concepts/enterprise-ai-reality.md.tmp.37928.a6c2340fbd91",
|
||||
"wiki/concepts/developer-as-agent-manager.md",
|
||||
"wiki/concepts/review-is-the-new-bottleneck.md",
|
||||
"wiki/entities/nikolai-sheiko.md",
|
||||
"wiki/sources/2026-07-30-rakes-in-ai-sdlc-adoption.md",
|
||||
"raw/assets/G6g3O60bkAE05ZW.png",
|
||||
"wiki/concepts/harness.md",
|
||||
"raw/sources/Грабли во внедрении ИИ в SDLC.md",
|
||||
"wiki/entities/swepr.md",
|
||||
"wiki/sources/2026-07-30-stanford-swepr-widening-gap.md",
|
||||
"raw/sources/Stanford SWEPR - AI and the widening productivity gap.md",
|
||||
"wiki/queries/2026-07-30-stanford-widening-gap-source.md",
|
||||
"index.md",
|
||||
"wiki/queries/2026-07-28-webinar-theses.md",
|
||||
"wiki/queries/2026-07-22-webinar-theses.md",
|
||||
"raw/notes/my theses.md",
|
||||
"raw/notes/Webinar Plan - From Chat Box to Your Own OS.md",
|
||||
"raw/notes/Webinar script.md",
|
||||
"raw/sources/А что если наВайб-Кодить.md",
|
||||
"wiki/concepts/maintenance-is-the-real-cost.md",
|
||||
"wiki/sources/2026-07-29-what-if-we-vibe-code-it.md",
|
||||
"raw/sources/In 1 Year, the Gap Between AI Users and Everyone Else Will Be Irreversible.md",
|
||||
"wiki/queries/2026-07-28-verification-beat-design.md",
|
||||
"wiki/concepts/enterprise-ai-reality.md",
|
||||
"wiki/concepts/code-as-throwaway.md",
|
||||
"wiki/lint-reports/2026-07-28-lint.md",
|
||||
"wiki/concepts/emacsification-of-software.md"
|
||||
]
|
||||
}
|
||||
59
CLAUDE.md
59
CLAUDE.md
@@ -34,7 +34,6 @@ raw/
|
||||
|
||||
wiki/
|
||||
overview.md # top-level synthesis and navigation
|
||||
script-coverage.md # machine-maintained: concept coverage vs the webinar script
|
||||
sources/ # one summary page per ingested raw source
|
||||
entities/ # people, orgs, projects, places, tools
|
||||
concepts/ # themes, ideas, methods, frameworks
|
||||
@@ -70,7 +69,6 @@ Folder → required tag:
|
||||
| Folder / file | Tag |
|
||||
| ---------------------- | -------------- |
|
||||
| `wiki/overview.md` | `#overview` |
|
||||
| `wiki/script-coverage.md` | `#coverage` |
|
||||
| `wiki/sources/*` | `#source` |
|
||||
| `wiki/entities/*` | `#entity` |
|
||||
| `wiki/concepts/*` | `#concept` |
|
||||
@@ -122,29 +120,6 @@ Must include:
|
||||
- Follow-up questions
|
||||
- Whether this output changed existing pages
|
||||
|
||||
### 4) Coverage File (`wiki/script-coverage.md`)
|
||||
|
||||
Machine-read by the dashboard plugin, which parses the table positionally. The
|
||||
shape below is required exactly — a deviation renders as parse errors, not as a
|
||||
best-effort read.
|
||||
|
||||
- `# Script coverage`
|
||||
- `#coverage` tag line
|
||||
- `## Metadata`, containing these two lines verbatim in this form:
|
||||
- `- **Script:** ` followed by the raw script path in backticks
|
||||
- `- **Last synced:** ` followed by a `YYYY-MM-DD` date
|
||||
- `## Coverage`, containing one markdown table with exactly these four columns in
|
||||
this order: `Concept`, `Status`, `Station`, `Pinned`
|
||||
- **Concept** — an Obsidian wikilink to a page in `wiki/concepts/`
|
||||
- **Status** — exactly one of `covered`, `partial`, `absent`, lowercase
|
||||
- **Station** — one of the seven station names spelled exactly as listed in
|
||||
Workflow D, a comma-separated list of them, the lowercase word `all`, or an
|
||||
em dash `—` when the status is `absent`
|
||||
- **Pinned** — the lowercase word `yes`, or empty
|
||||
- `## Notes` and `## Related Pages` are free prose and are not parsed.
|
||||
|
||||
The parser reads every markdown table in the file, so do not add a second table.
|
||||
|
||||
## Standard Workflows
|
||||
|
||||
### Workflow A: Ingest One Source
|
||||
@@ -159,8 +134,6 @@ When user says "ingest <source>":
|
||||
6. Update `index.md`.
|
||||
7. Append ingest entry to `log.md`.
|
||||
8. Report what changed, what is uncertain, and suggested next source/questions.
|
||||
9. If this ingest created or modified any page in `wiki/concepts/`, run Workflow D
|
||||
(Sync Script Coverage) before reporting.
|
||||
|
||||
### Workflow B: Answer Query
|
||||
|
||||
@@ -183,37 +156,6 @@ Run periodic health checks for:
|
||||
|
||||
Write report to `wiki/lint-reports/YYYY-MM-DD-lint.md`, then update `index.md` and `log.md`.
|
||||
|
||||
### Workflow D: Sync Script Coverage
|
||||
|
||||
Maintains `wiki/script-coverage.md` — one row per page in `wiki/concepts/`, judged
|
||||
against the script named in that file's `**Script:**` metadata field.
|
||||
|
||||
1. Read `wiki/script-coverage.md` and note every row where `Pinned` is `yes`.
|
||||
2. Read the script and every page in `wiki/concepts/`.
|
||||
3. For each concept, decide `Status` and `Station`:
|
||||
- `covered` — the script delivers the idea, whether or not it uses the page's name.
|
||||
- `partial` — the script gestures at it but never lands it.
|
||||
- `absent` — the script never reaches it.
|
||||
- `Station` is one of the seven — `Chat box`, `ReAct`, `Tools`, `Memory`,
|
||||
`Skills`, `Process`, `OS` — spelled exactly as written here, or a
|
||||
comma-separated list of them, or the lowercase word `all`, or `—` when absent.
|
||||
4. **Never modify a row whose `Pinned` is `yes`** — not its status, not its station.
|
||||
A pinned row is the user's judgment and outranks yours.
|
||||
5. Add rows for concept pages with no row. Remove rows whose concept page no longer exists.
|
||||
A pinned row whose concept page no longer exists is still removed — step 4
|
||||
protects the user's judgement about a live concept, not a dangling row.
|
||||
6. Update `**Last synced:**` to today.
|
||||
7. Update `index.md` and append a `sync` entry to `log.md`.
|
||||
|
||||
Run this workflow:
|
||||
|
||||
- at the end of any ingest that creates or modifies a page in `wiki/concepts/`
|
||||
- whenever the script file itself changes
|
||||
- on the explicit `sync script coverage` intent
|
||||
|
||||
The coverage baseline is always the raw script. Ingesting the script into
|
||||
`wiki/sources/` does not change the baseline.
|
||||
|
||||
## Citation & Evidence Policy
|
||||
|
||||
- Prefer citing wiki source summaries (`wiki/sources/*.md`) rather than raw files in normal answers.
|
||||
@@ -235,7 +177,6 @@ Supported intents:
|
||||
- "lint wiki"
|
||||
- "show recent changes"
|
||||
- "suggest next sources"
|
||||
- "sync script coverage"
|
||||
|
||||
Always execute intents according to workflows above.
|
||||
|
||||
|
||||
@@ -1,6 +0,0 @@
|
||||
# Webinar dashboard
|
||||
|
||||
```webinar-dash
|
||||
script: raw/sources/Webinar script.md
|
||||
coverage: wiki/script-coverage.md
|
||||
```
|
||||
File diff suppressed because it is too large
Load Diff
@@ -1,256 +0,0 @@
|
||||
# Webinar vault dashboard — design
|
||||
|
||||
Date: 2026-07-28
|
||||
Status: approved, ready for implementation planning
|
||||
|
||||
## Context
|
||||
|
||||
The vault is an LLM-maintained wiki governed by `CLAUDE.md`. It currently holds 12 raw
|
||||
sources, 9 ingested source summaries, 19 concept pages, and one webinar script
|
||||
(`raw/sources/Webinar script.md`) that the concepts are supposed to feed.
|
||||
|
||||
Two problems motivated this work:
|
||||
|
||||
1. **The manual catalog drifts.** `index.md` lists `Ideas for webinar.md` and
|
||||
`my theses.md` under `raw/sources/`, but both live in `raw/notes/`. It does not
|
||||
mention `Agentic Engineering, explained by a 10x developer.md` at all, which sits
|
||||
un-ingested in `raw/sources/`. Nothing detects this.
|
||||
2. **No view of script coverage.** There is no way to see which concept pages the
|
||||
webinar script actually delivers. A manual read shows the script is entirely
|
||||
machine-side: all human-side and strategy-side concepts are absent.
|
||||
|
||||
## Goals
|
||||
|
||||
- Show processed and unprocessed sources, with a one-click ingest on the unprocessed.
|
||||
- Show every concept and whether the webinar script mentions it, plus which script
|
||||
station it lands in.
|
||||
- Keep coverage status in a separate markdown file, kept synchronized by a rule in
|
||||
`CLAUDE.md`.
|
||||
|
||||
## Non-goals
|
||||
|
||||
- Replacing `index.md` or `log.md`. Both stay exactly as they are.
|
||||
- A general-purpose Obsidian dashboard framework. This is one vault-specific plugin.
|
||||
- Publishing the plugin to the community plugin registry.
|
||||
|
||||
## Decisions taken
|
||||
|
||||
| Decision | Choice | Rationale |
|
||||
|---|---|---|
|
||||
| Buttons | Own plugin, not Meta Bind | Needs are narrow and vault-specific; Meta Bind's expensive half (inline CM6 widgets, two-way frontmatter binding) is unused here |
|
||||
| Coverage status source | Claude judges; user can pin | Sync sets status automatically, but a row marked `Pinned: yes` is never overwritten |
|
||||
| Ingest mechanism | Headless `claude -p` via `child_process` | One click, fully automatic. Chosen over a queue file with the unsupervised-write trade-off understood |
|
||||
| Granularity | Status + script station | Turns the table into a pacing map, not just a checklist |
|
||||
| Layout | Two-pane (Option B) | Sources and coverage both first-class; coverage grouped by station recovers most of the station-board view |
|
||||
|
||||
## Architecture
|
||||
|
||||
```
|
||||
.obsidian/plugins/webinar-dash/
|
||||
manifest.json
|
||||
main.js # plain CommonJS, no build step
|
||||
styles.css # tesanti tokens scoped to .webinar-dash
|
||||
|
||||
dashboard.md # vault root, beside index.md
|
||||
wiki/script-coverage.md # the coverage table
|
||||
```
|
||||
|
||||
`dashboard.md` holds only a config block; the plugin renders everything:
|
||||
|
||||
````markdown
|
||||
# Webinar dashboard
|
||||
|
||||
```webinar-dash
|
||||
script: raw/sources/Webinar script.md
|
||||
coverage: wiki/script-coverage.md
|
||||
```
|
||||
````
|
||||
|
||||
Config keys are optional and fall back to those two defaults.
|
||||
|
||||
### Where truth lives
|
||||
|
||||
| Data | Source of truth | Mechanism |
|
||||
|---|---|---|
|
||||
| Which sources are processed | Filesystem, read live | Diff `raw/sources/*.md` against the `**Raw path:**` value in every `wiki/sources/*.md` |
|
||||
| Concept coverage status | `wiki/script-coverage.md` | Written by Claude on sync, read by the plugin |
|
||||
|
||||
Mechanical facts come from the filesystem, judgment comes from the markdown file.
|
||||
This makes the `index.md` class of drift structurally impossible on the sources half:
|
||||
the dashboard cannot disagree with the filesystem because it derives from it.
|
||||
|
||||
**The plugin never writes to the vault.** It reads files and spawns one subprocess.
|
||||
Nothing else. It also never reads `index.md` — the catalog is a human-facing artifact,
|
||||
and treating it as input would reintroduce exactly the drift this design removes.
|
||||
|
||||
### Source pipeline derivation
|
||||
|
||||
1. List `raw/sources/*.md`.
|
||||
2. For each `wiki/sources/*.md`, extract the backticked path from the line matching
|
||||
`**Raw path:** \`<path>\``. Verified consistent across all 9 existing source pages.
|
||||
3. A raw file claimed by some source page is **processed**; unclaimed is **unprocessed**.
|
||||
4. A source page whose raw path no longer exists is reported as **orphaned**.
|
||||
|
||||
`raw/notes/` is out of scope — those are notes, not sources.
|
||||
|
||||
## Coverage file format
|
||||
|
||||
```markdown
|
||||
# Script coverage
|
||||
|
||||
#coverage
|
||||
|
||||
## Metadata
|
||||
|
||||
- **Script:** `raw/sources/Webinar script.md`
|
||||
- **Last synced:** 2026-07-28
|
||||
- **Stations:** Chat box · ReAct · Tools · Memory · Skills · Process · OS
|
||||
|
||||
## Coverage
|
||||
|
||||
| Concept | Status | Station | Pinned |
|
||||
|---|---|---|---|
|
||||
| [[harness]] | covered | Tools | |
|
||||
| [[agentic-loops]] | partial | Process | |
|
||||
| [[levels-of-ai-usage]] | partial | all | |
|
||||
| [[connections-as-moat]] | absent | — | yes |
|
||||
```
|
||||
|
||||
Field rules:
|
||||
|
||||
- **Concept** — an Obsidian wikilink to a page in `wiki/concepts/`. The plugin extracts
|
||||
the page name from inside the brackets.
|
||||
- **Status** — exactly one of `covered`, `partial`, `absent`. Any other value renders as
|
||||
`invalid` rather than being silently coerced.
|
||||
- **Station** — one of the seven station names, a comma-separated list of them, `all`,
|
||||
or `—` for none.
|
||||
- **Pinned** — `yes`, or blank. Blank is the default.
|
||||
|
||||
The seven stations are the `#` headings of the script that represent technology levels:
|
||||
Chat box, ReAct, Tools, Memory, Skills, Process, OS. The script's `Intro`,
|
||||
`Mail from boss`, and `Notes` headings are setup and are not stations.
|
||||
|
||||
v1 does not write this file from the plugin. Pinning is a hand-edit of one cell — a pin
|
||||
toggle button would make the plugin a writer and risk clobbering concurrent user edits,
|
||||
which is not worth it for a one-word change.
|
||||
|
||||
## Rendering — two-pane layout
|
||||
|
||||
Left pane (38%):
|
||||
- **Queue** — unprocessed sources, each row showing filename, byte size, and an
|
||||
**Ingest** button. Files missing from `index.md` need no special flag: they appear
|
||||
here purely because no source page claims them, which is how
|
||||
`Agentic Engineering, explained by a 10x developer.md` surfaces despite being absent
|
||||
from the catalog.
|
||||
- **Ingested** — processed sources as compact rows: date from the source page filename
|
||||
prefix, plus title.
|
||||
|
||||
Right pane (62%):
|
||||
- Coverage meter — a stacked bar of covered / partial / absent with a 2px gap between
|
||||
segments, plus a counted key.
|
||||
- Coverage table grouped by station, with `No station` last.
|
||||
|
||||
Collapses to a single column below 820px so a narrow Obsidian pane stays usable.
|
||||
|
||||
Styling follows the tesanti design system: black / white / red only, Space Grotesk
|
||||
display, Inter body, JetBrains Mono for eyebrows and data, radii at most 6px, 1px
|
||||
hairlines instead of shadows, Lucide stroke icons, no emoji. Status colors use the
|
||||
system's `--ok` / `--warn` / `--danger` tokens and always ship with a text label, never
|
||||
color alone. Dark mode is derived from the same ink ramp, with the red lifted to
|
||||
`#ff4a3d` so small text clears contrast on near-black.
|
||||
|
||||
## Ingest mechanism
|
||||
|
||||
```js
|
||||
const { spawn } = require("child_process");
|
||||
spawn("claude", ["-p", `ingest "${file}"`], { cwd: vaultPath, shell: true });
|
||||
```
|
||||
|
||||
`shell: true` is required on Windows to resolve `claude.cmd`, which places the filename
|
||||
inside a shell string. Before spawning, the filename is rejected if it contains any of:
|
||||
`"` `` ` `` `$` `&` `|` `;` `<` `>` `%` or a newline. Existing filenames include
|
||||
Cyrillic, spaces, and `!`, all of which pass. A rejected filename shows an error in its
|
||||
row and does not spawn.
|
||||
|
||||
Vault path comes from `app.vault.adapter.getBasePath()` on `FileSystemAdapter`.
|
||||
|
||||
Per-row states: `idle` → `running` with elapsed seconds → `done` or `failed · exit <n>`
|
||||
with captured stderr in an expandable block. On success the pipeline is re-derived and
|
||||
the row moves to the ingested list. A second click while running is ignored.
|
||||
|
||||
A global **Sync coverage** button spawns `claude -p "sync script coverage"`.
|
||||
|
||||
Preflight: if `claude` is not resolvable on PATH, all buttons render disabled with that
|
||||
reason stated.
|
||||
|
||||
### Accepted risk
|
||||
|
||||
Headless ingest writes source summaries, concept pages, `index.md`, and `log.md` without
|
||||
the user watching. This was chosen deliberately over a review checkpoint. Mitigations:
|
||||
one file per click rather than a batch, captured output retained per row, and visible
|
||||
per-row status. The writes land before the user reads them; this is understood and
|
||||
accepted.
|
||||
|
||||
## CLAUDE.md changes
|
||||
|
||||
1. **Folder convention** — add `wiki/script-coverage.md` to the tree with a note that it
|
||||
is machine-maintained.
|
||||
2. **Tagging rules** — add the row `wiki/script-coverage.md` → `#coverage`. No existing
|
||||
page type fits: it is generated tabular data, not prose analysis.
|
||||
3. **Workflow D: Sync Script Coverage** — re-read the script and every
|
||||
`wiki/concepts/*.md`; set `Status` and `Station` for each; never modify a row whose
|
||||
`Pinned` is `yes`; add rows for new concept pages; remove rows for deleted ones;
|
||||
update `Last synced`; then update `index.md` and append to `log.md`.
|
||||
4. **Sync triggers** — Workflow D runs at the end of any ingest that creates or modifies
|
||||
a concept page, whenever `Webinar script.md` changes, and on the explicit
|
||||
`sync script coverage` intent, which is added to Operational Commands.
|
||||
|
||||
The coverage baseline is always the raw script at `raw/sources/Webinar script.md`.
|
||||
Ingesting the script into `wiki/sources/` later does not change the baseline.
|
||||
|
||||
## Failure modes
|
||||
|
||||
| Condition | Behavior |
|
||||
|---|---|
|
||||
| Coverage file missing or table malformed | Sources pane renders normally; coverage pane shows a parse error with the offending line |
|
||||
| Concept page exists with no table row | Rendered as `unsynced`, so a stale sync is visible rather than silent |
|
||||
| Table row points at a nonexistent concept page | Rendered as `stale`, kept in place, not auto-removed |
|
||||
| Source page whose raw path is missing | Listed under `orphaned` in the left pane |
|
||||
| `child_process` unavailable (mobile) | Buttons render disabled with the reason |
|
||||
| `claude` not on PATH | Buttons render disabled with the reason |
|
||||
|
||||
## Initial coverage assessment
|
||||
|
||||
Read manually while designing; the first real sync will regenerate it. 19 concepts:
|
||||
5 covered, 4 partial, 10 absent.
|
||||
|
||||
- **covered** — harness (Tools), skills-as-memory (Skills), solve-first-then-skillify
|
||||
(Skills), personal-ai-operating-system (OS), evolution-of-agent-tooling (Tools)
|
||||
- **partial** — agentic-loops (Process), context-as-scarce-resource (Memory),
|
||||
levels-of-ai-usage (all), code-as-throwaway (OS)
|
||||
- **absent** — connections-as-moat, product-ownership, seniority-and-the-junior-squeeze,
|
||||
decoupling-identity-from-profession, network-from-a-standing-start,
|
||||
think-wider-not-bigger, make-more-cheap-code, enterprise-ai-reality,
|
||||
integration-dead-ends, leave-less-room-for-imagination
|
||||
|
||||
Eight of the ten absent concepts are human-side or strategy-side per `index.md`'s grouping.
|
||||
The other two — `integration-dead-ends` and `leave-less-room-for-imagination` — are
|
||||
machine-side, and are absent because the script demonstrates the happy path and so never
|
||||
reaches connector gating or spec ambiguity, the two ways the machine side fails in
|
||||
practice. The `ReAct` station carries no wiki concept at all.
|
||||
|
||||
## Out of scope for v1
|
||||
|
||||
- Pin toggle button (hand-edit instead).
|
||||
- Alternate station-board view toggle. The data file is layout-independent, so this is a
|
||||
render change if wanted later.
|
||||
- Coverage for entities, sources, or queries — concepts only.
|
||||
- Any view of `raw/notes/`.
|
||||
|
||||
## Note on spec location
|
||||
|
||||
This file introduces a `docs/` folder at the vault root, which is not part of the
|
||||
`CLAUDE.md` folder convention and will appear in Obsidian's file explorer. It can be
|
||||
moved or deleted without affecting the implementation.
|
||||
|
||||
The vault is not a git repository, so this spec is not committed.
|
||||
29
index.md
29
index.md
@@ -17,12 +17,12 @@ Every wiki page carries a page-type tag under its H1 (`#source`, `#entity`, `#co
|
||||
- [[2026-07-21-larysa-interview]] — Eugene + Larysa (BA/PM): memory loss, integration dead-ends, less room for imagination _(raw: Larysa interview.md)_
|
||||
- [[2026-07-22-ai-is-stupid]] — YouTube short (author unknown): "stupid AI" = model minus context minus harness; Nobel-vs-employee analogy _(raw: ИИ глупый!.md)_
|
||||
- [[2026-07-24-youre-reading-way-too-much-code]] — Theo Browne (video): make more cheap code, four tiers of code, 100:1 slop-to-ship verification _(raw: You're reading way too much code.md)_
|
||||
- [[2026-07-28-agentic-engineering-10x-developer]] — Thorsten Ball (AMP): shed weight, orbs/async, Emacsification, internal software; **rejects skills/MCP** _(raw: Agentic Engineering, explained by a 10x developer.md)_
|
||||
- [[2026-07-29-what-if-we-vibe-code-it]] — YouTube video (author unknown): maintenance is the real cost, internal service = second business, Jira→Linear pendulum, build-vs-buy checklist _(raw: А что если наВайб-Кодить.md)_
|
||||
- [[2026-07-30-stanford-swepr-widening-gap]] — Stanford SWEPR (research dossier): 46-vs-46 teams DiD, gap 4.8%→19% (4×); ~15–20% net avg gain; gains collapse in large/legacy codebases; +91% PR review time _(raw: Stanford SWEPR - AI and the widening productivity gap.md)_
|
||||
- [[2026-07-30-rakes-in-ai-sdlc-adoption]] — Nikolai Sheiko (talk): people/companies/metrics throttle real AI gains; review is the new bottleneck; measure tasks-without-rework; developer → agent manager; Agentic Evolution + context-free-subagent skill verification _(raw: Грабли во внедрении ИИ в SDLC.md)_
|
||||
|
||||
**Raw, not yet ingested:** `raw/sources/Agentic Engineering, explained by a 10x developer.md` · `raw/sources/Webinar Plan - From Chat Box to Your Own OS.md` · `raw/sources/Webinar script.md`
|
||||
|
||||
## Coverage
|
||||
|
||||
- [[script-coverage]] — every concept vs `raw/sources/Webinar script.md`; 5 covered, 4 partial, 10 absent
|
||||
**All of `raw/sources/` is ingested.** The webinar-deliverable working notes now live in `raw/notes/` (`Ideas for webinar.md` · `Webinar Plan - From Chat Box to Your Own OS.md` · `Webinar script.md` · `my theses.md` · `introduction.md`) — treated as authored deliverables rather than sources, cited as raw where used.
|
||||
|
||||
## Entities
|
||||
|
||||
@@ -35,12 +35,16 @@ Every wiki page carries a page-type tag under its H1 (`#source`, `#entity`, `#co
|
||||
- [[nina]] — HR recruiter at Virtido; webinar-audience proxy, use-case supplier
|
||||
- [[yulia]] — HR/recruiting lead; webinar organizer (name/affiliation tentative)
|
||||
- [[larysa]] — technical BA/PM, ex-mobile dev; advanced user blocked by memory + integrations
|
||||
- [[thorsten-ball]] — founding engineer at AMP; 99% AI-written code, no skills/MCP
|
||||
- [[nikolai-sheiko]] — AI-adoption practitioner/consultant; review bottleneck, agent-manager shift, Agentic Evolution
|
||||
|
||||
### Tools / Orgs
|
||||
- [[claude-code]] — reference harness (all sources)
|
||||
- [[amp]] — Sourcegraph's agent; orbs, Oracle/Painter/Puck, vendor-curated harness
|
||||
- [[hermes]] — skills-first, self-curating harness
|
||||
- [[virtido]] — Sebastian's outsourcing company; its HR team is the webinar audience
|
||||
- [[inspectron]] — Eugene's employer (Edge Compute / IoT)
|
||||
- [[swepr]] — Stanford Software Engineering Productivity Research group (Yegor Denisov-Blanch); the corpus's quantitative outside study
|
||||
|
||||
## Concepts
|
||||
|
||||
@@ -55,6 +59,7 @@ Every wiki page carries a page-type tag under its H1 (`#source`, `#entity`, `#co
|
||||
- [[solve-first-then-skillify]] — solve the task once, then freeze it into a skill
|
||||
- [[integration-dead-ends]] — agent starts work against connectors the user's account doesn't have
|
||||
- [[leave-less-room-for-imagination]] — every gap in a spec gets filled, invisibly; tighten it
|
||||
- [[async-by-default]] — orbs/remote sandboxes; one URL = thread + agent + computation + diff; ask for proof
|
||||
|
||||
**Human side**
|
||||
- [[product-ownership]] — own outcomes, frame problems not tickets
|
||||
@@ -62,12 +67,19 @@ Every wiki page carries a page-type tag under its H1 (`#source`, `#entity`, `#co
|
||||
- [[network-from-a-standing-start]] — tentative from-zero networking protocol (v0, to be validated)
|
||||
- [[seniority-and-the-junior-squeeze]] — judgment as risk-reduction
|
||||
- [[decoupling-identity-from-profession]] — separate who you are from what you do
|
||||
- [[developer-as-agent-manager]] — CPU-bound coder → IO-bound manager of agent-employees; Judgment stays human; users vs Agentic Operations
|
||||
|
||||
**Strategy side**
|
||||
- [[think-wider-not-bigger]] — breadth over depth; match ambition to the model
|
||||
- [[code-as-throwaway]] — cost of code → zero
|
||||
- [[make-more-cheap-code]] — Theo: four tiers of code; generate never-shipped slop to verify/explore; there's always another layer
|
||||
- [[enterprise-ai-reality]] — compliance lock-down; the company-managed-harness market
|
||||
- [[shedding-weight]] — delete what only existed because humans were the bottleneck (backlogs, redundant CI, admin panels)
|
||||
- [[build-for-the-agent-not-the-human]] — no forms, no admin panels, bring your own agent
|
||||
- [[emacsification-of-software]] — fork and remix rather than upstream; software becomes bespoke
|
||||
- [[explosion-of-internal-software]] — the Excel/wiki/hack layer becomes real tools; skill + token budget as the divide
|
||||
- [[maintenance-is-the-real-cost]] — writing was never the bottleneck; internal service = second business; build-vs-buy checklist
|
||||
- [[review-is-the-new-bottleneck]] — the SDLC collapses around the humans; review with the agent; measure completed tasks without rework, never LoC/PRs
|
||||
|
||||
## Timelines
|
||||
|
||||
@@ -81,9 +93,12 @@ Every wiki page carries a page-type tag under its H1 (`#source`, `#entity`, `#co
|
||||
|
||||
- [[2026-07-14-best-first-skill-for-beginner]] — best first skill for a Claude beginner: skill-creator (meta) + tone-of-voice/anti-AI-language; foundation docs first
|
||||
- [[2026-07-14-network-from-standing-start]] — network-from-zero: tentative protocol + Sebastian round-2 interview instrument (10 questions)
|
||||
- [[2026-07-22-webinar-theses]] — 14 candidate theses for the webinar, grouped spine / stakes / obstacles / method / tensions
|
||||
- [[2026-07-22-webinar-theses]] — _superseded_ → 14 candidate theses (7-source state)
|
||||
- [[2026-07-28-webinar-theses]] — **v2, current**: 17 theses from all 10 sources; T3 reframed (*authored beats inferred*), verification / shedding-weight / ask-for-15-options added; 30-min cut + gaps in the current script
|
||||
- [[2026-07-28-verification-beat-design]] — how to add the missing verification beat: checker skill, the "right shelf" ambiguity demo, and the closing what-stays-yours half; drafted script copy
|
||||
- [[2026-07-24-non-engineer-throwaway-verification]] — non-engineer analog of throwaway verification code: generated checks not content; checker skills; drift as diagnostic
|
||||
- [[2026-07-30-stanford-widening-gap-source]] — traced the "widening gap" chart (`raw/assets/G6g3O60bkAE05ZW.png`) to Stanford SWEPR / Yegor Denisov-Blanch; first measured support for the irreversible-gap thesis; since ingested as [[2026-07-30-stanford-swepr-widening-gap]]
|
||||
|
||||
## Lint Reports
|
||||
|
||||
_None yet._
|
||||
- [[2026-07-28-lint]] — first pass: structurally clean (0 broken links, 0 orphans, 0 template/tag errors); 9 fixes applied (stale `raw/` paths, 4 one-sided contradictions, 2 staleness notes); open: a `taste` concept page, refreshing the webinar theses, weakly-linked query pages
|
||||
|
||||
129
log.md
129
log.md
@@ -6,7 +6,7 @@ Entry format:
|
||||
|
||||
```
|
||||
## YYYY-MM-DD — <operation>
|
||||
- Intent: ingest | query | lint | maintenance | sync
|
||||
- Intent: ingest | query | lint | maintenance
|
||||
- Input: <source path / question / scope>
|
||||
- Pages changed: [[...]], [[...]]
|
||||
- Notes: <what changed, uncertainty, next steps>
|
||||
@@ -148,10 +148,123 @@ Entry format:
|
||||
- Notes: Pure synthesis, no new source — every mapped pattern is grounded in corpus use cases (Nina/Yulia job descriptions, candidate KB, sourcing; Larysa spec ambiguity; Allie's anti-AI-language checker-skill precedent). Key reframes with durable value: (1) the fresh-agent misread test inverts [[leave-less-room-for-imagination]] — drift becomes a diagnostic when sandboxed; (2) [[solve-first-then-skillify]] populates skills in two species, producers and checkers. Flagged honestly: the whole mapping is argument-by-analogy with no measured claim; Nina's transcript-beats-summary finding is a standing counterweight to summary-based review.
|
||||
- Next: decide whether "checker skills" earns a slide on the webinar's skills rung; the webinar-deliverable docs (`Ideas`, `Plan`, `script`, `my theses.md`) remain un-ingested; first lint pass still overdue (9 sources, 18 concepts, 2026-07-24 now has 1 query, 0 lint reports).
|
||||
|
||||
## 2026-07-28 — sync (script coverage, initial)
|
||||
- Intent: sync script coverage
|
||||
- Input: first run of Workflow D, establishing `wiki/script-coverage.md`.
|
||||
- Pages created: [[script-coverage]] (coverage) — 19 rows, one per concept page.
|
||||
- Pages updated: `CLAUDE.md` (folder convention, `#coverage` tag row, Workflow D, new intent), `index.md` (new Coverage section; corrected the not-yet-ingested list — `Ideas for webinar.md` and `my theses.md` were listed under `raw/sources/` but live in `raw/notes/`, and `Agentic Engineering, explained by a 10x developer.md` was missing entirely).
|
||||
- Notes: Initial assessment is 5 covered, 4 partial, 10 absent. Eight of the ten absent are human-side or strategy-side per the grouping in index.md; the other two — [[integration-dead-ends]] and [[leave-less-room-for-imagination]] — are machine-side, absent because the script demos the happy path and never reaches connector gating or spec ambiguity. The `ReAct` station carries no wiki concept. No concept pages were edited.
|
||||
- Next: decide whether the human-side cluster earns a station or is a deliberate cut; decide separately whether the two absent machine-side failure modes belong in the demo; pin the rows that are decided so future syncs leave them alone.
|
||||
## 2026-07-28 — ingest (Agentic Engineering, explained by a 10x developer)
|
||||
- Intent: ingest
|
||||
- Input: "ingest \"Agentic Engineering, explained by a 10x developer\"" → `raw/sources/Agentic Engineering, explained by a 10x developer.md` (conclusions doc for a 42:33 YouTube interview; Thorsten Ball × David Andre). The densest single source in the vault so far.
|
||||
- Pages created — source (1): [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- Pages created — entities (2): [[thorsten-ball]] (founding engineer at AMP; author of the Go interpreter/compiler books), [[amp]] (Sourcegraph's agent — the vault's second reference harness).
|
||||
- Pages created — concepts (5): [[shedding-weight]] (delete process that only existed because humans were the bottleneck — backlogs, CI that repeats the agent's tests, IDE extensions, local dev), [[build-for-the-agent-not-the-human]] (no forms; the admin panel that dies; bring your own agent), [[emacsification-of-software]] (fork-and-remix, never upstream; software becomes bespoke), [[explosion-of-internal-software]] (the Excel/wiki/hack layer becomes real tools; skill + token budget as the two dividing variables), [[async-by-default]] (orbs as remote sandboxes; one URL = thread + agent + computation + diff; ask for proof since you're waiting anyway).
|
||||
- Pages updated — concepts (10): [[skills-as-memory]] (**the dissent**, plus three competing readings under Contradictions), [[evolution-of-agent-tooling]] ("a fourth position: skip the progression"; A2A partially answered by AMP's agent-to-agent messaging), [[harness]] (AMP as second reference harness; vendor-managed as a third governance option; local-vs-remote tension), [[context-as-scarce-resource]] (information > tuning; the two information sources; context as scarce per-*wallet*), [[code-as-throwaway]] (99%-AI-written production datapoint; slop-is-human), [[make-more-cheap-code]] (variations-not-answers; ask-for-proof; attention-vs-token-budget sharpening), [[product-ownership]] (first-principles as the top skill; the printer/tablet push-back; what got commoditised), [[seniority-and-the-junior-squeeze]] (2–3 years of hand-taught knowledge → 30-second output; "don't compare yourself to the 1%"), [[enterprise-ai-reality]] (token budget as a second divide; why the frontier playbook doesn't transfer), [[leave-less-room-for-imagination]] (his 5-part prompt structure as a worked example; model-choice tension), [[personal-ai-operating-system]] (the fourth layer: tools you build for yourself).
|
||||
- Pages updated — entities (2): [[theo-browne]] (ally cross-link), [[claude-code]] (AMP as the contrasting harness design). Plus [[overview]] (9→10 sources; new "frontier side" of the through-line; agree/diverge rewritten; 3 new vault-level open questions) and `index.md`.
|
||||
- Notes: **The important thing this source does is contradict the vault's spine.** Thorsten ships a 99%-AI-written codebase with no skills, no MCP servers and no slash commands — his context lives in the codebase and `AGENTS.md`. This is the first credible rejection of the mechanism the webinar's central promise rests on, and the evidential asymmetry favours him (first-hand daily practice at scale vs Konstantin's architecture argument plus self-reported individual workflows). Recorded as three competing readings on [[skills-as-memory]] — situational (he owns one codebase; the HR/BA audience owns none) / premature abstraction / same thing under another name (AMP's vendor-curated sub-agents and `AGENTS.md` *are* two-stage context, just not user-authored). Not smoothed, not resolved. Second-order tensions logged: model choice as lever (Eugene 4.7-over-4.8) vs distraction (Thorsten); local consolidated workspace (Eugene) vs local dev disappearing (Thorsten); shed-your-process (frontier) vs compliance-is-the-deliverable ([[enterprise-ai-reality]]).
|
||||
- Also strongly *confirmatory*: the club food-ordering app (menu photo → working app, then ~2 hours of phone typing to encode a 20-person club's ordering process) is the corpus's best outside evidence for the webinar's "little tools you make for yourself" thesis — reached independently, by an engineer, applied to non-technical people. And "slop comes from humans" converges with Theo from a different direction (taste vs verification discipline).
|
||||
- New named variable with no answer anywhere in the corpus: **token budget** as one of two winner/loser variables. Elevated to a vault-level open question.
|
||||
- All quantities self-reported from inside the company selling the agent (99% figure, the team poll, velocity claims) — flagged tentative throughout. "Local dev is going away" is a prediction from a remote-sandbox vendor — flagged.
|
||||
- Housekeeping: corrected the stale `index.md` "not yet ingested" list — those four webinar docs moved to `raw/notes/` (commit 1361dd7) and are authored deliverables, not sources. `raw/sources/` is now fully ingested (10/10).
|
||||
- Next: the highest-value move is now a **lint pass** — 10 sources, 24 concepts, 0 lint reports, and this ingest added five concepts plus a live contradiction that touches the spine. Candidate query with real stakes for the webinar: *does the skills rung survive Thorsten's counter-example, and what would test it?* (the cheap experiment — same task with and without a skill, in a non-engineer's hands — has never been run). Also worth considering: a comparison page "Thorsten vs the skills camp", and whether [[shedding-weight]] / [[explosion-of-internal-software]] earn stations on the webinar spine.
|
||||
|
||||
## 2026-07-28 — lint (first pass)
|
||||
- Intent: lint
|
||||
- Input: "lint wiki" — first health check on the vault (10 sources · 24 concepts · 14 entities · 4 queries · 1 comparison · 1 timeline; 0 prior lint reports).
|
||||
- Pages created: [[2026-07-28-lint]] (first `wiki/lint-reports/` page).
|
||||
- Checks run: page-type tags vs folder + line-3 placement (41/41 pass) · H1 presence (41/41) · required template sections for sources (10/10) and entity/concept pages (38/38) · Evidence sections citing ≥1 source page (38/38) · broken `[[links]]` (0) · orphans (0) · zero-outbound pages (0) · `index.md` ↔ `wiki/concepts/` drift (0, 24/24 in sync) · `raw/` path resolution (5 failures) · contradiction reciprocity · high-mention concepts lacking pages · link-graph inbound/outbound counts.
|
||||
- Headline: **structurally clean; the real defects were all staleness of synthesis.** 12 findings, 9 fixed in this pass, 3 left as recommendations because they are scope decisions rather than defects.
|
||||
- Fixes applied — references (3): stale `raw/sources/` paths for the four deliverable docs that moved to `raw/notes/` in commit 1361dd7, corrected in [[levels-of-ai-usage]], [[2026-07-22-webinar-theses]] and [[2026-07-14-sebastian-eugene-interview]] (5 refs, reworded "not yet ingested" → "authored deliverable"); [[claude-code]] summary said "cited across all four ingested sources" (written at 4 sources, now 10) — rewritten to a claim that won't rot, noting Thorsten as the sole practitioner on a different harness; [[overview]] open question naming `HR Contacts` (a file that does not exist — corrected in `index.md` on 2026-07-21 but never propagated here) marked resolved.
|
||||
- Fixes applied — one-sided contradictions (4): rule 5 requires contradictions be recorded explicitly, and four were logged on one page but not on the page holding the opposing view. Added reciprocal entries to [[think-wider-not-bigger]] (vs tight specs), [[levels-of-ai-usage]] (the skills dissent — its *top rung* is what Thorsten contests), [[personal-ai-operating-system]] (memory-as-anti-feature vs its *layer 1*, plus the skills dissent vs its layer 2), [[skills-as-memory]] (skills-vs-RAG, which its own Summary asserts as settled). L5 and L6 were the consequential ones: in both, the page *making* the contested claim was the page not carrying the objection.
|
||||
- Fixes applied — staleness notes (2): [[2026-07-22-webinar-theses]] (synthesized from 7 sources, 10 now exist; thesis 3 "Skills are the new memory" is load-bearing and its counter-example was missing from its own tensions list; nothing from the last two ingests appears) and [[theo-konstantin-allie]] (predates Theo's second source and Thorsten; its closing "none of the three directly contradicts another" now misleads about the skills thread). Both preserved rather than rewritten, per the Update Policy's no-silent-large-rewrites rule.
|
||||
- Open findings (not fixed — scope decisions): **(1)** "taste" is the vault's largest uncovered concept — 12 pages / 17 occurrences, one of four nouns in the through-line, the other three all have pages; named the meta-skill by Allie and the whole slop answer by Thorsten; recommend a concept page. **(2)** Query pages are a weakly-linked class (0/1/2/2 inbound); [[2026-07-22-webinar-theses]] is effectively orphaned despite being the most webinar-relevant page in the vault. **(3)** Watch items: [[2026-07-22-ai-is-stupid]] is thinly integrated (2 citing pages vs a median of ~17, plausibly correct since it restates rather than adds); [[emacsification-of-software]] + [[explosion-of-internal-software]] should merge if neither gains second-source support by the next lint. Considered and rejected as a new page: "trust calibration" — covered by [[make-more-cheap-code]] + [[code-as-throwaway]] + [[seniority-and-the-junior-squeeze]]; creating it would duplicate rather than consolidate.
|
||||
- Contradiction inventory: 9 live disagreements, now all recorded on both sides. #1 (skills-as-memory vs no-skills-at-all) is the vault's most consequential open question because the webinar's central promise rests on it.
|
||||
- Next: refresh [[2026-07-22-webinar-theses]] against all 10 sources (fixes the staleness and most of the weak-linking in one operation, and is the page closest to the deliverable); create the `taste` concept page; extend [[theo-konstantin-allie]] to four lenses. The falsification test flagged on [[skills-as-memory]] — same task with and without a skill, in a non-engineer's hands — remains the cheapest experiment that would move contradiction #1.
|
||||
|
||||
## 2026-07-28 — query (webinar theses v2 — refresh)
|
||||
- Intent: query
|
||||
- Input: "Refresh 2026-07-22-webinar-theses" — acting on the top recommendation from [[2026-07-28-lint]] (v1 was two ingests stale and effectively orphaned).
|
||||
- Pages created: [[2026-07-28-webinar-theses]] (17 theses from all 10 sources + the current deliverable state in `raw/notes/`).
|
||||
- Pages updated: [[2026-07-22-webinar-theses]] (staleness note replaced with a **SUPERSEDED** banner summarising what changed and pointing forward — preserved as the 7-source state, not overwritten, per the Update Policy); backlinks added from [[explosion-of-internal-software]], [[skills-as-memory]], [[shedding-weight]] and [[2026-07-24-non-engineer-throwaway-verification]] so v2 does not repeat v1's orphaning; `index.md` (Queries section marks v1 superseded, v2 current).
|
||||
- Method note: created as a **new dated page** rather than editing v1 in place. Query pages are dated Q&A snapshots (`wiki/queries/YYYY-MM-DD-<slug>.md`); rewriting the 07-22 file would have made its date lie and would have been a silent large rewrite of a dated artifact.
|
||||
- Substantive changes to the thesis set: **(1) T3 reframed** from "skills are the new memory" to *"context you author beats context that's inferred"* — the v1 wording has a live counter-example in [[thorsten-ball]], and the reframe is what all four practitioners actually agree on (Konstantin's skills, Allie's foundation docs, Eugene's anti-memory position, Thorsten's `AGENTS.md` are all authored context). It survives all three readings logged on [[skills-as-memory]] and keeps the script's Memory→Skills stations intact. **(2) T5 upgraded from assertion to evidence** — [[explosion-of-internal-software]] supplies a non-engineer-shaped outside case (20-person club, phone, menu photo, ~2 hours), which defuses the "sure, *you* can do that, you're technical" objection against the talk's least-provable claim. **(3) Three new theses** the earlier set had no source for: T6a verification/ask-for-checks, T10 shedding weight ("which of your processes only exist because *you* were the bottleneck?"), T13a ask-for-15-options. **(4) T1 strengthened** — Thorsten's "stop tuning model choice; the dominant variable is the information you put in" makes harness-not-model the best-evidenced claim in the vault, and it is already the script's literal closing argument. **(5) New honest caveat** — token budget as a second, non-skill axis of the gap.
|
||||
- Revised 30-min cut: T2 · T4 · T3 · T6a · T1 · T5 · T15, mapped to script beats. Changed from v1's recommendation: T3 reframed, T6a added, T12 promoted (it now has a teachable five-part prompt structure from Thorsten rather than an abstract principle), T9 demoted to Q&A.
|
||||
- Also produced: a Q&A-ammo section stating the skills dissent honestly with the three readings and the presentation-safe framing, and **three gaps the refresh exposes in the current script** — no verification beat (the audience's first question is "can I trust it?" and the script never once shows the agent being checked), no "what stays yours" beat (the closing arc is entirely harness, not human), and the unsaid token-budget caveat against the "a laptop, one hour, and your real work" promise.
|
||||
- Read directly for this refresh: `raw/notes/Webinar script.md` (current ladder: Chat box → ReAct → Tools → Memory → Skills → Process → OS), `raw/notes/Webinar Plan - From Chat Box to Your Own OS.md`, `raw/notes/my theses.md`. Notable: T4 and T1 are already dramatized in the script better than a slide could do it ("the notebook is tiny. On purpose."; "the model never changed").
|
||||
- Next: decide whether T6a earns a station or one line inside the Skills station (recommend the latter — a checker skill is one sentence of demo and costs no new level); decide whether T10 opens the talk rather than closing it; the remaining lint recommendations stand (create a `taste` concept page; extend [[theo-konstantin-allie]] to four lenses). The falsification test on [[skills-as-memory]] would settle T3's tension and would itself make a strong demo.
|
||||
|
||||
## 2026-07-28 — maintenance (token-budget claim rescoped; webinar gap #3 withdrawn)
|
||||
- Intent: maintenance
|
||||
- Input: user objection to gap #3 in [[2026-07-28-webinar-theses]] — every LM vendor sells a subscription, that subscription covers even advanced users, so "budget" reduces to subscription cost, which is obvious.
|
||||
- Assessment: **objection upheld, and the corpus supports it more strongly than the original write-up did.** The token-budget claim was recorded at ingest as an unqualified "the divide is also a *spending* gap" without weighing three counter-datapoints already in the vault: [[eugene]] runs 7 project-agents in parallel on a $200 plan; [[allie-miller]] runs ~100 agents and 36 workflows; and [[2026-07-14-sebastian-eugene-interview]] frames levelling as "a 20-year veteran and a fresh grad **on the same subscription**." No practitioner in the corpus reports a cost ceiling. The claim's real scope is **metered** pricing — [[amp]] sells usage, and Thorsten's pattern is parallel remote sandboxes and parked orbs ([[async-by-default]]) — which is a fleet cost, not a seat cost.
|
||||
- Pages changed: [[enterprise-ai-reality]] (scoping sub-bullet added under the token-budget item, with the counter-evidence named), [[explosion-of-internal-software]] (the "two variables" bullet rescoped; its Contradictions entry partly resolved and marked tentative), [[context-as-scarce-resource]] ("context now has a price" → "…at fleet scale"; per-request scarcity restated as the binding constraint for individuals), [[overview]] (vault-level open question narrowed to fleet/enterprise allocation), [[2026-07-28-webinar-theses]] (gap #3 withdrawn with the reasoning recorded inline; T7's "second axis" line rescoped so the thesis stays on the skill gap).
|
||||
- Claim preserved, not deleted, per rule 5 — Thorsten did say it and it stands in its own regime. What changed is scope and the counter-evidence, both now stated on every page carrying it.
|
||||
- Residual open: metered/fleet pricing and enterprise budget allocation remain unanswered; [[eugene]]'s price-rise prediction ("what I now buy for 200 will cost about 1,000") would reopen the question for individuals if it holds — currently a forecast, not a constraint. Status: tentative.
|
||||
- Notes: worth flagging as a process lesson — the claim came from a credible source and was written up the same session it arrived, without checking it against the vault's existing practitioner evidence. A source's framing of its own economics is not automatically the corpus's.
|
||||
|
||||
## 2026-07-28 — query (verification beat design)
|
||||
- Intent: query
|
||||
- Input: "What are your suggestions for verification beat? What can we add?" — following the gap flagged in [[2026-07-28-webinar-theses]].
|
||||
- Pages created: [[2026-07-28-verification-beat-design]] (placement analysis, three options costed by seconds, drafted script copy in the script's voice, audience-translation lines, honest caveats).
|
||||
- Pages updated: [[2026-07-28-webinar-theses]] (T6a now points to the design page); `index.md` (Queries).
|
||||
- Key synthesis: **the verification beat and the "what stays yours" beat are the same beat** — verification is exactly where the human's remaining job lives ([[product-ownership]]) — so one insertion closes both gaps the refresh identified. Matters for a 30-min format.
|
||||
- Placement argument: the audience's unease peaks at one specific existing line in the Process station ("I take my hands off the keyboard… Nobody is typing. It just... runs."). Answer it there, not in Q&A. Recommended split: introduce the checker skill at **Skills** (~60–90s), cash it in at **Process** (~20s, reuses an existing reveal), put the judgment half in the **closing arc** (~30s).
|
||||
- Three options by cost: **(1)** ~15s and free — the Process station already reveals the prompt the shell wrote for its worker; add one visible self-check line to that artifact, no new demo steps. **(2)** ~60–90s recommended — a second skill whose only job is to check the first, demonstrated by breaking the state *by hand* so the audience sees the error before the agent reports it; introduces the producer/checker species split from [[2026-07-24-non-engineer-throwaway-verification]] at no new level. **(3)** ~30s standalone — **the script already contains a perfect ambiguity example**: the Process goal line says "keep the cube on the **right shelf**", which reads as *correct* shelf or *right-hand* shelf. The colon disambiguates it as written, so the unsafe version can be shown deliberately as a live demo of [[leave-less-room-for-imagination]] (currently thesis T12 with no demo) and as motivation for the checker.
|
||||
- Closing half drafted to fill gap #2: a checker catches drift but can never catch a wrong rule ("if twenty degrees was the wrong number, both agents agree, confidently, forever") → "the machine checks whether the thing was done right; you check whether it was the right thing." Converts the ending from capability to the audience's own value.
|
||||
- Caveats recorded rather than smoothed: a checker authored by the agent it checks is not independent verification (the same limit already logged on [[async-by-default]] — proof produced by the thing being checked is evidence, not verification); [[nina]]'s transcript-beats-summary finding is a standing counterweight against implying reading is now optional; and none of this has been tested on a non-engineer audience, which is why the audience-translation lines after option 2 are load-bearing rather than optional.
|
||||
- Note: `raw/notes/Webinar script.md` was read but **not modified** (rule 1). All drafted copy lives in the wiki for the user to apply.
|
||||
- Next: gap #2 is now addressed by this design; the remaining lint recommendations stand (create a `taste` concept page; extend [[theo-konstantin-allie]] to four lenses). Open decision from the refresh — whether T10 ("which processes only exist because you were the bottleneck?") opens the talk.
|
||||
|
||||
## 2026-07-28 — maintenance (authorized raw edit: "right shelf" ambiguity demo) + theses legend
|
||||
- Intent: maintenance
|
||||
- Input: user — "That's a great idea about the 'right shelf'. would be a perfect demo. add it." Plus a question about the `T<number>` shorthand.
|
||||
- **Authorized raw edit** (exception to rule 1, on direct instruction; same pattern as the 2026-07-14 script edits logged above): `raw/notes/Webinar script.md`, Process station. Inserted the ambiguity demo between "…but a goal." and the real goal line — deliberately sloppy prompt ("keep the cube on the right shelf") → agent moves the cube to the right-*hand* shelf → "That's not what I meant. I meant the *correct* shelf. It heard: the shelf on the *right*." → "It didn't ask. It didn't hesitate… It just confidently did the wrong thing." → "Every gap you leave, it fills. And it fills it silently." → ties into the hands-off moment a minute later and reuses Marcus's own word: "Marcus said: don't let it drift. Turns out the first thing that drifts… is what I meant." → then the precise goal as originally written.
|
||||
- Placement rationale: kept at Process rather than moved to Skills (the design page's alternative) because the user is adding the ambiguity demo *alone*, without the checker skill — standalone it is strongest where the ambiguous phrase already lives and where handing over control is imminent. If the checker skill (option 2 of [[2026-07-28-verification-beat-design]]) is added later, this beat should move earlier so the problem precedes its solution.
|
||||
- **Stage-safety note added inline** (`_note:`): a modern model may disambiguate "right shelf" correctly from context, so this beat must be pinned to a deterministic response or a low-temp on-rails prompt. Consistent with the Plan's existing "never a naked live call" production rule. Without pinning, the demo can silently succeed and kill the point on stage.
|
||||
- Effect on the wiki: this is the first *demo* of [[leave-less-room-for-imagination]] in the deliverable — thesis T12 previously had no dramatization. The script's own accidental ambiguity became the example.
|
||||
- Pages changed: [[2026-07-28-webinar-theses]] — added a legend explaining the `T<number>` shorthand (T = thesis; stable handles for cross-referencing; T1–T15 follow v1's order where the thesis survived; letter suffixes mark v2 additions placed beside their nearest relative instead of renumbering). This was an undocumented convention I introduced in v2 and the user was right to flag it.
|
||||
- Next unchanged: decide on the checker skill (option 2) and the closing what-stays-yours half from [[2026-07-28-verification-beat-design]]; remaining lint recommendations stand (a `taste` concept page; extend [[theo-konstantin-allie]] to four lenses).
|
||||
|
||||
## 2026-07-29 — ingest (А что если наВайб-Кодить / "What if we vibe-code it?")
|
||||
- Intent: ingest
|
||||
- Input: `raw/sources/А что если наВайб-Кодить.md` — viewer's conclusions from a 5:31 Russian YouTube video (author unknown; his company pays "millions a year" for Datadog). 11th source; `raw/sources/` fully ingested again.
|
||||
- Pages created: [[2026-07-29-what-if-we-vibe-code-it]] (source), [[maintenance-is-the-real-cost]] (concept — 25th).
|
||||
- Core of the source: **writing code was never the bottleneck — maintenance is.** Developers never skipped building their own Jira/Datadog for lack of ability; they skipped it because they didn't want to *run* the result. An internal service is a second IT business (bad for the company and the developer both); "I can write it in a week" ≠ "worth writing"; the vendor sells operational offload, not code. Evidence: the pendulum case — a company builds its own Jira clone (March 2026) and returns to a bought tracker, Linear, by July. Prescription: a build-vs-buy checklist (dependency size / ongoing support / operational load / second-business willingness). The author also retracts his own earlier "many services will die because of AI" claim.
|
||||
- Why it matters to this vault: it is the **first dedicated counterweight to the build-everything-yourself thread** ([[explosion-of-internal-software]], [[emacsification-of-software]]) — and both of those pages had already flagged "maintenance is assumed away" as their own weakest point, so the objection was latent and is now sourced with the corpus's only *observed outcome* of the pattern (a reversal). Reconciliation recorded on both sides: Thorsten's club app *passes* the source's own checklist (tiny, personal, no SLA), his "teams will remix Riverside" prediction is what the checklist rejects — the disagreement is a threshold, not a winner. Separately, the source *agrees* with the vault's spine from a new angle: "writing was never the bottleneck" is the harness-over-model premise; the corpus now holds three named bottlenecks that don't compete — context (Thorsten, authoring time), verification (Theo, ship time), maintenance (this source, lifetime).
|
||||
- Pages updated: [[explosion-of-internal-software]] (contradiction upgraded from self-criticism to sourced, threshold reconciliation, next-question sharpened), [[emacsification-of-software]] (maintenance objection sourced; `~/bin` fork passes, team remix doesn't), [[code-as-throwaway]] (new "lifetime boundary" bullet — throwaway is safe *because* unmaintained; first user converts code into a service), [[thorsten-ball]] (contradiction added, tentative both sides — one anecdote vs one prediction), [[overview]] (11 sources; frontier bullet counterweight; new divergence entry; concept count), [[2026-07-28-webinar-theses]] (T5 scoping note: the thesis survives — its examples are checklist-safe — and gains a one-sentence inoculation against the sharpest technical-audience pushback), `index.md`.
|
||||
- Uncertainty flagged: the pendulum case is second-hand tweets with fuzzy company identification (tentative); the checklist is prescriptive, not observed; the author's own company is currently building a Datadog replacement — if it ships and survives, he becomes his own counterexample. Open question with no evidence either way in the corpus: does the maintenance objection survive *agents* doing the maintenance ([[agentic-loops]], [[async-by-default]])?
|
||||
- Effect on the last lint's watch item: [[emacsification-of-software]] and [[explosion-of-internal-software]] were merge candidates "if neither gains second-source support by the next lint" — both now have second-source engagement (as a bounding counterpoint), which argues for keeping them separate with [[maintenance-is-the-real-cost]] as the shared boundary page.
|
||||
- Next: the standing recommendations are unchanged (a `taste` concept page; extend [[theo-konstantin-allie]] to four lenses; the skills falsification test). New candidate question for the HR audience: which of their candidate tools (candidate knowledge base, transcribe→summarize) fall on the safe side of the build-vs-buy checklist — directly webinar-relevant if Q&A raises "should we build or buy?"
|
||||
|
||||
## 2026-07-30 — query (Stanford "widening gap" chart traced to source)
|
||||
- Intent: query
|
||||
- Input: user saved `raw/assets/G6g3O60bkAE05ZW.png` (X/Twitter screenshot of a Stanford slide, "Teams that master AI are accelerating their productivity gains, widening the gap with laggards") and asked to find the original research.
|
||||
- Pages created: [[2026-07-30-stanford-widening-gap-source]] (query — the slide is from Stanford's Software Engineering Productivity Research group (SWEPR), Yegor Denisov-Blanch; 600+ companies / 120k+ engineers since 2022; the chart is a 46-vs-46-team difference-in-differences analysis showing the AI-adopter productivity gap growing 4.8% → 19% (4×) from April 2023 to July 2025; slide matches his Sept 2025 AI Conference deck "Will AI Replace Software Engineers?"; primary links recorded on the page).
|
||||
- Pages updated: [[2026-07-14-gap-between-ai-users-irreversible]] (external-corroboration pointer under Connections — Allie's title claim gains its first measured, non-practitioner support), `index.md` (Queries).
|
||||
- Notes: the DiD result itself is talk/deck-published, not peer-reviewed — marked tentative; only the measurement methodology has a peer-reviewed paper (arXiv 2409.15152). Nuance recorded: same study finds ~15–20% average gains with AI *decreasing* net productivity in complex legacy codebases (rework, +91% PR review time) — honest-caveat material aligning with [[maintenance-is-the-real-cost]] and [[make-more-cheap-code]]. No concept pages changed (citation policy: the talk is not yet an ingested source).
|
||||
- Next: decide whether to ingest the talk/deck as a proper `raw/sources/` doc (would let concept pages and the webinar theses cite it as `wiki/sources/*` evidence); consider adding the "Stanford measured it: 4× in two years" line to the webinar's stakes beat; watch for a peer-reviewed version of the DiD analysis.
|
||||
|
||||
## 2026-07-30 — ingest (Stanford SWEPR — AI and the widening productivity gap)
|
||||
- Intent: ingest
|
||||
- Input: user — "Create the source. I'm giving you permission to write a new file in the sources folder." **Authorized raw write** (exception to rule 1, new file only): created `raw/sources/Stanford SWEPR - AI and the widening productivity gap.md`, a research *dossier* compiled from the saved slide screenshot (`raw/assets/G6g3O60bkAE05ZW.png`) plus public coverage — honestly marked as not-a-transcript, with per-claim provenance (slide-read vs secondary coverage). 12th source; the corpus's first quantitative outside study.
|
||||
- Pages created: [[2026-07-30-stanford-swepr-widening-gap]] (source), [[swepr]] (entity — Stanford Software Engineering Productivity Research group, Yegor Denisov-Blanch; 15th entity).
|
||||
- Pages updated: [[levels-of-ai-usage]] (evidence: measured team-level twin of the mastery gap, with the non-engineer-audience caveat), [[context-as-scarce-resource]] (evidence: gains collapse toward 10M LOC via context-window limits — first outside quantitative support for context-as-constraint), [[make-more-cheap-code]] (evidence: +91% PR review time / 2.6× rework = the cost moving downstream, measured; brownfield-negative caveat), [[2026-07-14-gap-between-ai-users-irreversible]] (corroboration pointer upgraded to cite the source page), [[2026-07-28-webinar-theses]] (T7 note: thesis upgraded from prediction to measurement, with a citable stage line), [[2026-07-30-stanford-widening-gap-source]] (ingest follow-up marked done), [[overview]] (11→12 sources; stakes-claim measurement added to the agree section; navigation), `index.md`.
|
||||
- Notes: the source *corroborates* rather than contradicts — no new contradictions logged, but three caveats recorded on the source page and carried into every citing page: the DiD analysis is talk-published, not peer-reviewed (tentative); the rework/review numbers are secondary coverage; the study measures engineering teams, not the webinar's non-engineer audience. Deliberately did **not** claim the study validates the *skills* rung specifically — Stanford asserts "quality of usage" as the differentiator without decomposing it, so it cannot arbitrate contradiction #1 (skills vs no-skills). The webinar theses' T7 gains the corpus's best number: gap 4.8% → 19% (4×), April 2023 → July 2025.
|
||||
- Next: watch for a peer-reviewed version of the DiD analysis (status upgrade); candidate webinar edit — the one-line "Stanford measured it: the gap quadrupled in two years" in the stakes beat (user's call, script is an authored deliverable); standing recommendations unchanged (a `taste` concept page; extend [[theo-konstantin-allie]] to four lenses; the skills falsification test).
|
||||
|
||||
## 2026-07-30 — maintenance (authorized raw edit: Stanford beat in the script's closing arc)
|
||||
- Intent: maintenance
|
||||
- Input: user — "good idea to add it to the webinar script. Do it."
|
||||
- **Authorized raw edit** (exception to rule 1, on direct instruction; same pattern as the 2026-07-14/07-28 script edits): `raw/notes/Webinar script.md` — inserted a Stanford beat into the closing arc, between "You don't buy it. You build it — one small tool at a time." and "We started this journey…". The beat: Stanford tracked 46 AI teams vs 46 matched non-AI teams for 2+ years → the teams that *learned* it pulled away from the ones that just *had* it → spread under 5% (spring 2023) → 19% (summer 2025) → "the gap quadrupled in two years" → callback to the script's own reveal: "everyone had the same models the whole time. The difference was never the model. It was who built something around it."
|
||||
- Placement rationale: the closing arc is where the script's "same model, different harness" argument lands, and the Stanford curve is that exact argument as data — it also answers "why start now" right before the final chat-box→OS callback. Phrasing kept factually careful: the widening spread is *among AI-using teams* (masters vs laggards), so the beat says "pulled away from the ones that just had it," not "AI users vs non-users."
|
||||
- Stage-safety/honesty note added inline (`_note:`): source pointer to [[2026-07-30-stanford-swepr-widening-gap]] plus the three Q&A caveats (talk-published not peer-reviewed; software teams not office workers; "quality of usage" asserted but not decomposed).
|
||||
- Pages changed: [[2026-07-28-webinar-theses]] (T7 note updated — dramatized in the script as of today, promoted from Q&A material to an on-stage beat). No other wiki pages changed; `index.md` unchanged (no catalog change).
|
||||
- Note on scope: the Stanford research itself was already fully ingested earlier today ([[2026-07-30-stanford-swepr-widening-gap]] + [[swepr]] — see the previous ingest entry); this operation only carries the number into the deliverable.
|
||||
- Next: unchanged from the ingest entry (peer-review watch; `taste` concept page; four-lens comparison; skills falsification test).
|
||||
|
||||
## 2026-07-30 — ingest (Грабли во внедрении ИИ в SDLC / Nikolai Sheiko)
|
||||
- Intent: ingest
|
||||
- Input: `raw/sources/Грабли во внедрении ИИ в SDLC.md` — viewer's conclusions from Nikolai Sheiko's 45:59 Russian YouTube talk ("why the AI is there but the results aren't"). 13th source; `raw/sources/` fully ingested again.
|
||||
- Pages created: [[2026-07-30-rakes-in-ai-sdlc-adoption]] (source), [[nikolai-sheiko]] (entity — 16th), [[review-is-the-new-bottleneck]] and [[developer-as-agent-manager]] (concepts — 26th and 27th).
|
||||
- Core of the source: models are already good enough — **people, companies and metrics throttle the gains by an order of magnitude**. The SDLC collapsed into days/hours but not around the two human "red squares" (reviewer, planner); the fix is review *with* the agent plus the one metric that resists gaming — **completed tasks without rework** (never LoC/commits/PRs; his outsourcer case: more PRs, +1% net). Error #0: the AI-developer is an IO-bound **manager of an agent-employee**, not a CPU-bound coder ("sit watching Claude Code work = bad employee") — and not everyone can or should switch. "Companies no longer need custom AI development — install Claude Code/Codex, configure, attach connectors, mind security." **Agentic Evolution**: walk the agent through hard tasks → "remember this and write the manual for the next one" → verify via a **context-free subagent** solving the task from the skill alone. Compaction curse on big codebases → best practices exist *for the agent* (locality, interfaces, AST search over grep); embeddings/RAG over code rejected flatly.
|
||||
- Why it matters to this vault: (1) **second practitioner vote for the skills layer**, narrowing the evidential asymmetry Thorsten's dissent enjoyed on [[skills-as-memory]] — and his verification protocol is the corpus's first described run of anything like the proposed skills falsification test (with-skill half only; no without-skill control, so the test question stands). (2) **Independent citation of the Stanford chart** ([[swepr]]) as his stakes slide, plus an anecdotal mirror of its +91%-review-time finding — recorded on [[2026-07-30-stanford-swepr-widening-gap]]. (3) Names the org-level bottleneck the corpus had only as an open question on [[async-by-default]] (parallel diffs pile up on a human) — now a page: [[review-is-the-new-bottleneck]]. (4) His anti-RAG-for-code stance supports the audience-driven reading of the skills-vs-RAG contradiction on [[context-as-scarce-resource]] (anti-RAG votes are about code/procedures; the pro-RAG vote is about business data).
|
||||
- Pages updated: [[solve-first-then-skillify]] (Agentic Evolution + 5-step verification protocol; next-question partially answered), [[skills-as-memory]] (evidence + asymmetry softened + falsification-test note), [[context-as-scarce-resource]] (compaction curse; codebase-stores-context converging with Thorsten from the opposite direction; AST search; RAG contradiction note), [[async-by-default]] (IO-bound-manager evidence; related links to both new concepts), [[enterprise-ai-reality]] (no-custom-AI-dev quote as the managed-harness market seconded; external-configurator vs teacher/curator anti-pattern; Cursor metered billing → team economizes, the metered-vs-subscription split observed organizationally; tokens-dearer-then-cheaper matching Eugene's prediction), [[make-more-cheap-code]] (related link to the review-bottleneck page), [[2026-07-30-stanford-swepr-widening-gap]] (independent-citation pointer), [[overview]] (12→13 sources; new "adoption side" bullet; agree/diverge updates; skills-dissent paragraph rebalanced), `index.md`.
|
||||
- New contradiction logged (on [[developer-as-agent-manager]]): Sheiko's "don't force everyone" vs the irreversible/compounding gap (Allie, Stanford) — opting out is legitimate *and* costly; no source reconciles the two. Also tentative: all client cases are anonymous self-reported anecdotes; "embeddings over code don't work" has no mechanism given; the users-vs-Agentic-Operations split is prediction, not observation.
|
||||
- Uncertainty about the speaker himself: affiliation unknown; "you don't need custom AI development" is also a consultant's pitch — flagged on [[nikolai-sheiko]].
|
||||
- Webinar relevance noted but not applied (script untouched): the Intelligence-vs-Judgment framing is close kin to the planned "what stays yours" closing beat, and the talk independently strengthens the case for the standing `taste` concept-page recommendation (Judgment = taste-built-over-years or domain expertise — a second source alongside Thorsten's).
|
||||
- Next: standing recommendations unchanged (a `taste` concept page — now with two sources backing it; extend [[theo-konstantin-allie]] to four lenses; the skills falsification test — half-run by this source, control still missing). New candidate question: what does review-with-the-agent look like concretely (no transcript of it done well exists in the corpus).
|
||||
|
||||
Binary file not shown.
BIN
raw/assets/G6g3O60bkAE05ZW.png
Normal file
BIN
raw/assets/G6g3O60bkAE05ZW.png
Normal file
Binary file not shown.
|
After Width: | Height: | Size: 343 KiB |
@@ -424,6 +424,42 @@ Watch what happens when I give it — not a task...
|
||||
|
||||
...but a goal.
|
||||
|
||||
Actually — hold on.
|
||||
|
||||
Before I hand over control, let me be sloppy on purpose.
|
||||
|
||||
"keep the cube on the right shelf"
|
||||
|
||||
{AI moves the cube to the right-hand shelf}
|
||||
|
||||
_note: stage-critical — a modern model may well disambiguate "right shelf" correctly from context. Pin this beat to a deterministic response (or a low-temp on-rails prompt) so it reliably picks the right-hand shelf._
|
||||
|
||||
That's not what I meant.
|
||||
|
||||
I meant the *correct* shelf.
|
||||
|
||||
It heard: the shelf on the *right*.
|
||||
|
||||
And notice what it didn't do.
|
||||
|
||||
It didn't ask. It didn't hesitate. It didn't flag anything.
|
||||
|
||||
It just confidently did the wrong thing.
|
||||
|
||||
Every gap you leave, it fills.
|
||||
|
||||
And it fills it silently.
|
||||
|
||||
Right now that's harmless — I'm sitting here, I can see the cube.
|
||||
|
||||
But in a minute I'm going to walk away from this keyboard.
|
||||
|
||||
Marcus said: don't let it drift.
|
||||
|
||||
Turns out the first thing that drifts... is what I meant.
|
||||
|
||||
So let's say exactly what we mean.
|
||||
|
||||
"keep the cube on the right shelf: below 20 — top, above 20 — bottom. continuously."
|
||||
|
||||
{AI spawns a process — "started process 1"}
|
||||
@@ -602,6 +638,32 @@ Your harness is unique to you.
|
||||
|
||||
You don't buy it. You build it — one small tool at a time.
|
||||
|
||||
---
|
||||
|
||||
And don't take my word for why this matters *now*.
|
||||
|
||||
Stanford measured it.
|
||||
|
||||
Their researchers tracked 46 teams working with AI — matched against 46 similar teams without it — for more than two years.
|
||||
|
||||
The teams that really learned it pulled away from the ones that just... had it.
|
||||
|
||||
In spring 2023, the spread between them was under five percent.
|
||||
|
||||
By summer 2025 — nineteen.
|
||||
|
||||
The gap quadrupled in two years. And the curve is still bending upward.
|
||||
|
||||
And remember — everyone had the same models the whole time.
|
||||
|
||||
The difference was never the model.
|
||||
|
||||
It was who built something around it.
|
||||
|
||||
_note: source — Stanford SWEPR, difference-in-differences analysis, Apr 2023 → Jul 2025 (see wiki/sources/2026-07-30-stanford-swepr-widening-gap.md). Honest caveats if asked in Q&A: talk-published, not yet peer-reviewed; measures software teams, not office workers; Stanford says "quality of usage" decides, without naming which practice._
|
||||
|
||||
---
|
||||
|
||||
We started this journey by pasting an email into a chat box.
|
||||
|
||||
We're ending it with a button that already knows what the email said.
|
||||
@@ -0,0 +1,60 @@
|
||||
# Stanford SWEPR — AI and the widening productivity gap
|
||||
|
||||
_Research dossier compiled 2026-07-30. Trigger: a saved screenshot (`raw/assets/G6g3O60bkAE05ZW.png`, X/Twitter image filename) of a Stanford slide titled "Teams that master AI are accelerating their productivity gains, widening the gap with laggards." This document assembles what the underlying research says, from the slide itself plus public coverage. It is NOT a first-hand transcript of a talk; per-claim provenance is marked below._
|
||||
|
||||
## Who / what
|
||||
|
||||
- **Group:** Software Engineering Productivity Research (SWEPR), Stanford University — https://softwareengineeringproductivity.stanford.edu/
|
||||
- **Lead researcher (public face):** Yegor Denisov-Blanch — https://yegordb.com/
|
||||
- **Data:** private Git repositories from **600+ companies**, **~100,000–120,000 software engineers**, tens of millions of commits, collected since 2022. (Coverage varies between "100k" and "120k+"; the group's own site says 120,000+.)
|
||||
- **Method:** a machine-learning model trained to replicate a **panel of human expert reviewers** scoring every commit — measuring *functionality delivered* rather than commit counts or lines of code. Methodology is peer-reviewed: "Predicting Expert Evaluations in Software Code Reviews" (https://arxiv.org/pdf/2409.15152); a companion paper tests LLM determinism in code review (https://arxiv.org/pdf/2502.20747).
|
||||
|
||||
## The slide (primary evidence — read directly from the screenshot)
|
||||
|
||||
Slide 3 of a deck; footer "Stanford University / SWEPR / Software Engineering Productivity Research Group." Title: **"Teams that master AI are accelerating their productivity gains, widening the gap with laggards."**
|
||||
|
||||
Chart: *"Causal Impact of AI on Software Engineering Productivity: Difference-in-Differences Analysis."*
|
||||
|
||||
- Method steps on the slide: (1) identified **46 teams that used AI**; (2) matched with **46 similar non-AI teams**; (3) measured **net productivity gains from AI quarterly**.
|
||||
- Y-axis: net productivity gain (%), causal vs the matched control group; median line + 95% CI band (Q25–Q75).
|
||||
- X-axis: April 2023 → July 2025, with model-release markers annotated along the top (GPT-era releases).
|
||||
- **April 2023: 4.8% Q1–Q3 difference. July 2025: 19% Q1–Q3 difference. Labeled "Widening Gap: 4× increase."**
|
||||
- Fine print: "DID Covariate Balance < 0.25".
|
||||
- Early quarters (Apr 2023–Jan 2024) hover around **0% or slightly negative** — the gap only opens from mid-2024 onward and then accelerates.
|
||||
|
||||
The slide matches Denisov-Blanch's September 2025 AI Conference talk **"Will AI Replace Software Engineers?"** (deck PDF: https://aiconference.com/wp-content/uploads/2025/09/Yegor-Denisov-Blanch-Will-AI-Replace-Software-Engineers_-.pptx.pdf). A video version of the material: "Can you prove AI ROI in Software Eng? (Stanford 120k Devs Study)" — https://www.youtube.com/watch?v=JvosMkuNxF8
|
||||
|
||||
## Broader findings of the study (from public coverage of the talks)
|
||||
|
||||
Headline: **AI coding tools deliver ~15–20% net average productivity gain** — not the 10× of vendor marketing, and not zero. Gross delivered code volume rises 30–40%, but **rework** (fixing AI-introduced bugs) eats roughly half the gross gain.
|
||||
|
||||
Gains vary sharply by context (the "it depends" matrix):
|
||||
|
||||
| Context | Net gain |
|
||||
| --- | --- |
|
||||
| Greenfield, low complexity | 30–40% |
|
||||
| Greenfield, high complexity | 10–15% |
|
||||
| Brownfield (legacy), low complexity | 15–20% |
|
||||
| Brownfield (legacy), high complexity | **0–10%, can be negative** |
|
||||
|
||||
- **Language popularity matters:** popular languages (Python, Java, JS/TS) ~20% on simple tasks, 10–15% on complex; niche languages (COBOL, Haskell, Elixir) minimal or negative — thin AI training data.
|
||||
- **Codebase size matters:** gains fall sharply as codebases grow from ~10k to ~10M lines — attributed to **context-window limits, signal-to-noise degradation, and domain-specific logic**.
|
||||
- Coverage of the same research reports a **91% increase in PR review time** and a **~2.6× increase in rework** in AI-heavy workflows, i.e. the cost moved downstream from writing to reviewing. _(Secondary coverage; not read off a primary slide.)_
|
||||
- Interpretation offered by the researchers in talks/coverage: quality of AI usage beats volume of AI usage; teams with clean, modular, well-tested codebases compound gains, while teams with poor code hygiene accumulate technical debt and lose trust in the tools — one proposed mechanism for the widening gap.
|
||||
- Related earlier finding from the same group (separate result, widely covered ~Nov 2024): **"ghost engineers"** — ~9.5% of engineers in the dataset perform virtually no verifiable work. _(Contextual; distinct from the AI-impact analysis.)_
|
||||
|
||||
## Status / caveats
|
||||
|
||||
- The 46-vs-46 difference-in-differences result is, as of this writing, **talk/deck-published only** — presented at conferences and webinars, not (yet) in a peer-reviewed paper. The peer-reviewed papers cover the measurement methodology.
|
||||
- All numbers outside the slide itself come from secondary coverage of the talks and may compress or paraphrase.
|
||||
- The study's data is proprietary (companies opt in), so independent replication is not possible from outside.
|
||||
|
||||
## Links (all, in one place)
|
||||
|
||||
- Group site: https://softwareengineeringproductivity.stanford.edu/
|
||||
- Sept 2025 AI Conference deck: https://aiconference.com/wp-content/uploads/2025/09/Yegor-Denisov-Blanch-Will-AI-Replace-Software-Engineers_-.pptx.pdf
|
||||
- Talk video: https://www.youtube.com/watch?v=JvosMkuNxF8
|
||||
- Researcher: https://yegordb.com/
|
||||
- Methodology paper: https://arxiv.org/pdf/2409.15152
|
||||
- Determinism paper: https://arxiv.org/pdf/2502.20747
|
||||
- Screenshot that triggered this dossier: `raw/assets/G6g3O60bkAE05ZW.png`
|
||||
107
raw/sources/А что если наВайб-Кодить.md
Normal file
107
raw/sources/А что если наВайб-Кодить.md
Normal file
@@ -0,0 +1,107 @@
|
||||
# Выводы по видео
|
||||
|
||||
**Источник:** https://www.youtube.com/watch?v=zBcWcignqng
|
||||
**Название:** А что если наВайб-Кодить?
|
||||
**Длительность:** 5:31
|
||||
|
||||
---
|
||||
|
||||
## Главный тезис
|
||||
|
||||
**Нейросети открыли ящик Пандоры: теперь любой сервис можно быстро переписать «под себя» — и в этом главная ловушка.** Проблема современного софта никогда не заключалась в написании кода. Проблема — в его поддержке. Разработчики не писали свои аналоги Jira, Datadog и т.д. не потому что *не могли*, а потому что *не хотели*. И зря забывают об этом сейчас, вдохновившись возможностями ИИ.
|
||||
|
||||
---
|
||||
|
||||
## Иллюстрация: маятник «сделали своё → вернулись к покупному»
|
||||
|
||||
Автор приводит два твита с разницей в несколько месяцев:
|
||||
|
||||
| Дата | Что произошло |
|
||||
|---|---|
|
||||
| Март 2026 | Компания сделала свой аналог Jira со всем нужным функционалом и переехала на него |
|
||||
| Июль 2026 | Та же (или похожая) компания вернулась к покупке трекера (Linear), потому что не захотели тащить свой продукт |
|
||||
|
||||
Это типичный сценарий эпохи вайб-кодинга: собрать за пару недель — легко, тащить дальше — невозможно.
|
||||
|
||||
---
|
||||
|
||||
## Почему раньше не переписывали всё сами
|
||||
|
||||
Общее заблуждение: «раньше не могли, а теперь с ИИ смогли». **Это неправда.**
|
||||
|
||||
- Разработчики всегда могли написать любой сервис — руками, командой, за несколько месяцев.
|
||||
- Не писали по одной причине: **не хотели управлять этим сервисом дальше**.
|
||||
- Сам код — не проблема. Проблема начинается после первого пользователя.
|
||||
|
||||
---
|
||||
|
||||
## Что ломается, как только у продукта появляются пользователи
|
||||
|
||||
Как только сервис живёт и масштабируется, на разработчиков сваливается:
|
||||
|
||||
- баги и регрессии;
|
||||
- запросы на новые фичи;
|
||||
- «что-то не так работает / не там работает / не сработало»;
|
||||
- логи, мониторинг, дежурства;
|
||||
- ответственность за аптайм.
|
||||
|
||||
Проект, который делался «чтобы сэкономить на подписке», превращается в **отдельную постоянную работу** с выделенными людьми и временем — ровно то, что делала компания-вендор, которой вы платили.
|
||||
|
||||
---
|
||||
|
||||
## Ключевой парадокс: два бизнеса вместо одного
|
||||
|
||||
Если основной бизнес компании — например, «условный ChatGPT», а в фоне она тащит свой self-hosted трекер / логгер / что-то ещё, то она:
|
||||
|
||||
- либо **переходит из одного бизнеса во второй**,
|
||||
- либо **совмещает два IT-бизнеса в одном**.
|
||||
|
||||
Плохо для всех:
|
||||
|
||||
| Кому плохо | Почему |
|
||||
|---|---|
|
||||
| Компании | Платит за один продукт, а команда пилит второй |
|
||||
| Разработчику | Есть основная работа (ругают, если не сделал) + второстепенная (ругают, если не сделал) |
|
||||
|
||||
---
|
||||
|
||||
## Личный кейс автора
|
||||
|
||||
- В его компании используют **Datadog**.
|
||||
- Платят «буквально миллионы в год» за работу с логами и их хранение.
|
||||
- Хотят заменить и уже разрабатывают свой аналог + присматриваются к более дешёвым альтернативам.
|
||||
- Признаёт: в предыдущем ролике сказал, что «многие сервисы умрут из-за ИИ» — и **был неправ**.
|
||||
|
||||
---
|
||||
|
||||
## Сквозные принципы
|
||||
|
||||
1. **Написание кода — не бутылочное горлышко.** Никогда не было.
|
||||
2. **Стоимость софта = стоимость поддержки**, а не разработки.
|
||||
3. **«Могу написать за неделю» ≠ «стоит писать».** Между этими двумя утверждениями — годы саппорта.
|
||||
4. **Внутренний сервис — это внутренний бизнес.** Со своими SLA, дежурствами, багфиксами, roadmap.
|
||||
5. Вендор берёт деньги не за код, а за то, что снимает с вас операционную нагрузку.
|
||||
|
||||
---
|
||||
|
||||
## Что делать: практический вывод автора
|
||||
|
||||
> «Не пытайтесь переписать всё.»
|
||||
|
||||
Оценивать замену сторонних решений стоит по чек-листу:
|
||||
|
||||
- **Размер зависимости.** Небольшие библиотеки без развития — можно переписать.
|
||||
- **Требует ли дальнейшей поддержки?** Если да — считайте это отдельным проектом.
|
||||
- **Какую операционную нагрузку добавит?** Мониторинг, багфикс, дежурства, дев-время.
|
||||
- **Готов ли бизнес открывать второй IT-бизнес внутри себя?**
|
||||
|
||||
Если ответы «да / много / нет» — оставайтесь на платном сервисе, даже имея под рукой Claude / Antigravity / Codex.
|
||||
|
||||
---
|
||||
|
||||
## Кому это полезно
|
||||
|
||||
- **Тимлидам и техлидам,** которые под впечатлением от вайб-кодинга собираются «за спринт заменить Jira / Datadog / Sentry».
|
||||
- **Основателям стартапов,** решающим build vs buy для инфраструктурных инструментов.
|
||||
- **Fullstack-разработчикам,** прикидывающим себестоимость «своего маленького SaaS-клона».
|
||||
- **Инженерам,** оценивающим ROI миграции с внешнего сервиса на in-house решение.
|
||||
198
raw/sources/Грабли во внедрении ИИ в SDLC.md
Normal file
198
raw/sources/Грабли во внедрении ИИ в SDLC.md
Normal file
@@ -0,0 +1,198 @@
|
||||
# Выводы по видео
|
||||
|
||||
**Источник:** https://www.youtube.com/watch?v=Nm3MsnngCJg
|
||||
**Название:** Грабли во внедрении ИИ в SDLC — почему ИИ есть, а результата нет и как это лечить (Николай Шейко)
|
||||
**Длительность:** 45:59
|
||||
|
||||
---
|
||||
|
||||
## Главный тезис
|
||||
|
||||
**ИИ в разработке уже даёт реальный прирост, но люди, компании и метрики тормозят его на порядок.** С декабря 2025 (Opus 4.5 / GPT-5.2 + Claude Code / Codex) начался настоящий скачок — SDLC схлопнулся в дни/часы. Но результат появляется только у тех, кто (а) перестал быть просто разработчиком и стал менеджером агента, (б) построил feedback loop, (в) меряет **выполненные задачи без rework**, а не строки кода / PR-ы, и (г) занимается **эволюцией системы** (skill-и, промпты, инструменты), а не одноразовыми настройками.
|
||||
|
||||
Ключевая цитата: *«Компаниям больше не нужна кастомная AI-разработка. Им нужно прийти, поставить Claude Code или Codex, всё настроить, прицепить коннекторы, подумать про безопасность — и это работает лучше любой кастомной».*
|
||||
|
||||
---
|
||||
|
||||
## 1. Прошлое: что уже произошло
|
||||
|
||||
| Событие | Что важно |
|
||||
|---|---|
|
||||
| Статья METR (июль 25) | Ожидали ускорение, а замер показал замедление. Но у исследования много методологических проблем |
|
||||
| Стэнфордское исследование (август 25) | +20% скорости, но **разрыв между топ-перформерами и середняками растёт** — догнать всё сложнее |
|
||||
| Твит Карпаты (ноябрь-декабрь 25) | Автор термина «vibe-coding» сам говорит: раньше было баловство, теперь 80% делает Claude Code, 20% дорабатываю руками |
|
||||
| Статья «SDLC is dead» | Стадии жизненного цикла схлопнулись из недель в дни/часы |
|
||||
|
||||
**Но SDLC схлопнулся не полностью.** Осталось два «красных квадратика» — люди:
|
||||
- **Ревьюер** — узкое место. Задачи копятся в очереди на ревью.
|
||||
- **Планировщик / продукт** — тоже человек.
|
||||
|
||||
Распределение времени разработчика сдвинулось с «кодинга посередине» к «планированию слева + проверке справа».
|
||||
|
||||
---
|
||||
|
||||
## 2. Универсальная ошибка №0: разработчик ≠ менеджер
|
||||
|
||||
- Хороший разработчик = 3-5 часов сфокусированной работы над одной фичей (CPU-bound).
|
||||
- Хороший AI-разработчик = **менеджер сотрудника-агента** (IO-bound), запускающий несколько задач параллельно.
|
||||
- Если ты запустил Claude Code и **сидишь смотришь**, как он работает — ты плохой сотрудник.
|
||||
- Не все психологически способны переключиться. **И это нормально** — не заставляйте всех.
|
||||
|
||||
---
|
||||
|
||||
## 3. Кейсы и ошибки
|
||||
|
||||
### Кейс 1: Перенос фронтенда на новый стек
|
||||
|
||||
| Ошибка | Лечение |
|
||||
|---|---|
|
||||
| Нет feedback loop у агента | Дать доступ к браузеру (Playwright / Agent Browser / Chrome DevTools) — пусть сравнивает старый vs новый фронт |
|
||||
| Кранч → баги, плохая архитектура, порочный круг фиксов | Много времени на **планирование**. 20 минут — минимум, часы — норма. Каждые 10 минут планирования экономят часы. Цель — реализация за один шаг |
|
||||
| Устаревшие инструменты (Cursor + оплата за токены → команда экономит) | Claude Code / Codex по подпискам |
|
||||
| Внешний эксперт настраивает — «магический артефакт» | Люди должны настраивать инструменты сами. Опросник, чтобы вытащить неявные знания в инструкцию агента |
|
||||
| Всех под одну гребёнку тащить в AI | Разное сопротивление — нормально. Консерваторы охраняют компанию от вайб-кодеров |
|
||||
| Взяли архитектурный проект для обучения | Архитектурные ошибки стоят дорого и живут годами. Лучше начинать не с архитектуры |
|
||||
|
||||
**Решение по обучению команды:** записать видео → скрипт для выгрузки всех сессий → эксперт отсматривает → **пишет фидбэк команде, а команда сама правит инструкции агента** → фокус на 2 топ-перформерах (час с ними даёт 10× больше пользы, чем с остальными).
|
||||
|
||||
### Кейс 2: Европейский аутсорс — PR-ов больше, а прирост +1%
|
||||
|
||||
Причина — **rework**. Быстро задеплоили, потом много доработок.
|
||||
|
||||
**Ошибки метрик** (мем всех компаний):
|
||||
|
||||
| Не мерить | Мерить |
|
||||
|---|---|
|
||||
| Строки кода | Количество **выполненных** задач в единицу времени |
|
||||
| Количество коммитов | (задача выполнена только если **не вернулась** на доработку) |
|
||||
| Число PR-ов | Время жизни задачи + время на доработки |
|
||||
|
||||
**Ревью — новое узкое место.** Ручное ревью → скапливаются задачи → выгорание → снижение качества. **Решение — ревью вместе с агентом** (не вместо, а вместе). Модель = умный студент: направляйте, задавайте гипотезы, находите проблемы.
|
||||
|
||||
### Кейс 3: Большая кодовая база + «проклятие compaction»
|
||||
|
||||
- Агент собирает контекст → окно переполняется → compaction → снова добирает → снова compaction → задача еле выполняется.
|
||||
- Компания решила: «раз агенты, best practices не нужны». **Ошибка.**
|
||||
- Best practices нужны именно для агента: локальность, изолированные модули с интерфейсами, кодовая база хранит контекст.
|
||||
- **AST Search** вместо grep на колоссальных проектах — grep выдаёт «портянку» мусора, AST даёт релевантное. Работает на разных языках.
|
||||
|
||||
### Мини-кейсы
|
||||
|
||||
- **Middle**, который внедрил AI и ускорил команду на десятки %, попросил повышение зарплаты, не получил — ушёл на сильно больше. *Если вы такой middle — задумайтесь. Если руководитель — вдвойне.*
|
||||
- **Стартап, который делает spec-driven development, не зная, что хочет.** Планирование бесполезно, если нет цели. Сначала соберите UI (даже с in-memory базой в браузере) → покликайте → поймите, что нужно → потом планируйте.
|
||||
|
||||
---
|
||||
|
||||
## 4. Что будет дальше (будущее ролей)
|
||||
|
||||
### Появление **Product-инженера**
|
||||
|
||||
Планирование съедает больше времени → нужен человек, который отвечает не «как технически сделать», а «**почему** технически делаем так, чем можем пренебречь, что упростить, на что забить».
|
||||
|
||||
### Intelligence vs Judgment
|
||||
|
||||
- **Intelligence** (последовательности действий, требующие интеллекта) — AI уже отжирает.
|
||||
- **Judgment** (вкус, различие полутонов, доменная экспертиза) — пока за людьми.
|
||||
- Мы детектим slop в интернете, потому что там нет human touch.
|
||||
- Judgment = либо **вкус, наработанный годами** (хороший код), либо **доменная экспертиза** (нефтянка, медицина).
|
||||
|
||||
### Разделение ролей: пользователь vs настройщик системы
|
||||
|
||||
Сейчас те, кто пишет код с AI, и те, кто настраивает harness — обычно одни люди. Постепенно **разделяется**:
|
||||
- **Пользователи** — планирование + верификация конкретной фичи.
|
||||
- **Agentic Operations** — настраивают SDLC, feedback loop-ы, инструменты, промпты, скиллы.
|
||||
|
||||
### Тренды на токены
|
||||
|
||||
- Пока **дорожают** — в ближайшее время. Позже, вероятно, начнут дешеветь.
|
||||
- Сейчас — **дикий запад**. Задача — оказаться в верхней половине графика Стэнфорда.
|
||||
- **Экспериментируйте на полную котлету**, пока подписки дешёвые.
|
||||
|
||||
---
|
||||
|
||||
## 5. Agentic Evolution — ключевой концепт
|
||||
|
||||
Как правильно обучать агента:
|
||||
|
||||
| Плохо | Хорошо |
|
||||
|---|---|
|
||||
| Спросить эксперта «как ты это делаешь» → он расскажет теорию | Взять нового сотрудника (агента) за ручку → провести по сложным задачам → показать грабли → потом сказать: *«Запомни всё это и напиши методичку следующему»* |
|
||||
|
||||
Без этого мы пользуемся тем, что нам дали по умолчанию. С этим — начинается вертикальный рост.
|
||||
|
||||
**Как верифицировать скилл:**
|
||||
|
||||
1. Написал скилл вместе с агентом.
|
||||
2. **Не иди обедать.**
|
||||
3. Запусти сабагента **без контекста** → пусть решит ту же задачу с нуля, используя только скилл.
|
||||
4. Основной агент смотрит, что не так → правит скилл.
|
||||
5. Так агент-ментор онбордит следующего агента.
|
||||
|
||||
---
|
||||
|
||||
## 6. Матрица «что делать / чего не делать»
|
||||
|
||||
### Ошибки разработчика
|
||||
|
||||
- Ревью полностью вручную ❌
|
||||
- Отдать ревью целиком агенту ❌
|
||||
- Слишком мало времени на планирование ❌
|
||||
- Слишком много планирования при неясной цели ❌
|
||||
- Обмазываться сабагентами / мультиагентными системами сразу ❌ (сложные системы вырастают из простых)
|
||||
- Забить на эволюцию (жить с дефолтами) ❌
|
||||
|
||||
### Ошибки компании
|
||||
|
||||
- Нанять внешнего настройщика (даст рыбу, но не удочку) → **нужен препод/куратор**
|
||||
- Устаревшие инструменты (Cursor с оплатой за токены)
|
||||
- Всех сотрудников под одну гребёнку в AI
|
||||
- Не повышать зарплату — потеряете тех, кто разобрался
|
||||
- Надеяться на быстрый результат — это долгий навык
|
||||
- Нанимать по-старому
|
||||
- Метрики, которые легко хакаются (LoC, PR count)
|
||||
|
||||
---
|
||||
|
||||
## 7. Что можно сделать **завтра**
|
||||
|
||||
1. **Замкните feedback loop**, если ещё нет.
|
||||
2. **Напишите скилл, который анализирует ваши сессии** хотя бы за день.
|
||||
3. **Автоматизируйте**: schedule в Codex или routines в Anthropic.
|
||||
4. **Голосовой ввод** (сильно больше контекста), причём **на русском** — тоже больше контекста, чем на английском.
|
||||
5. **Не гоняйтесь за каждым новым инструментом** — что не всасывается в Claude Code / Codex за пару месяцев, скорее всего бесполезно.
|
||||
|
||||
---
|
||||
|
||||
## 8. Долгосрочный план
|
||||
|
||||
- Стать «правым» на слайде — тем, кто настраивает систему, а не пользуется.
|
||||
- Вкатываться, **пока подписки дешёвые**.
|
||||
- Отлаживать систему до one-shot execution (реализация за один проход, не итерации).
|
||||
- Автоматический анализ сессий на **уровне команды** — искать общие паттерны, не только личные.
|
||||
|
||||
---
|
||||
|
||||
## 9. Из Q&A: заметки на полях
|
||||
|
||||
- **Embeddings в AI-инжиниринге / RAG поверх эмбеддингов кода** — **не работает.** Не используйте, если не понимаете *очень* хорошо, зачем.
|
||||
- **Cursor не тот инструмент**, потому что: (а) отставал от Claude Code, (б) тащит старые фичи (embedding-индекс), (в) поддержка совместимости с VS Code съедает ресурсы, (г) оплата за токены → команда экономит вместо экспериментов. ~30% дороже подписок при том же уровне.
|
||||
- **Дефицит железа**: H100/H600 не арендовать. Claude банит через раз, требует верификацию email. Прогноз докладчика: **AI назовут кибероружием**, введут лицензии как на биотех/фарму.
|
||||
- **Китайские модели — важный тренд:**
|
||||
- **GLM** (ZAI) — «красавчики», хорошая модель, есть свой GUI-клон Codex, подключается любая модель. Минус — не vision.
|
||||
- **Kimi** — рабочая, есть vision (для frontend feedback loop).
|
||||
- **Xiaomi агент** — интересная реализация памяти (стоит посмотреть). Head of AI перешёл туда из DeepSeek.
|
||||
- **Как заставить агента справиться за один шаг:**
|
||||
1. Feedback loop — must have.
|
||||
2. Новая фича **goal** — чётко формулируйте реальную цель; агент сам проверяет, достигнута ли.
|
||||
3. Скилл-верификация через субагента без контекста.
|
||||
|
||||
---
|
||||
|
||||
## 10. Кому это полезно
|
||||
|
||||
- **Тимлидам и техлидам**, которые внедряют AI и меряют строками кода (перестаньте).
|
||||
- **Разработчикам,** которые сидят и смотрят, как Claude работает — пора становиться менеджером.
|
||||
- **CTO** — не нанимайте внешнего настройщика, наймите куратора; повышайте зарплату тем, кто разобрался, иначе уйдут.
|
||||
- **Стартаперам** — не делайте spec-driven, пока не знаете, что хотите.
|
||||
- **AI-инженерам** — не суйте embeddings в код, стройте skill evolution через субагента без контекста.
|
||||
- **Всем** — замкните feedback loop и включите голосовой ввод на русском **завтра**.
|
||||
@@ -2,6 +2,12 @@
|
||||
|
||||
#comparison
|
||||
|
||||
> **Staleness note (added 2026-07-28 by [[2026-07-28-lint]]).** Written 2026-07-16 from one source per speaker. Two developments since, neither reflected below:
|
||||
> - **[[theo-browne]] has a second source** ([[2026-07-24-youre-reading-way-too-much-code]]). The "On code" row and the "deskilling vs re-skilling" tension both read his position as bare disposability; he has since supplied its *discipline* ([[make-more-cheap-code]] — keep hand-verification of what ships, generate 100×+ more that never ships) and explicitly disowned shipping unreviewed slop.
|
||||
> - **The closing claim "None of the three directly contradicts another; the disagreements in this corpus are elsewhere" is now materially incomplete.** [[thorsten-ball]] contradicts the skills thread this page calls "the vault's strongest cross-source thread" — he uses no skills, no MCP, no slash commands. He is outside this page's three-way scope, but a reader taking the closing line at face value would conclude the skills convergence is uncontested. It is not; see [[skills-as-memory]].
|
||||
>
|
||||
> Content below is preserved as the 2026-07-16 state. Recommended refresh: extend to four lenses, or add Thorsten as an explicit dissent column.
|
||||
|
||||
## 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:
|
||||
|
||||
41
wiki/concepts/async-by-default.md
Normal file
41
wiki/concepts/async-by-default.md
Normal file
@@ -0,0 +1,41 @@
|
||||
# Async by Default (Orbs and Proof)
|
||||
|
||||
#concept
|
||||
|
||||
## Summary
|
||||
|
||||
If agent work takes sixteen minutes and you are doing something else, latency stops being a cost. [[thorsten-ball]]'s working mode: delegate into a **remote sandbox**, walk away, run several in parallel, and — since you are waiting anyway — **ask the agent for proof** rather than a claim of success.
|
||||
|
||||
## Current Understanding
|
||||
|
||||
**The orb.** [[amp]]'s unit of work is a remote sandbox tied to one conversation. It sleeps when idle and wakes on typing; it streams to phone, laptop and TUI as the same conversation; and **one URL packages the thread + the agent + the computation + the diff**. Share the URL and a teammate opens the orb and takes over. Agent-to-agent messaging turns this multiplayer: "I found another bug" → "launch another orb to fix it" → new checkout, new branch, new agent, in parallel.
|
||||
|
||||
**The old objections collapsed.** Cloud IDEs (Cloud9 and friends) died on latency, key bindings, "I can't SSH in," and missing language servers. Thorsten's rebuttal: *who cares about latency when you're waiting for tokens per second anyway?* — and nobody uses editors, key bindings or language servers the way they did when those objections were formed. The objection stack was about a workflow that no longer exists.
|
||||
|
||||
**Ask for proof.** Quinn (AMP's CEO): *"You're async anyway — so ask the agent to give you proof."* Screenshots, benchmarks, dark-mode *and* light-mode variants, fifty tests in parallel. This is the delegation-side counterpart to [[make-more-cheap-code]]: cheap generated artifacts exist to make a claim checkable, and asking for three of them costs you nothing when you are not sitting there watching. In practice at AMP: screenshot a bug → send it → an orb returns a fix → spot check → merge; the designer "never fixed so many paper cuts."
|
||||
|
||||
**The prediction.** Local dev effort goes away, replaced by remote sandboxes — with the caveat that 15+ sandbox providers are already racing margins to zero, which Thorsten himself calls unsustainable.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Orbs, sleep/wake, one-URL packaging, multiplayer handoff, the 16-minute live demo, the collapsed cloud-IDE objections, Quinn's proof line, paper-cut velocity, local-dev prediction, infra-margin prediction — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- Fire-and-forget as a native harness mode; completion notifications as what makes background agents usable — [[2026-07-14-skills-based-on-git]], [[harness]].
|
||||
- The same mode as a job description: the AI-developer is IO-bound, runs tasks in parallel, and "if you launched Claude Code and sit watching it work — you're a bad employee" — [[2026-07-30-rakes-in-ai-sdlc-adoption]] (the role-shift side lives at [[developer-as-agent-manager]]).
|
||||
- Scheduled agents producing while you sleep (the non-engineer version) — [[personal-ai-operating-system]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[harness]] (async is one of its two modes), [[agentic-loops]], [[make-more-cheap-code]] (proof artifacts are throwaway code with a job), [[shedding-weight]] (async is what makes killing the backlog possible — parked agents replace queued tickets), [[personal-ai-operating-system]], [[context-as-scarce-resource]], [[developer-as-agent-manager]] (the human role this mode implies), [[review-is-the-new-bottleneck]] (where the parallel diffs pile up)
|
||||
- Entities: [[thorsten-ball]], [[amp]], [[claude-code]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- **Attention, not latency, is the real budget.** Five parallel orbs produce five diffs that a human must still review; [[make-more-cheap-code]] argues reading is the scarce resource. Async multiplies generation without multiplying review capacity, and the source does not address the pile-up. Status: tentative — this is the same open question logged on [[make-more-cheap-code]] about reviewing *agent behaviour* becoming the new attention sink.
|
||||
- **Proof is produced by the thing being checked.** A screenshot from the agent that made the change is evidence, not verification; the failure mode where an agent produces a convincing artifact of work it did not do is unaddressed.
|
||||
- **Remote sandboxes vs compliance.** Code and conversation in a vendor's cloud is exactly what [[enterprise-ai-reality|locked-down enterprises]] forbid. Also sits against [[eugene]]'s consolidated *local* workspace pitch ([[harness]]) — though the two are compatible if the consolidation point is the interface rather than the compute.
|
||||
- "Local dev is going away" comes from a company selling remote sandboxes. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- What is the non-engineer's orb? The corpus has scheduled workflows (Allie) and completion notifications (Eugene) but nothing that packages a resumable, shareable unit of work for a non-technical user.
|
||||
- Which proofs actually catch drift? If [[leave-less-room-for-imagination|the damage is what you don't notice]], a screenshot proves the happy path and nothing else — the proof list needs a design, not just a habit.
|
||||
37
wiki/concepts/build-for-the-agent-not-the-human.md
Normal file
37
wiki/concepts/build-for-the-agent-not-the-human.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Build for the Agent, Not the Human
|
||||
|
||||
#concept
|
||||
|
||||
## Summary
|
||||
|
||||
A product philosophy from [[thorsten-ball]]: if you start something on the frontier today, **no human should have to fill out a form.** Anything a human can do on your site, they should be able to have an agent do — and ideally they should **bring their own agent**, because "nobody wants to use your shitty built-in agent."
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- **The admin panel that dies.** Building a food-ordering app from a photo of a menu, the agent also produced an admin UI for editing prices and spellings. Thorsten's reaction: *"I'm never going to open that. I'll just send another photo and say 'fix the pricing.'"* The insight underneath it is general: **a lot of admin UI existed only so that no code had to change.** Once changing code is cheap, the UI layer built to avoid changing code is pure [[shedding-weight|weight]].
|
||||
- **The same for content dashboards.** WordPress-style admin: "here's my draft, add this header image, publish, spell-check" — one sentence instead of a session of clicking.
|
||||
- **Bring your own agent** is the sharp part, and it cuts against most 2026 product roadmaps: the differentiator stops being *your* assistant and becomes whether your surface is drivable by *the user's* assistant. That makes agent-accessibility a product feature rather than an integration checkbox.
|
||||
- **Consequence for moats.** If every surface is agent-drivable and every agent can remix software ([[emacsification-of-software]]), general-purpose SaaS loses the lock-in that UI familiarity used to provide. Thorsten's own prediction list says it plainly: it is unclear what software survives.
|
||||
|
||||
**Read carefully, this is not "no UI."** The claim is that UI built as a *substitute for changing the system* dies, and UI built as a genuinely better interface survives. The distinction matters for the webinar's [[personal-ai-operating-system|OS framing]], where the endpoint is a *smaller* interface (a button that already knows what the email said) rather than no interface — arrived at from the opposite direction: Thorsten deletes UI so he can prompt, the OS framing builds tiny UI so you need not prompt. Both are the same underlying claim that the generic chat box and the generic admin panel are the two things being squeezed out.
|
||||
|
||||
## Evidence
|
||||
|
||||
- "No human should have to fill out forms," bring-your-own-agent, the food-app admin panel, the WordPress example — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- Erosion of software moats via remixability (prediction 3 in the same source).
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[shedding-weight]] (the parent move), [[emacsification-of-software]], [[explosion-of-internal-software]], [[personal-ai-operating-system]] (the interface question from the user's side), [[async-by-default]]
|
||||
- Entities: [[thorsten-ball]], [[amp]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- **Who operates the software if forms die?** Thorsten's answer is "prompt the agent" — which assumes exactly the prompting competence the corpus's HR interviews identify as the real bottleneck ([[levels-of-ai-usage]], and Nina/Yulia's *friction, not resistance* finding). An admin panel is a poor interface for an expert and a good one for a beginner. Status: tentative.
|
||||
- "Bring your own agent" is asserted by someone who sells an agent; the business model that survives universal BYOA is not addressed.
|
||||
- No account of authorization: an agent-drivable surface is also an agent-*abusable* surface, and the source says nothing about permissions, rate limits, or attribution.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- What is the minimum an existing product must expose to be genuinely agent-drivable — an API, an `AGENTS.md`, structured error messages, or something else?
|
||||
- Does the webinar audience want fewer forms or *better* forms? Worth asking directly, since it decides whether the OS pitch lands as liberation or as loss of a familiar surface.
|
||||
@@ -16,6 +16,11 @@ When the cost of writing code trends to zero, code stops being a precious asset.
|
||||
|
||||
- **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.
|
||||
|
||||
- **The production datapoint.** [[thorsten-ball]] reports **99% of [[amp]]'s code is written by AI** — the corpus's only figure from inside a shipping company rather than an individual workflow, and the strongest available answer to "does this survive contact with a real product?" He polled his team offering 99%+, 90–99% and <90%; the one engineer who said he still wrote "a bunch" by hand landed at ~95% when pushed. Self-reported, and from a company that sells an agent — but specific.
|
||||
- **Slop is a human problem.** "Most of slop comes from humans not having good product. With AI they can just build trash products faster." Slop = lack of ideas, lack of playfulness, not knowing what you want to exist — *not* an AI defect. His counter-demonstration is taste at AI speed: 15 generated icon variants across styles and 18 palettes, one picked by hand. This converges with Theo's anti-slop stance from a different direction — Theo defends cheap code with *verification discipline*, Thorsten with *taste* — and both reject the vibe-coder reading of this page.
|
||||
|
||||
- **The lifetime boundary.** [[2026-07-29-what-if-we-vibe-code-it]] adds the third cost besides writing and verifying: **maintenance**. Throwaway code is safe *because it is never maintained* — the trap begins at the first user, which converts code into a service ([[maintenance-is-the-real-cost]]). "I can write it in a week ≠ it's worth writing" is Theo's ship/no-ship line restated over the artifact's lifetime rather than at review time.
|
||||
|
||||
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
|
||||
@@ -24,15 +29,18 @@ Caveat: legacy/hobby niches persist (COBOL in banks — no training data; coding
|
||||
- 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]].
|
||||
- 99% AI-written at AMP; the hand-coding poll; "slop comes from humans"; the 15-icon-variant workflow — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- Writing was never the bottleneck; cost of software = maintenance; "can write in a week ≠ worth writing" — [[2026-07-29-what-if-we-vibe-code-it]].
|
||||
|
||||
## 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]]
|
||||
- Concepts: [[make-more-cheap-code]], [[maintenance-is-the-real-cost]] (the lifetime boundary), [[product-ownership]], [[think-wider-not-bigger]], [[skills-as-memory]], [[decoupling-identity-from-profession]], [[leave-less-room-for-imagination]], [[emacsification-of-software]] (cheap code makes the bespoke fork rational), [[explosion-of-internal-software]], [[shedding-weight]]
|
||||
- Entities: [[theo-browne]], [[sebastian]], [[eugene]], [[thorsten-ball]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- "Most code isn't high-value" is a generalization; safety-critical/regulated code is a clear exception (see [[enterprise-ai-reality]]).
|
||||
- The 99% figure is self-reported by a founding engineer at the company selling the agent, and describes a codebase whose authors are all expert users of that agent. It bounds what is *possible*, not what is typical. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
|
||||
@@ -18,6 +18,12 @@ Context pressure explains several otherwise-separate design choices:
|
||||
|
||||
The human role has climbed prompt-engineer → **context-engineer** → harness-builder → loop-engineer, tracking exactly this concern.
|
||||
|
||||
**Information beats tuning** ([[2026-07-28-agentic-engineering-10x-developer]]). [[thorsten-ball]] states the strongest version: once you have a frontier model, **the dominant variable in output quality is the information you put in** — not which model, and not the effort level (medium vs high vs ultra). "If you're mad your model doesn't use camelCase, rethink your software engineering, not the model." He names the agent's only two information sources — **training data** (a senior engineer who's seen it all, but lossy and possibly stale) and **the context window** (your prompt, plus whatever the codebase and `AGENTS.md` supply) — and the operative asymmetry: a model cannot turn a thin prompt into a good one. Note what he does *not* conclude: the fix is a better-tended codebase and a longer prompt, not [[skills-as-memory|skills]] (contested there).
|
||||
|
||||
**Context now has a price — at fleet scale.** The same source names **token budget** as one of two variables separating winners from losers, alongside knowing how to use agents. Context has always been scarce per-request; this is the corpus's first claim that it is also scarce per-*wallet*. Scope, corrected 2026-07-28: the claim comes from **metered** usage (parallel remote sandboxes), and under a flat consumer subscription the corpus's own heavy users report no ceiling — so per-request scarcity remains the binding constraint for individuals, and per-wallet scarcity is a fleet and enterprise concern. See [[enterprise-ai-reality]] and [[explosion-of-internal-software]].
|
||||
|
||||
**The compaction curse — scarcity at codebase scale** ([[2026-07-30-rakes-in-ai-sdlc-adoption]]). On a huge codebase the agent gathers context → the window overflows → compaction → it re-gathers → compaction again, and the task barely completes. [[nikolai-sheiko]]'s cure inverts the "agents mean best practices don't matter" fallacy: **best practices exist for the agent now** — locality, isolated modules with interfaces, so that *the codebase stores the context*. This converges with [[thorsten-ball]]'s context-lives-in-the-codebase position from the opposite direction (Thorsten skips skills because his codebase carries context; Sheiko says make your codebase able to). Practical additions: **AST search instead of grep** on colossal projects (grep returns a wall of noise, AST returns the relevant slice), and a flat rejection of embeddings/RAG over code. The mechanism matches Stanford's measured gains-collapse toward 10M LOC (evidence below).
|
||||
|
||||
**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
|
||||
@@ -25,16 +31,20 @@ The human role has climbed prompt-engineer → **context-engineer** → harness-
|
||||
- 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]].
|
||||
- Information > model choice > effort level; the two information sources; token budget as a winner/loser variable — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- Reading costs attention — the human-side analog of the same scarcity — [[make-more-cheap-code]], [[2026-07-24-youre-reading-way-too-much-code]].
|
||||
- **First outside quantitative support:** Stanford SWEPR finds AI productivity gains collapse as codebases grow from ~10k to ~10M lines, attributing it to context-window limits and signal-to-noise degradation — the corpus's context-is-the-constraint claim, measured at scale — [[2026-07-30-stanford-swepr-widening-gap]].
|
||||
- Compaction curse; best-practices-for-the-agent (locality, interfaces, codebase-stores-context); AST search over grep; embeddings/RAG over code rejected — [[2026-07-30-rakes-in-ai-sdlc-adoption]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[harness]], [[skills-as-memory]], [[agentic-loops]], [[evolution-of-agent-tooling]], [[personal-ai-operating-system]]
|
||||
- Entities: [[konstantin]], [[allie-miller]]
|
||||
- Concepts: [[harness]], [[skills-as-memory]], [[agentic-loops]], [[evolution-of-agent-tooling]], [[personal-ai-operating-system]], [[make-more-cheap-code]], [[explosion-of-internal-software]], [[enterprise-ai-reality]]
|
||||
- Entities: [[konstantin]], [[allie-miller]], [[thorsten-ball]]
|
||||
|
||||
## 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.
|
||||
- [[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. *(2026-07-30: [[nikolai-sheiko]] adds a hard anti-RAG data point for the code domain specifically — "embeddings over code don't work" — which supports the audience-driven reading: the anti-RAG votes are both about code/procedures, the pro-RAG vote is about business data.)*
|
||||
|
||||
## Next Questions
|
||||
|
||||
|
||||
37
wiki/concepts/developer-as-agent-manager.md
Normal file
37
wiki/concepts/developer-as-agent-manager.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Developer as Agent Manager
|
||||
|
||||
#concept
|
||||
|
||||
## Summary
|
||||
|
||||
[[nikolai-sheiko]]'s "universal error #0": treating AI-assisted development as the same job at higher speed. A good developer is **CPU-bound** — 3–5 hours of deep focus on one feature. A good AI-developer is **IO-bound** — a *manager of an agent-employee*, running several tasks in parallel, spending their time on planning and verification instead of typing. His blunt test: "If you launched Claude Code and sit watching it work — you're a bad employee."
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- **The switch is psychological, not technical** — and not everyone can make it. Sheiko is explicit that this is *fine*: don't drag everyone into AI under one brush; conservatives "guard the company from the vibe-coders." Compare [[2026-07-14-nina-interview|Nina's finding]] that adoption blocks on friction, not resistance — this page is the case where genuine resistance exists and is legitimate.
|
||||
- **Where the time goes instead:** "planning on the left, verification on the right" — the coding middle collapsed. Hence 20-minutes-minimum planning, explicit goals the agent self-checks against, and the review discipline of [[review-is-the-new-bottleneck]].
|
||||
- **The role splits further.** Today the people who *use* agents and the people who *tune the harness* are the same; Sheiko predicts a split into **users** (plan + verify a feature) and **Agentic Operations** (own the SDLC configuration, feedback loops, prompts, skills). A **Product engineer** also emerges — answers *why* we build it this way, what to simplify, what to ignore.
|
||||
- **What stays human: Judgment over Intelligence.** AI absorbs *Intelligence* (action sequences requiring intellect); *Judgment* — taste built over years, or deep domain expertise (oil & gas, medicine) — remains human for now. We detect slop precisely because it lacks human touch. This is the corpus's [[seniority-and-the-junior-squeeze|judgment-as-risk-reduction]] claim restated as a capability boundary.
|
||||
- **Corpus convergence.** The same working mode appears as [[async-by-default|orbs and parallel delegation]] ([[thorsten-ball]]), Eugene's 7 parallel project-agents, Allie's ~100 agents, and Karpathy's "80% Claude Code, 20% by hand" (cited within the talk). Sheiko's contribution is naming the *identity* shift and its HR consequences: the middle dev who mastered this, asked for a raise, was refused, and left for far more.
|
||||
|
||||
## Evidence
|
||||
|
||||
- CPU-bound vs IO-bound framing; "sit watching = bad employee"; don't-force-everyone; users vs Agentic Operations; Product engineer; Intelligence vs Judgment; the raise-refusal mini-case — [[2026-07-30-rakes-in-ai-sdlc-adoption]].
|
||||
- The same mode practiced at the frontier (parallel remote sandboxes, delegation, proof-asking) — [[2026-07-28-agentic-engineering-10x-developer]] via [[async-by-default]].
|
||||
- Non-engineer versions of parallel delegation (~100 agents, scheduled workflows) — [[2026-07-14-gap-between-ai-users-irreversible]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[async-by-default]] (the infrastructure this role runs on), [[review-is-the-new-bottleneck]] (where the manager's verification time goes), [[product-ownership]] (the webinar's human-side twin: own outcomes, not tickets), [[seniority-and-the-junior-squeeze]] (Judgment as the durable half), [[levels-of-ai-usage]] (the non-engineer's version of the same climb), [[harness]]
|
||||
- Entities: [[nikolai-sheiko]], [[thorsten-ball]], [[eugene]], [[allie-miller]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- **"Don't force everyone" vs the widening gap.** Sheiko permits opting out; [[2026-07-14-gap-between-ai-users-irreversible|Allie]] calls the gap irreversible and [[2026-07-30-stanford-swepr-widening-gap|Stanford measured it quadrupling]]. If both are right, opting out is legitimate *and* costly, and the source doesn't reconcile the two. Status: tentative.
|
||||
- The users / Agentic-Operations split is a prediction, not an observation — today's evidence (Eugene, Thorsten) is of people doing both. Status: tentative.
|
||||
- Intelligence-vs-Judgment is a moving boundary asserted "for now"; the corpus has no criterion for where it stops moving.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- What does the manager's day actually look like — is there a source with a concrete parallel-task routine (queue depth, check-in cadence) rather than the mode's name?
|
||||
- Does the Agentic-Operations role match the webinar's promise that non-engineers can self-serve ([[levels-of-ai-usage]]), or does it re-centralize harness-tuning in specialists?
|
||||
38
wiki/concepts/emacsification-of-software.md
Normal file
38
wiki/concepts/emacsification-of-software.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# The Emacsification of Software
|
||||
|
||||
#concept
|
||||
|
||||
## Summary
|
||||
|
||||
Emacs users have always forked plugins, rewritten them for their own config, and never contributed back. [[thorsten-ball]] (citing a blog post of this name) argues **that behaviour is now becoming the default for all software**: when an agent can bend someone else's program to your exact needs in two minutes, the bespoke fork beats the upstream contribution.
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- **The worked example:** he forked a diff viewer called **hunk**, pointed [[amp]] at it, and said "add Gruvbox dark hard theme, add file-checkoff in the sidebar, compile, drop it in `~/bin`." Two minutes of agent time. **No reason to upstream** — the change is bespoke to him, and the cost of maintaining a personal fork has collapsed along with the cost of writing the patch.
|
||||
- **The blast radius expands.** Not just individuals with small tools: he expects teams and companies to remix mid-sized software. His examples: "I want Riverside but audio-only," or video-only.
|
||||
- **Why it matters commercially:** general-purpose SaaS has historically been defended by the gap between "close enough" and "exactly what I want." Agents close that gap for free, which is why his prediction list includes *it is unclear what software survives* — remixability plus per-user custom versions erode the moat.
|
||||
- **The OSS side effect:** contributions dry up where the incentive to upstream was mostly "so I don't have to maintain a fork." This compounds a claim already in the corpus — that open-source contribution graphs are worth almost nothing now, and giving away near-free code costs little ([[code-as-throwaway]], via [[sebastian]]).
|
||||
|
||||
**Relationship to the sibling concept.** [[explosion-of-internal-software]] is about building tools that never existed; this page is about *remixing tools that do*. Same shift — software becoming personal rather than general — from opposite starting points, and both feed the webinar's "little tools you make for yourself" thesis.
|
||||
|
||||
## Evidence
|
||||
|
||||
- The Emacsification framing, the hunk fork, the Riverside remix prediction, expanding blast radius — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- OSS growth as low-cost giveaway, contribution graphs devalued — [[2026-07-14-sebastian-eugene-interview]].
|
||||
- Cost-of-code → zero as the enabling condition — [[code-as-throwaway]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[explosion-of-internal-software]] (sibling mechanism), [[maintenance-is-the-real-cost]] (the bounding counterweight), [[code-as-throwaway]] (the enabling economics), [[build-for-the-agent-not-the-human]] (what happens to the products being remixed), [[shedding-weight]], [[make-more-cheap-code]] (a fork nobody else sees is tier-A/B code with a long life)
|
||||
- Entities: [[thorsten-ball]], [[amp]], [[sebastian]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- **Maintenance is assumed away.** A two-minute fork is cheap; a fork carried across three years of upstream security patches is not. The source does not address rebasing, CVEs in the parent project, or what happens when the agent that built the fork can no longer reconstruct it. *(Sourced 2026-07-29:* [[2026-07-29-what-if-we-vibe-code-it]] *makes exactly this objection — [[maintenance-is-the-real-cost]] — and its pendulum case (in-house Jira clone abandoned for Linear within four months) is the mid-size "Riverside but audio-only" prediction failing in the wild. The personal `~/bin` fork still passes that source's checklist; the team/company remix he predicts does not.)*
|
||||
- **Who maintains the upstream** if the people capable of patching it now all fork silently? The prediction is stated as an observation, with no answer for the commons problem it describes.
|
||||
- Untested against [[enterprise-ai-reality]]: a bespoke unaudited fork in `~/bin` is precisely what locked-down corporate environments forbid.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- Does a personal fork count as a durable artifact, or is it disposable in the [[code-as-throwaway]] sense — regenerated from a prompt against a fresh upstream each time you need it? The second reading is more consistent with the rest of the corpus and would dissolve the maintenance objection.
|
||||
- Is there a non-engineer version of this — remixing a tool you use rather than one you can compile?
|
||||
@@ -12,22 +12,30 @@ The indie/practitioner world and the regulated-enterprise world diverge sharply.
|
||||
- **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"]].
|
||||
- **A second divide: the token budget** (added 2026-07-28; **scope corrected 2026-07-28** — see below). [[thorsten-ball]] names two variables separating winners from losers — knowing how to use agents, and **having the token budget to do it**. It cuts both ways for this page: an enterprise can buy budget an individual cannot, while a locked-down enterprise may withhold it from the people who would use it best. Whoever controls the budget controls how far [[explosion-of-internal-software|internal software]] spreads. Thorsten names the variable and says nothing about who pays.
|
||||
- **Scoping correction.** This was first written here as "the divide is also a *spending* gap," which overstates it. Thorsten's pricing regime is **metered**: [[amp]] sells usage, and his working pattern is parallel remote sandboxes and parked orbs ([[async-by-default]]) — a fleet cost, not a seat cost. Under a **flat consumer subscription** the corpus's own evidence points the other way: [[eugene]] runs 7 project-agents in parallel on a $200 plan, [[allie-miller]] runs ~100 agents and 36 workflows, and neither reports hitting a cost ceiling — while [[2026-07-14-sebastian-eugene-interview]] frames levelling as "a 20-year veteran and a fresh grad **on the same subscription**." For individual and small-team use the budget is one subscription; the token-budget variable bites at fleet scale and under metered pricing, which is where Thorsten sits and where enterprises will land.
|
||||
- **The market claim, seconded — and sharpened into a quote** (added 2026-07-30). [[nikolai-sheiko]], from multi-company adoption work: *"Companies no longer need custom AI development. Come in, install Claude Code or Codex, configure everything, attach connectors, think about security — and it works better than any custom build."* This is Sebastian's company-managed-harness market stated as a service playbook. Two adoption anti-patterns attached: **the external configurator** who leaves a "magic artifact" nobody on the team owns (what a company should buy is a *teacher/curator*; the team must configure its own tools — the [[solve-first-then-skillify|evolution]] has to happen in their hands), and **metered pricing shaping behaviour** — a team on Cursor's per-token billing economizes instead of experimenting (~30% dearer than subscriptions at the same level), which is the metered-vs-subscription split from the scoping correction above observed as an organizational failure mode. His pricing prediction — tokens get dearer near-term, cheaper later; "experiment at full throttle while subscriptions are cheap" — matches [[eugene]]'s price-rise prediction already flagged in the token-budget question.
|
||||
- **The frontier's advice does not transfer.** [[shedding-weight]] — kill the backlog, kill CI that repeats the agent's tests, kill local dev in favour of remote sandboxes ([[async-by-default]]) — describes a startup that owns its own process. In a regulated shop the pipeline, the audit trail and the ticket history frequently *are* the deliverable to a regulator, and code sitting in a vendor's remote sandbox is precisely what Sebastian's clients forbid. The gap between what the frontier recommends and what compliance permits is the same gap this page calls the market.
|
||||
|
||||
## 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]].
|
||||
- Token budget as a winner/loser variable; the frontier playbook (kill backlog/CI/local dev, remote sandboxes) that compliance cannot follow — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- "No custom AI development needed" quote; external-configurator anti-pattern vs teacher/curator; Cursor per-token billing → team economizes; tokens-dearer-then-cheaper prediction — [[2026-07-30-rakes-in-ai-sdlc-adoption]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[harness]], [[seniority-and-the-junior-squeeze]], [[code-as-throwaway]]
|
||||
- Entities: [[sebastian]], [[virtido]], [[eugene]]
|
||||
- Tools: [[claude-code]]
|
||||
- Concepts: [[harness]], [[seniority-and-the-junior-squeeze]], [[code-as-throwaway]], [[shedding-weight]], [[async-by-default]], [[explosion-of-internal-software]], [[context-as-scarce-resource]]
|
||||
- Entities: [[sebastian]], [[virtido]], [[eugene]], [[thorsten-ball]], [[nikolai-sheiko]]
|
||||
- Tools: [[claude-code]], [[amp]]
|
||||
|
||||
## 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.
|
||||
- [[amp]]'s orb model (code, conversation and diff living in a vendor's remote sandbox) is a direct test case for this page and the source never addresses it. Whether the frontier's unit of work is adoptable at all under compliance is open. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- What is the minimal compliant feature set for a centrally-managed enterprise harness?
|
||||
- Who controls the token budget in a large organisation, and is it allocated by role, by team, or by request? The corpus has no evidence either way, and it decides who actually gets to use the tools.
|
||||
|
||||
@@ -16,21 +16,25 @@ Konstantin's three-generation map of how agents get capabilities: **Tools (2022
|
||||
|
||||
**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.
|
||||
|
||||
**A fourth position: skip the progression.** [[thorsten-ball]] uses none of the three generations as user-authored artifacts — no skills, no MCP servers, no slash commands — and locates capability instead in the *codebase* plus `AGENTS.md` plus a rich prompt ([[2026-07-28-agentic-engineering-10x-developer]]). [[amp]] does ship structure (Oracle/Painter/Puck sub-agents, a model/effort dial), but the vendor curates it, not the user. Read against this table, his claim is that the progression's real axis was never tools → MCP → skills but **who supplies the context and where it lives** — and that for someone working in one well-tended repo, the repo wins. See the three competing readings logged on [[skills-as-memory]].
|
||||
|
||||
## 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]].
|
||||
- The skip-it-all position; vendor-curated sub-agents in place of user-authored skills — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[skills-as-memory]], [[harness]], [[context-as-scarce-resource]]
|
||||
- Tools: [[claude-code]], [[hermes]]
|
||||
- Entity: [[konstantin]]
|
||||
- Tools: [[claude-code]], [[hermes]], [[amp]]
|
||||
- Entity: [[konstantin]], [[thorsten-ball]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- "Everything changes every 6 months" — MCP was just ratified and A2A is already wanted; this map may shift quickly. Status: tentative.
|
||||
- The map assumes each generation *supersedes* the last. Thorsten's practice suggests a parallel track that never enters the table at all (repo + `AGENTS.md`), which would make the progression a history of *one* branch rather than of agent capability as such. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- Where does agent-to-agent (A2A) sit in this progression?
|
||||
- Where does agent-to-agent (A2A) sit in this progression? *(Partial datapoint 2026-07-28: [[amp]] shipped agent-to-agent messaging and a meta-agent that spawns and controls other agents — see [[async-by-default]]. It arrived as a harness feature, not as a fourth generation of capability-delivery, which the table would not have predicted.)*
|
||||
|
||||
38
wiki/concepts/explosion-of-internal-software.md
Normal file
38
wiki/concepts/explosion-of-internal-software.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# Explosion of Internal Software
|
||||
|
||||
#concept
|
||||
|
||||
## Summary
|
||||
|
||||
The layer of organisational life that used to be **one Excel file, one wiki page, and one hacky script** is about to be replaced by actual software, because building it now costs an evening instead of a quarter. [[thorsten-ball]] encoded his 20-person club's ordering process in **~2 hours of typing on his phone**. This is the corpus's strongest external validation of the webinar's thesis — *little tools you make for yourself*.
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- **The before/after.** Before, internal software was whatever survived the cost-benefit test against a spreadsheet — which almost nothing did. Now the test is trivially passed, so the Excel/wiki/hack layer gets replaced by real, purpose-built tools.
|
||||
- **Two variables separate winners from losers**, per Thorsten: (1) knowing how to use agents, and (2) **having the token budget to do it.** Scope matters on the second, and was corrected here 2026-07-28: he is describing **metered** fleet work (parallel orbs, parked agents), not a subscription. At individual scale the corpus's own practitioners run large agent setups on flat consumer plans without reporting a ceiling — so for a non-engineer this is a skill divide, and the budget is one subscription. See the scoping note on [[enterprise-ai-reality]].
|
||||
- **The velocity claim:** *"You cannot take a programmer who doesn't use AI, they're going to get crushed by a mediocre programmer with AI."* Stated about programmers, but the internal-software argument extends it to any role that has ever maintained a spreadsheet.
|
||||
- **The hard part is not building.** His printer anecdote is the whole skill in one exchange: asked to build an app so a tablet prints a paper receipt for the kitchen, he answered *"Why do you need a printer? Why not a second tablet?"* Seeing the workflow underneath the request is the surviving competence — see [[product-ownership]] and the first-principles section there.
|
||||
|
||||
**Why this matters for the webinar.** It is the outside evidence for thesis T5 in [[2026-07-28-webinar-theses]] — the claim that had been the talk's least provable. [[eugene]]'s arc (chat box → your own OS) lands on exactly this: "It dissolved — into the operating system. Into little tools you make for yourself… You don't buy it. You build it — one small tool at a time." Thorsten reaches the same endpoint from a frontier-engineering starting point and with a non-technical audience (a 20-person social club, a menu photo, a phone). That convergence is usable evidence: the pitch is not an engineer's fantasy about non-engineers, it is what happens when someone with the skill applies it to an ordinary group of people.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Excel/wiki/hack replacement, the club ordering app in ~2 hours of phone typing, the token-budget variable, "crushed by a mediocre programmer with AI," the printer anti-example — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- The webinar's convergent framing — "little tools you make for yourself," the OS arc — `raw/notes/Webinar script.md` (raw, not yet ingested).
|
||||
- Non-engineer capability ceiling and the same build-it-yourself instinct — [[levels-of-ai-usage]], [[personal-ai-operating-system]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[emacsification-of-software]] (sibling mechanism — remixing rather than building), [[maintenance-is-the-real-cost]] (the bounding counterweight), [[personal-ai-operating-system]], [[levels-of-ai-usage]], [[product-ownership]], [[shedding-weight]], [[enterprise-ai-reality]] (token budget as access), [[solve-first-then-skillify]]
|
||||
- Entities: [[thorsten-ball]], [[eugene]], [[allie-miller]], [[virtido]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- **Survivorship.** Thorsten is a founding engineer at an agent company building for a club he belongs to. The corpus's actual non-engineers ([[nina]], [[yulia]], [[larysa]]) hit friction, [[integration-dead-ends|integration dead-ends]] and memory loss well before "2 hours on a phone." His datapoint proves the ceiling is high, not that the floor is low. Status: tentative.
|
||||
- **Nobody owns the result.** Internal software built in an evening still needs to survive its author leaving, a schema change, or an incorrect order going out. The source treats creation cost as the only cost — the same gap [[emacsification-of-software]] has around maintenance. *(Upgraded 2026-07-29 from self-criticism to a sourced contradiction:* [[2026-07-29-what-if-we-vibe-code-it]] *makes this objection its whole thesis — [[maintenance-is-the-real-cost|the cost of software is maintenance, not writing]] — and supplies the corpus's only observed outcome of this pattern in the wild: a company that built its own Jira clone in March 2026 and returned to a bought tracker by July. Partial reconciliation: the club app passes that source's own build-vs-buy checklist — tiny, no SLA, no external users — so the disagreement is about where the threshold sits, not whether one exists.)*
|
||||
- **The token-budget variable is named and then dropped.** Who pays, how much, and what happens to people or teams without the budget is unaddressed in the source. Partly resolved by scope (see above): under flat-rate consumer pricing it appears not to bind at individual scale, and the corpus has two practitioners running large setups to show it. It remains open for metered pricing and fleet scale — and [[eugene]]'s prediction that prices *rise* ("what I now buy for 200 will cost about 1,000") would reopen it for everyone if it holds. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- What is the realistic first internal tool for the webinar's HR audience — and does it survive contact with the friction Nina and Yulia describe?
|
||||
- Is there a threshold above which internal software must graduate to being owned like a product (an on-call rota, a schema, a backup), and where is it? *(Sharpened 2026-07-29: [[maintenance-is-the-real-cost]] supplies a checklist for the question — size, ongoing support, operational load, second-business willingness — but not the line itself.)*
|
||||
@@ -16,6 +16,8 @@ The harness is the de-facto unit of agentic work in 2026. A good one has: a **sh
|
||||
|
||||
**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.
|
||||
|
||||
**A second reference harness: [[amp]].** Where [[claude-code]] is local-first and user-extended, AMP is sandbox-first and vendor-curated ([[2026-07-28-agentic-engineering-10x-developer]]): a PWA install, a low/medium/high/ultra dial that maps each level to a model *and* a sub-agent set, named sub-agents (**Oracle** the reviewer, **Painter** the image generator), a meta-agent (**Puck**) that spawns and messages other agents, and **orbs** — remote sandboxes where one URL carries thread + agent + computation + diff (see [[async-by-default]]). Two things it demonstrates about the concept: the harness is now the *product* (AMP's most-asked customer question is "what's the meta — what model, what prompt?", i.e. customers pay for research decisions), and a harness can be strong with **no user-authored skills layer at all** — the structure exists, but the vendor supplies it. That is the design axis [[hermes]] and Claude Code put in the user's hands.
|
||||
|
||||
**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
|
||||
@@ -26,16 +28,18 @@ The harness is the de-facto unit of agentic work in 2026. A good one has: a **sh
|
||||
- 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]].
|
||||
- AMP's dial/sub-agents/meta-agent/orbs; "what's the meta?" as the customers' recurring question — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
|
||||
## 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]]
|
||||
- Tools: [[claude-code]], [[hermes]], [[amp]]
|
||||
- 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]], [[async-by-default]], [[shedding-weight]]
|
||||
- Entities: [[eugene]], [[sebastian]], [[konstantin]], [[larysa]], [[thorsten-ball]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- Personal vs company-managed harness is an unresolved tension (Eugene vs Sebastian), not a settled answer.
|
||||
- Personal vs company-managed harness is an unresolved tension (Eugene vs Sebastian), not a settled answer. [[amp]] adds a third option neither of them argues for: a **vendor-managed** harness, where the research decisions are the purchase and the user tunes almost nothing.
|
||||
- **Local vs remote.** Eugene's consolidation pitch assumes one place *on your machine*; Thorsten predicts local dev disappears into remote sandboxes. Compatible only if the thing being consolidated is the interface rather than the compute. Status: tentative.
|
||||
- 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
|
||||
|
||||
@@ -17,6 +17,8 @@ This is Eugene's explicit critique of demo culture: asking Claude to build a who
|
||||
|
||||
**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.)
|
||||
|
||||
**A worked example of the constructive form.** [[thorsten-ball]]'s prompt for porting a feature to the CLI ([[2026-07-28-agentic-engineering-10x-developer]]) shows what "less room" looks like without a skill: **set the standard** ("look at how it's implemented in web UI") → **state intent** ("I want to port this to our CLI") → **riff on the design** (name the commands, guess at the modality, invite disagreement) → **specify process** ("research how it's implemented, research how we communicate it, document how it works, sit down and think, compile what you learned, *then* come up with a good idea") → **set constraints and economics** ("Fable is expensive — use GPT models for the implementation, then present the results"). His summary: *"This is how I would talk to a senior engineer. This is the Slack message I'd send."* Note that the *process* step is doing most of the work here — it removes imagination about **how to proceed**, not only about what to build. Worth holding against this page's remedy: Eugene freezes procedure into a [[skills-as-memory|skill]]; Thorsten retypes it, and rejects skills outright (see that page's contradictions).
|
||||
|
||||
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
|
||||
@@ -24,17 +26,19 @@ Tension worth holding: [[think-wider-not-bigger]] argues for giving models *more
|
||||
- "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]].
|
||||
- The five-part prompt structure (standard / intent / riff / process / economics); "the Slack message I'd send to a senior engineer"; stop tuning model choice — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
|
||||
## 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]]
|
||||
- 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]], [[context-as-scarce-resource]]
|
||||
- Entities: [[eugene]], [[larysa]], [[claude-code]], [[thorsten-ball]]
|
||||
|
||||
## 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.
|
||||
- **Model choice as a lever, or a distraction?** (added 2026-07-28.) Eugene selects *against* over-proactivity at the model level (4.7 over 4.8). [[thorsten-ball]] says the opposite about the whole activity: past a frontier model there are diminishing returns on which one you pick and even on the effort level, and "if you're mad your model doesn't use camelCase, rethink your software engineering, not the model" — put the effort into the information you supply ([[context-as-scarce-resource]]). They are reconcilable if Eugene's complaint is about *behaviour under an underspecified prompt* rather than capability, which is exactly what Thorsten would say the prompt should fix. Neither addresses the other. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
|
||||
@@ -20,6 +20,7 @@ Supporting practices at the plateau: keep CLAUDE.md self-maintaining ("always ke
|
||||
- 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]].
|
||||
- **Measured, team-level corroboration that the gap grows between rungs of mastery**, not between license-holders and others: Stanford's 46-vs-46-team analysis shows the productivity gap between AI-mastering and lagging teams growing 4.8% → 19% (4×) over ~2.25 years — [[2026-07-30-stanford-swepr-widening-gap]]. *(Caveat: measures engineering teams, not this ladder's non-programmer audience; and the study asserts "quality of usage" as the differentiator without decomposing which rung supplies it.)*
|
||||
|
||||
## Related Pages
|
||||
|
||||
@@ -33,5 +34,7 @@ Supporting practices at the plateau: keep CLAUDE.md self-maintaining ("always ke
|
||||
|
||||
## Next Questions
|
||||
|
||||
- Does the final webinar script keep this exact rung order? (`raw/sources/Webinar script.md` is not yet ingested.)
|
||||
- **Is the top rung the right ceiling?** (Raised 2026-07-28 by lint.) This ladder's non-programmer ceiling is *CLAUDE.md + skills*, and [[thorsten-ball]] reaches the frontier with neither — no skills, no MCP, no slash commands, context in the codebase and `AGENTS.md` ([[2026-07-28-agentic-engineering-10x-developer]]). If his practice generalises, the ladder's top two rungs are a detour rather than a summit; if it doesn't, the reason is that he has a codebase to encode context into and this ladder's audience does not — which would be worth stating *as* the rung's precondition. See [[skills-as-memory]] for the three competing readings.
|
||||
|
||||
- Does the final webinar script keep this exact rung order? (`raw/notes/Webinar script.md` — an authored deliverable, not an ingest candidate.)
|
||||
- Where do agents/processes (the harness's outer loops) sit for a non-programmer — above skills, or out of reach?
|
||||
|
||||
37
wiki/concepts/maintenance-is-the-real-cost.md
Normal file
37
wiki/concepts/maintenance-is-the-real-cost.md
Normal file
@@ -0,0 +1,37 @@
|
||||
# Maintenance Is the Real Cost
|
||||
|
||||
#concept
|
||||
|
||||
## Summary
|
||||
|
||||
The cost of software was never in writing it — it is in **running it after the first user arrives**. AI collapsed the writing cost, which was always the small part, and left the real cost untouched. The trap of the vibe-coding era: "assemble in two weeks — easy; carry it forward — impossible." An internal service is an internal business.
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- **The misconception being corrected:** "we couldn't build our own Jira before, and now with AI we can." False on both ends — developers always could (by hand, with a team, in months); they didn't because they didn't want to *operate* the result. The blocker was never capability.
|
||||
- **What arrives with the first user:** bugs and regressions, feature requests, "something's not working / working wrong / didn't work," logs, monitoring, on-call, uptime responsibility. The project built "to save on a subscription" becomes a standing job with dedicated people — exactly the job the vendor was paid to do.
|
||||
- **The two-business paradox:** a company whose product is X, quietly carrying a self-hosted tracker/logger, is running two IT businesses. Bad for the company (pays for one product, staffs two) and for the developer (a primary job you're blamed for neglecting, plus a secondary one you're blamed for neglecting).
|
||||
- **The pendulum case:** March 2026 — a company builds its own Jira clone and migrates; July 2026 — the same (or a similar) company returns to a bought tracker (Linear). Status: tentative (second-hand tweets, fuzzy identification), but it is the corpus's only *observed outcome* of the build-your-own-tools thesis, and it's a reversal.
|
||||
- **The build-vs-buy checklist** (prescriptive): rewrite only small, non-evolving dependencies; if it needs ongoing support, cost it as a separate project; count the operational load; ask whether the business wants a second IT business inside itself. Otherwise keep paying the vendor — the money buys operational offload, not code.
|
||||
- **Where it agrees with the vault's spine:** "writing code was never the bottleneck" is the same premise as [[harness]]-over-model and [[make-more-cheap-code]]'s verification bottleneck. The corpus now has three candidates for the *real* bottleneck — context (Thorsten), verification (Theo), maintenance (this source) — which are not rivals: they are the costs at authoring time, at shipping time, and over the artifact's lifetime, respectively.
|
||||
|
||||
## Evidence
|
||||
|
||||
- All claims, the pendulum case, the checklist, the Datadog self-report — [[2026-07-29-what-if-we-vibe-code-it]].
|
||||
- The objection was already latent in the vault before this source named it: [[explosion-of-internal-software]] ("nobody owns the result") and [[emacsification-of-software]] ("maintenance is assumed away") both flagged it as their own weakest point.
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[explosion-of-internal-software]] (the thesis this bounds), [[emacsification-of-software]] (forks age too), [[code-as-throwaway]] (throwaway is safe *because* unmaintained), [[make-more-cheap-code]] (the ship/no-ship line is also the maintain/no-maintain line), [[shedding-weight]] (the inverse move — deleting owned software rather than acquiring it), [[product-ownership]] (owning an outcome includes owning its ops)
|
||||
- Entities: [[thorsten-ball]] (the predictions this bounds)
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- **vs. [[explosion-of-internal-software]] / [[thorsten-ball]]:** Thorsten predicts teams remix mid-size software ("Riverside but audio-only") and the Excel layer becomes real tools; this source's pendulum case is that pattern failing in the wild. Partial reconciliation: the club app *passes* this source's own checklist (tiny, no SLA, no external users) — the disagreement is only about where the threshold sits, not whether one exists. Recorded on both pages.
|
||||
- **Does the objection survive agents doing the maintenance?** The author assumes ops load lands on humans. The corpus's outer-loop material ([[agentic-loops]], [[async-by-default]]) implies agents could absorb some of it — but no source demonstrates agent-carried ops for an internal service, and [[async-by-default]]'s own caveat (proof produced by the thing being checked is not verification) cuts against trusting it blind. Open.
|
||||
- The pendulum case is one anecdote, second-hand. The author's own company is *currently* building a Datadog replacement — if it ships and survives, he becomes his own counterexample. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- Where exactly is the graduation threshold — the point at which a personal/internal tool must be owned like a product (on-call, schema, backups)? [[explosion-of-internal-software]] asks the same question; this source supplies the checklist but not the line.
|
||||
- For the webinar's HR audience: which of their candidate tools (candidate knowledge base, transcribe→summarize) fall on the safe side of the checklist, and which quietly cross into "second business"?
|
||||
@@ -15,16 +15,20 @@
|
||||
- **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").
|
||||
- **Variations, not answers** (added 2026-07-28). [[thorsten-ball]] extends the same economics past code into *design decisions*: ask for 10–15 variants and pick one. His orb icon came from 15 AI-generated versions across styles and 18 palettes; AMP's news imagery from turn-by-turn Midjourney rounds. Generation is cheap, so the human's job moves from producing the artifact to **choosing among artifacts** — taste at AI speed, which is his answer to the slop objection ([[code-as-throwaway]]). The webinar-relevant part: this is the version of "make more cheap code" that needs no codebase, so it transfers directly to a non-engineer ([[2026-07-24-non-engineer-throwaway-verification]]).
|
||||
- **Ask for proof, since you're waiting anyway.** Screenshots, benchmarks, dark-mode and light-mode variants, fifty tests in parallel — cheap generated artifacts whose only job is to make a claim checkable. See [[async-by-default]], where the practice belongs to delegation rather than to reading.
|
||||
|
||||
## 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]].
|
||||
- 15 icon variants, Midjourney rounds, "ask the agent for proof" — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- **External measurement of the cost moving downstream:** Stanford SWEPR coverage reports +91% PR review time and ~2.6× rework in AI-heavy workflows — writing got cheaper, reviewing got dearer, which is this page's premise measured rather than asserted — [[2026-07-30-stanford-swepr-widening-gap]]. *(Secondary-coverage numbers; and note the same study's negative gains in complex brownfield code — "code is cheap" holds least where most code lives.)*
|
||||
|
||||
## 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]]
|
||||
- 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]], [[async-by-default]] (proof artifacts as the delegated form of the same move), [[review-is-the-new-bottleneck]] (the org-level form of the cost shift this page manages individually — with the completed-without-rework metric as its answer)
|
||||
- Entities: [[theo-browne]], [[eugene]], [[thorsten-ball]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
@@ -35,4 +39,5 @@
|
||||
## 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?
|
||||
- Does tier-A slop generation stay cheap once context is accounted for — or does reviewing *agent behavior* replace reviewing code as the attention sink? *(Sharpened 2026-07-28: [[async-by-default]] multiplies parallel agents without multiplying review capacity, and Thorsten names **token budget** as a winner/loser variable — so the honest answer may be that cheap code is cheap in money and expensive in attention, which is precisely the resource this page says is binding.)*
|
||||
- Does "15 variations, pick one" hold where the choice needs a criterion rather than taste? Picking an icon is judgment you already have; picking among 15 candidate job descriptions or architectures may require the analysis the variations were supposed to replace.
|
||||
|
||||
@@ -20,21 +20,26 @@ Three layers, built bottom-up:
|
||||
|
||||
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]].
|
||||
|
||||
**The fourth layer the corpus keeps circling: tools you build for yourself.** Allie's three layers are all *context and orchestration*; [[explosion-of-internal-software]] adds the artifact — a real, small piece of software replacing the spreadsheet. [[thorsten-ball]] supplies the non-engineer-shaped proof (a 20-person club's ordering process, ~2 hours of phone typing) and [[eugene]]'s webinar arc lands on the same place: "little tools you make for yourself." The interface question is where they differ — Thorsten deletes UI so he can prompt ([[build-for-the-agent-not-the-human]]); the OS framing builds a tiny UI so you need not prompt. Both agree the *generic* surface, chat box or admin panel, is what disappears.
|
||||
|
||||
## 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.
|
||||
- Independent convergence on tools-you-build-for-yourself, from a frontier engineer applying it to a non-technical group — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[skills-as-memory]], [[context-as-scarce-resource]], [[connections-as-moat]], [[levels-of-ai-usage]]
|
||||
- Entity: [[allie-miller]], [[eugene]]
|
||||
- Tools: [[claude-code]]
|
||||
- Concepts: [[skills-as-memory]], [[context-as-scarce-resource]], [[connections-as-moat]], [[levels-of-ai-usage]], [[explosion-of-internal-software]], [[build-for-the-agent-not-the-human]], [[async-by-default]] (scheduled workflows are its non-engineer form)
|
||||
- Entity: [[allie-miller]], [[eugene]], [[thorsten-ball]]
|
||||
- Tools: [[claude-code]], [[amp]]
|
||||
- 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.
|
||||
- **Persistent context vs memory-as-anti-feature** (recorded here 2026-07-28 by lint; previously logged only on [[skills-as-memory]]). Allie's layer 1 is persistent context documents, used without complaint. [[eugene]] holds that built-in agent memory is a net negative — "it gives no benefit and confuses users to hell… it'd be better if it didn't [exist]" ([[2026-07-21-larysa-interview]]). The two are largely reconcilable — both prefer *authored* context over *inferred* context, and Allie's docs are authored — but the blanket condemnation is one voice and this page never registers it. Status: tentative.
|
||||
- **Does the OS need a skills layer at all?** [[thorsten-ball]] runs a 99%-AI-written codebase with no skills, no MCP and no slash commands ([[2026-07-28-agentic-engineering-10x-developer]]), which challenges layer 2 of this stack directly. Three competing readings are logged on [[skills-as-memory]]; the one most favourable to this page is that his context lives in a codebase he owns, and Allie's audience has none. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
|
||||
@@ -12,21 +12,26 @@ The durable human skill in the AI era: **owning outcomes**, not completing ticke
|
||||
- **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.
|
||||
- **First-principles thinking becomes the top skill** ([[thorsten-ball]]). His anti-example: someone at his club asked for an app so a tablet prints a paper receipt the kitchen picks up. His push-back — *"Why do you need a printer? Why not a second tablet?"* — is the whole competence in one question. The skill is **seeing the workflow underneath the request**, and it is now the scarce half of the job: *"everyone becomes an architect,"* and the value is knowing solutions from other industries and having the right idea for this problem. Note the direction of travel: the profile-picture story above is a failure to check the *output*; the printer story is a failure to check the *problem*. Ownership now runs at both ends.
|
||||
- **What just got commoditised.** What senior engineers used to hand-teach over 2–3 years — his example, the safe multi-step column-drop migration — is a 30-second model output. Also gone is the lucky overlap of the last 20–30 years, where "the guy who loves Haskell on weekends is also the guy who models the finance backend well." Technical depth and domain judgment have come apart, and only the second is still scarce. See [[seniority-and-the-junior-squeeze]].
|
||||
|
||||
## 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]].
|
||||
- The printer/tablet push-back, "everyone becomes an architect," the 2–3-years-to-30-seconds migration example, the dissolving Haskell/finance-backend overlap — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[code-as-throwaway]], [[seniority-and-the-junior-squeeze]], [[connections-as-moat]], [[decoupling-identity-from-profession]]
|
||||
- Entities: [[sebastian]], [[eugene]], [[allie-miller]]
|
||||
- Concepts: [[code-as-throwaway]], [[seniority-and-the-junior-squeeze]], [[connections-as-moat]], [[decoupling-identity-from-profession]], [[explosion-of-internal-software]] (where the framing skill gets exercised), [[shedding-weight]] (deciding what should exist at all), [[make-more-cheap-code]]
|
||||
- Entities: [[sebastian]], [[eugene]], [[allie-miller]], [[thorsten-ball]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- "Get closer to the product" can improve product quality while *reducing* technical quality — the interview flags this trade-off explicitly.
|
||||
- "Everyone becomes an architect" is asserted, not argued. The corpus's own non-engineers reach for AI to do the framing *for* them ([[levels-of-ai-usage]]), and nothing establishes that first-principles thinking distributes more widely than the technical skill it replaces. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- How do you *teach/hire for* ownership if it's a personality trait, not a checklist?
|
||||
- If the senior's 2–3 years of hand-taught pattern knowledge is now a 30-second output, what is the new apprenticeship — and does it produce the judgment the printer story requires? Compounds the pipeline problem on [[seniority-and-the-junior-squeeze]].
|
||||
|
||||
38
wiki/concepts/review-is-the-new-bottleneck.md
Normal file
38
wiki/concepts/review-is-the-new-bottleneck.md
Normal file
@@ -0,0 +1,38 @@
|
||||
# Review Is the New Bottleneck
|
||||
|
||||
#concept
|
||||
|
||||
## Summary
|
||||
|
||||
When agents write the code, the SDLC doesn't collapse completely — it collapses *around the humans*. [[nikolai-sheiko]]'s two remaining "red squares" are the **reviewer** and the **planner**: tasks pile up in the review queue, reviewers burn out, quality drops, and headline output metrics (PRs, LoC) rise while real throughput barely moves. The organizational fix is twofold: **review with the agent** (not fully manual, not fully delegated) and **measure completed tasks without rework** rather than anything volume-based.
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- **The mechanism.** Generation got ~free, so the cost moved downstream to verification — and at team scale, downstream is a *person* with a queue. Sheiko's European-outsourcer case: more PRs than ever, net gain +1%, because rework consumed the difference. Manual-only review starts a spiral (queue → burnout → rubber-stamping → more rework); fully delegated review is the opposite error ([[async-by-default]]'s "proof produced by the thing being checked").
|
||||
- **The middle path: review together with the agent.** Treat the model as a smart student — direct it, pose hypotheses, locate problems jointly. This is the org-level sibling of Theo's reading economics ([[make-more-cheap-code]]: AI reviews before humans, per-file summaries, read only what's worth reading).
|
||||
- **The metric that resists gaming:** a task counts as done only if it **doesn't come back for rework**; track task lifetime and rework time. LoC, commit count and PR count are all trivially hacked and all rise *because* of the bottleneck, not despite it.
|
||||
- **Externally measured:** Stanford SWEPR coverage reports **+91% PR review time** and ~2.6× rework in AI-heavy workflows, and finds gross code volume up 30–40% while net gains are ~15–20% — the same rework-eats-half story Sheiko tells anecdotally ([[2026-07-30-stanford-swepr-widening-gap]]).
|
||||
- **Planning is the other red square.** Time redistributes from coding to "planning on the left + verification on the right" — which is why Sheiko prescribes 20-minutes-minimum planning and why a **Product engineer** role emerges ([[developer-as-agent-manager]]).
|
||||
|
||||
## Evidence
|
||||
|
||||
- Reviewer/planner as the remaining red squares; review-with-the-agent; the metrics table; the +1% outsourcer case — [[2026-07-30-rakes-in-ai-sdlc-adoption]].
|
||||
- +91% PR review time, 2.6× rework, gross-vs-net gap — [[2026-07-30-stanford-swepr-widening-gap]] *(secondary-coverage numbers)*.
|
||||
- Reading as the scarce human resource; AI-review-before-human-review; tiered reading discipline — [[2026-07-24-youre-reading-way-too-much-code]] via [[make-more-cheap-code]].
|
||||
- Parallel agents multiplying diffs without multiplying review capacity — the attention pile-up already logged on [[async-by-default]]; this page names that open question as the bottleneck it becomes at team scale.
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[make-more-cheap-code]] (individual-level discipline for the same cost shift), [[async-by-default]] (the generation side that feeds the queue), [[developer-as-agent-manager]] (the role shift on the human side of the queue), [[seniority-and-the-junior-squeeze]] ("read what you approve" — why review can't just be dropped), [[maintenance-is-the-real-cost]] (kindred move: the visible activity was never the expensive part)
|
||||
- Entities: [[nikolai-sheiko]], [[swepr]], [[theo-browne]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- **How much review survives?** Theo/Dax hold that agent diff-summaries surface anomalies; [[eugene]] holds that drift is precisely what summaries miss ([[leave-less-room-for-imagination]]); Sheiko's review-with-the-agent is a third position between them — asserted, not tested. Status: tentative.
|
||||
- The completed-without-rework metric is better than LoC/PRs but still gameable (e.g. by inflating task granularity or quietly reclassifying rework as new tasks); the source doesn't address it. Status: tentative.
|
||||
- Whether review-as-bottleneck is transitional (until verification is agentized) or structural (a human must always sign off — the [[seniority-and-the-junior-squeeze|accountability]] view) is open across the corpus.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- What does review-with-the-agent look like concretely — a checklist, a dialogue pattern, a skill? The corpus has the prescription but no transcript of it done well.
|
||||
- Is there a non-engineer analog (the webinar audience reviews documents, not PRs)? The checker-skill design in [[2026-07-24-non-engineer-throwaway-verification]] may be it.
|
||||
@@ -12,20 +12,24 @@ Counter-intuitively, AI has *raised* demand for seniors and made juniors "comple
|
||||
- **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.
|
||||
- **What the levelling actually consumed** ([[thorsten-ball]], 2026-07-28): the transferable content of seniority. "What senior engineers used to hand-teach in 2–3 years" — his example is the safe multi-step column-drop migration — "is now a 30-second model output." So the *knowledge* half of seniority is commoditised while the *judgment* half is not, which is a sharper version of this page's claim and a harsher one for the pipeline: juniors are squeezed out of the entry-level work **and** the apprenticeship that work used to constitute. He also notes the end of a lucky historical overlap: the person who loved Haskell on weekends was also the person who modelled the finance backend well; those two skills have now come apart, and only the domain half is scarce.
|
||||
- **The floor rose, not just the ceiling.** *"You cannot take a programmer who doesn't use AI, they're going to get crushed by a mediocre programmer with AI."* Read alongside the levelling caveat, the competitive line is no longer senior-vs-junior but tooled-vs-untooled — which is the same claim [[allie-miller]] makes about the irreversible gap, stated about professionals rather than individuals.
|
||||
|
||||
## 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]].
|
||||
- 2–3 years of hand-taught knowledge → 30-second output; the dissolving Haskell/finance overlap; "crushed by a mediocre programmer with AI"; "don't compare yourself to the 1%" — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[product-ownership]], [[enterprise-ai-reality]], [[connections-as-moat]], [[code-as-throwaway]]
|
||||
- Entities: [[sebastian]], [[eugene]]
|
||||
- Concepts: [[product-ownership]], [[enterprise-ai-reality]], [[connections-as-moat]], [[code-as-throwaway]], [[explosion-of-internal-software]], [[shedding-weight]]
|
||||
- Entities: [[sebastian]], [[eugene]], [[thorsten-ball]]
|
||||
|
||||
## 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.
|
||||
- **Don't generalise from the 1%.** Thorsten's caution cuts across this whole page: online debates cite Mitchell Hashimoto (Ghostty, a GPU-accelerated terminal emulator) as proof AI "isn't good enough," but that is one of the best programmers alive on atypical software. Most software is CRUD, "MySQL and something-something," which agents handle fine. The senior's judgment premium is real where failure is expensive and thinner than the discourse suggests everywhere else.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- If juniors can't get in, how does the industry produce the next generation of seniors?
|
||||
- If juniors can't get in, how does the industry produce the next generation of seniors? *(Compounded 2026-07-28 — the apprenticeship content itself is now a 30-second output, so the answer cannot be "they'll learn it on the job.")*
|
||||
|
||||
44
wiki/concepts/shedding-weight.md
Normal file
44
wiki/concepts/shedding-weight.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# Shedding Weight
|
||||
|
||||
#concept
|
||||
|
||||
## Summary
|
||||
|
||||
[[thorsten-ball]]'s operating discipline: **most of your process exists because humans used to be the bottleneck, and it should be deleted.** Not optimized — deleted. "Don't optimize for what looks safe today, optimize for the ability to move fast tomorrow."
|
||||
|
||||
## Current Understanding
|
||||
|
||||
The test for any workflow, feature or artifact: *would this exist if agents had always been available?* If not, it is weight.
|
||||
|
||||
Named casualties from the source:
|
||||
|
||||
- **Backlogs.** Old loop: bug reported → backlog → weeks later someone decides it's worth doing → estimate → maybe fix. New loop: *"optimistically spawn these agents, have them parked somewhere, then go through the bug fixes."* You no longer estimate whether a bug is worth fixing when the fix ran while you slept. **Backlogs are an artifact of expensive humans.**
|
||||
- **CI that re-runs the agent's own tests.** The agent is already in an isolated sandbox and already ran the tests; pushing so CI can repeat them for ten minutes is waste motion.
|
||||
- **IDE extensions.** [[amp]] killed its VS Code extension — "who has the editor open anymore?"
|
||||
- **Admin panels and forms.** They existed so that *no code had to change*; changing the code is now cheaper. See [[build-for-the-agent-not-the-human]].
|
||||
- **Local dev environments.** Predicted to go away as remote sandboxes take over ([[async-by-default]]).
|
||||
|
||||
The corporate version is aggressive self-cannibalization: AMP publicly kills its own features and accepts churn from users pushed out of their comfort zone. The commercial logic is that a defensible-looking 2025 product ("single agent in a VS Code sidebar with enterprise permissions and per-line attribution") would have been obsolete within a year.
|
||||
|
||||
**The honest form of the exercise** is his suggested internal doc: *"Software Is Dead — Now What?"* — be specific about which of your processes only survive because humans used to be the bottleneck.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Backlogs, CI, VS Code extension, "AMP Frontier Corporation," the frontier bet, the suggested internal doc — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- The same instinct one layer down: killing code without guilt and resetting rather than guilt-merging — [[2026-07-14-everything-we-knew-about-software-has-changed]], via [[code-as-throwaway]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[code-as-throwaway]] (the artifact-level version of the same move), [[build-for-the-agent-not-the-human]], [[async-by-default]], [[explosion-of-internal-software]], [[product-ownership]] (deciding what should exist is the surviving job), [[enterprise-ai-reality]] (the strongest counterweight)
|
||||
- Entities: [[thorsten-ball]], [[amp]], [[theo-browne]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- **Compliance doesn't shed.** In [[enterprise-ai-reality|regulated enterprises]], CI, audit trails, backlogs and permission systems are frequently *the deliverable* to a regulator, not overhead. Thorsten is describing a startup on the frontier and never scopes the claim; [[sebastian]]'s clients cannot install their own tools, let alone delete their pipeline. Status: tentative.
|
||||
- "The agent already ran the tests" assumes you trust the agent's report of its own run. Nothing in the source addresses a lying or truncated test run — an obvious place for [[make-more-cheap-code|generated verification]] to re-enter.
|
||||
- Deleting the backlog and "parking agents" replaces one queue with another; the source does not say who triages the parked fixes or what that costs in attention.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- What is the smallest safe version of this for a non-frontier team — which single pre-agent workflow gives the biggest return when deleted first?
|
||||
- Does shedding weight have a floor for a *person* rather than a company? The webinar audience's equivalent of "kill your backlog" is unclear. *(Proposed 2026-07-28: the audience-facing form is the question "which of your processes only exist because **you** were the bottleneck?" — carried as thesis T10 in [[2026-07-28-webinar-theses]], where it is suggested as an opener. Untested on a non-engineer audience.)*
|
||||
@@ -14,6 +14,8 @@ A classic skill is "**von Neumann without data**" (code, no data). Adding data +
|
||||
|
||||
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 dissent: a frontier practitioner who skips skills entirely.** [[thorsten-ball]] — 99% of his company's code is AI-written — reports "**no custom slash commands, no skills, no MCP servers**" ([[2026-07-28-agentic-engineering-10x-developer]]). His substitute is not weaker context but *differently located* context: the codebase itself, a team-maintained `AGENTS.md`, and a long prompt written "like a Slack message to a senior engineer" (set the standard → state intent → riff on design → specify process → set sub-agent economics). He agrees with this page's premise — "where does the agent get its information from?" is the only question he thinks matters — and rejects its mechanism. Recorded as a live contradiction under *Contradictions* below rather than reconciled.
|
||||
|
||||
**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
|
||||
@@ -24,19 +26,28 @@ The **method** for populating skills is [[solve-first-then-skillify]]: reach the
|
||||
- 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]].
|
||||
- Counter-evidence: no skills, no MCP, no slash commands at a 99%-AI-written company; `AGENTS.md` + codebase + rich prompt as the substitute — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- **A second practitioner vote *for* the skills layer** (2026-07-30): [[nikolai-sheiko]]'s "Agentic Evolution" makes skill-building-plus-verification the difference between living on defaults and "vertical growth," and he flatly rejects embeddings/RAG over code ("don't use them unless you understand *very* well why") — siding with the load-on-activation camp in the skills-vs-RAG contradiction below. His verification protocol (context-free subagent re-solves the task from the skill alone) is the closest thing yet to the falsification test this page asks for — [[2026-07-30-rakes-in-ai-sdlc-adoption]].
|
||||
|
||||
## 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]]
|
||||
- Tools: [[hermes]], [[claude-code]], [[amp]] (a harness with vendor-curated sub-agents and no user-authored skills layer)
|
||||
- Entities: [[konstantin]], [[allie-miller]], [[eugene]], [[larysa]], [[thorsten-ball]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- **Skills vs RAG** (recorded here 2026-07-28 by lint; previously logged only on [[context-as-scarce-resource]]). This page's Summary asserts load-on-activation beats RAG pre-injection as settled mechanism, but [[2026-07-22-ai-is-stupid]] names **RAG and long-term assistant memory** as *the* practical context mechanisms for a business audience. Possibly not a real disagreement — business *data* may want RAG where *procedures* want skills — but the corpus has never separated the two cases. Status: tentative.
|
||||
- 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.
|
||||
- **Skills may be unnecessary at the frontier** (added 2026-07-28). [[thorsten-ball]] ships 99%-AI-written code with no skills, no MCP and no slash commands. Three readings, none settled by the corpus:
|
||||
1. **Situational.** He works daily in *one codebase he controls*, where context can live in the code and `AGENTS.md`. Skills earn their keep when work is spread across many ad-hoc tasks with no codebase to encode into — which is exactly the corpus's HR/BA audience ([[nina]], [[yulia]], [[larysa]]). Under this reading both are right and the disagreement is about who is speaking.
|
||||
2. **The abstraction is premature.** Skills are scaffolding for models that needed it; a strong model plus a rich prompt plus a good repo may simply beat a skills library, making the whole layer a 2025 artifact. This is the uncomfortable reading for the webinar's central promise.
|
||||
3. **He has skills under another name.** AMP's Oracle/Painter/Puck sub-agents and a maintained `AGENTS.md` *are* curated, reusable, two-stage context — just authored by the vendor and the team rather than the user. Under this reading the dispute is about who curates, not whether curation is needed.
|
||||
Status: tentative. Note the evidential asymmetry — his is a first-hand report of daily practice at scale, where the pro-skills case rests on Konstantin's architecture argument plus self-reported individual workflows. *(Asymmetry softened 2026-07-30: [[nikolai-sheiko]] adds a second practitioner voice on the pro-skills side, from multi-company adoption work rather than one codebase — though his cases are anonymous anecdotes, so the readings above remain unsettled.)* **Presentation-safe restatement:** [[2026-07-28-webinar-theses]] reframes the claim as *context you author beats context that's inferred*, which holds under all three readings — Konstantin's skills, Allie's foundation docs, Eugene's anti-memory position and Thorsten's `AGENTS.md` are all authored context.
|
||||
|
||||
## 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.
|
||||
- Is there a test that would separate reading 1 from reading 2 above? The cheapest one available: give a non-engineer the same task with and without a skill and compare drift — the corpus has never run it, and the webinar's promise rests on the answer. *(Adjacent evidence 2026-07-30: Sheiko's context-free-subagent protocol — [[solve-first-then-skillify]] — runs the with-skill half in practice, but never the without-skill control, so the question stands.)*
|
||||
|
||||
@@ -15,17 +15,28 @@ The recurring beginner mistake is writing the skill first and then trying to "sh
|
||||
|
||||
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."
|
||||
|
||||
**Agentic Evolution — the strongest formulation, plus the missing verification step** (added 2026-07-30). [[nikolai-sheiko]] frames the same method as onboarding an employee: asking the expert "how do you do this?" yields theory; instead **take the new employee (the agent) by the hand through hard real tasks, show it the rakes, then say: "remember all of this and write the manual for the next one."** Without this you live on defaults; with it "vertical growth begins." He then adds what the corpus's earlier heuristics lacked — a **verification protocol** for the frozen skill:
|
||||
|
||||
1. Write the skill together with the agent.
|
||||
2. Don't go to lunch.
|
||||
3. Launch a **subagent with no context** — it must solve the same task from scratch using only the skill.
|
||||
4. The main agent watches what fails and fixes the skill.
|
||||
5. The mentor agent thus onboards the next agent.
|
||||
|
||||
This is the first source to describe actually *running* something close to the skills falsification test proposed on [[skills-as-memory]] (same task, with-skill vs from-scratch) — though it tests the skill's completeness for one task, not whether the skill beats no-skill. His do-tomorrow extension: a skill that analyses your own sessions daily, automated via schedules/routines — evolution as a standing loop rather than a one-time freeze.
|
||||
|
||||
## 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]].
|
||||
- Agentic Evolution (walk the agent through tasks → have it write the manual); the context-free-subagent verification protocol; session-analysis skill as a daily loop — [[2026-07-30-rakes-in-ai-sdlc-adoption]].
|
||||
|
||||
## 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]]
|
||||
- Entities: [[eugene]], [[nina]], [[konstantin]], [[larysa]], [[nikolai-sheiko]]
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
@@ -33,5 +44,6 @@ The payoff goes beyond reuse: a packaged skill is a **handoff and de-risking ass
|
||||
|
||||
## Next Questions
|
||||
|
||||
- What does a good "create a skill from this" prompt look like — does the corpus contain a concrete example transcript?
|
||||
- What does a good "create a skill from this" prompt look like — does the corpus contain a concrete example transcript? *(Partially answered 2026-07-30: Sheiko's "remember all of this and write the manual for the next one" after a guided run is the best prompt-shape the corpus has.)*
|
||||
- How do the ~3-message and >5-tool-call heuristics compare in practice; is one strictly better for non-programmers?
|
||||
- Does the context-free-subagent check catch skill *quality*, or only completeness for the one task it was frozen from?
|
||||
|
||||
@@ -25,6 +25,7 @@ Theo Browne's core reframe: you can't out-improve the models by "getting better"
|
||||
## 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.
|
||||
- **Wide latitude vs tight specs** (recorded here 2026-07-28 by lint; previously logged only on the other side). [[eugene]]'s [[leave-less-room-for-imagination]] argues the opposite reflex: every gap you leave gets filled invisibly, so specs should be tightened and frozen into skills. The reconciliation offered there is *breadth of attempts vs tightness of each spec* — many cheap wide attempts, each individually well-constrained — which preserves both, but neither source addresses the other and the reconciliation is the wiki's synthesis, not either author's. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
|
||||
44
wiki/entities/amp.md
Normal file
44
wiki/entities/amp.md
Normal file
@@ -0,0 +1,44 @@
|
||||
# AMP (Sourcegraph)
|
||||
|
||||
#entity
|
||||
|
||||
## Summary
|
||||
|
||||
Agent product from Sourcegraph, where [[thorsten-ball]] is a founding engineer. The vault's **second reference [[harness]]** after [[claude-code]], and the one that pushes hardest on remote execution: its unit of work is the **orb**, a sleeping remote sandbox tied to one conversation. Officially self-described as "AMP Frontier Corporation."
|
||||
|
||||
## Current Understanding
|
||||
|
||||
**Operating principle:** don't optimize for what looks safe today, optimize for the ability to move fast tomorrow. They could have made money in 2025 building "a single agent in a VS Code sidebar with an enterprise permission system and per-line attribution" — and that model would have been obsolete within a year. Instead they publicly kill their own features on `ampcode.com/news` (the VS Code extension went first). Some users churn; the ones who stay respect the pushing. See [[shedding-weight]].
|
||||
|
||||
**Shape of the product:**
|
||||
|
||||
- Installed as a **PWA** from `ampcode.com` (Thorsten suspects the acronym itself blocks mass adoption of the install flow).
|
||||
- A **low / medium / high / ultra dial**, each level mapping to a model *and* a sub-agent choice. Default is medium.
|
||||
- Sub-agents: **Oracle** (reviewer, gives advice) and **Painter** (generates images). Meta-agent **Puck** controls other agents, spawns orbs, messages them, and runs flows.
|
||||
- Multi-model: GPT, Anthropic and GLM models all supported.
|
||||
- **Orbs**: one URL packages the thread + the agent + the computation + the diff; the sandbox sleeps when idle and wakes on typing; the same conversation streams to phone, laptop and TUI; share the URL and a teammate takes over. Agent-to-agent communication shipped recently. See [[async-by-default]].
|
||||
|
||||
**What customers actually buy:** the most common question AMP gets is "guys, what's the meta? What model, what prompt?" — customers are paying for the research decisions as much as the software. That is a commercial restatement of [[harness|harness-over-model]].
|
||||
|
||||
**Internal practice:** ~99% of AMP's own code is AI-written; a bug is screenshotted, sent to AMP, and returned as a fix from an orb for spot-check and merge; side-bugs get their own parallel orb, branch and checkout.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Frontier bet, feature-killing, PWA install, model dial, Oracle/Painter/Puck, orbs, multiplayer, velocity anecdotes, live production ship — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Entities: [[thorsten-ball]]
|
||||
- Concepts: [[harness]], [[async-by-default]], [[shedding-weight]], [[build-for-the-agent-not-the-human]], [[code-as-throwaway]]
|
||||
- Related tools: [[claude-code]] (the vault's other reference harness; local-first where AMP is sandbox-first), [[hermes]] (skills-first, the axis AMP ignores)
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- AMP ships sub-agents and a meta-agent but no user-authored skills layer — a harness design that assumes the *vendor* curates structure, where [[hermes]] and [[claude-code]] assume the *user* does. Whether that is a philosophy or a roadmap gap is unstated.
|
||||
- "15+ sandbox providers racing to zero margin" is Thorsten's own prediction about the infrastructure his product depends on; he calls it unsustainable without saying what AMP does about it.
|
||||
- All internal metrics are self-reported by a founding engineer. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- Does the orb model survive [[enterprise-ai-reality|enterprise compliance]] — code and conversation living in a vendor's remote sandbox is exactly what Sebastian's clients lock down?
|
||||
- Is "bring your own agent" ([[build-for-the-agent-not-the-human]]) compatible with selling an agent?
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## 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.
|
||||
Anthropic's agentic coding CLI/harness, cited across most of the corpus as the reference [[harness]] and used by every practitioner in it except [[thorsten-ball]] (who runs [[amp]]). Used interactively and in fire-and-forget / scheduled modes.
|
||||
|
||||
## Current Understanding
|
||||
|
||||
@@ -29,7 +29,7 @@ Claude Code recurs as the concrete example of the "universal agent" pattern: a s
|
||||
|
||||
- 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
|
||||
- Related tools: [[hermes]] (skills-first harness), [[amp]] (sandbox-first, vendor-curated — the contrasting harness design: orbs instead of a local working directory, Oracle/Painter/Puck instead of user-authored skills), Codex CLI, OpenClaude (a Claude Code fork), Cursor, Conductor
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
|
||||
36
wiki/entities/nikolai-sheiko.md
Normal file
36
wiki/entities/nikolai-sheiko.md
Normal file
@@ -0,0 +1,36 @@
|
||||
# Nikolai Sheiko
|
||||
|
||||
#entity
|
||||
|
||||
## Summary
|
||||
|
||||
Speaker of the talk "Грабли во внедрении ИИ в SDLC" ([[2026-07-30-rakes-in-ai-sdlc-adoption]]). Russian-speaking AI-adoption practitioner/consultant who works with client companies (a frontend-migration team, a European outsourcer, a large-codebase company) on getting real results from AI in the software lifecycle. Background beyond the talk unknown.
|
||||
|
||||
## Current Understanding
|
||||
|
||||
His through-line: the models are already good enough — **people, companies and metrics are what throttle the gains**. Signature positions:
|
||||
|
||||
- The AI-developer is a **manager of an agent-employee**, IO-bound and parallel ([[developer-as-agent-manager]]).
|
||||
- **Review is the new bottleneck**; review *with* the agent; measure completed-tasks-without-rework, never LoC/PRs ([[review-is-the-new-bottleneck]]).
|
||||
- **Agentic Evolution**: walk the agent through hard tasks, then have it write the manual; verify skills with a context-free subagent ([[solve-first-then-skillify]]).
|
||||
- Companies should install and configure Claude Code / Codex rather than build custom AI tooling; buy a **teacher/curator**, not an external configurator ([[enterprise-ai-reality]]).
|
||||
- Best practices matter *more* with agents (compaction curse, AST search over grep); embeddings/RAG over code don't work ([[context-as-scarce-resource]]).
|
||||
- AI eats **Intelligence**; **Judgment** (taste or domain expertise) stays human for now.
|
||||
|
||||
## Evidence
|
||||
|
||||
- All positions — [[2026-07-30-rakes-in-ai-sdlc-adoption]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Concepts: [[developer-as-agent-manager]], [[review-is-the-new-bottleneck]], [[solve-first-then-skillify]], [[enterprise-ai-reality]], [[context-as-scarce-resource]]
|
||||
- Entities: [[swepr]] (he cites their Stanford chart as the stakes — "be in the top half"), [[thorsten-ball]] (fellow frontier practitioner; they disagree on skills — Sheiko builds skill evolution, Thorsten uses none)
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- His client cases are anonymous and self-reported; no numbers are verifiable. Status: tentative.
|
||||
- Identity/affiliation beyond the talk unknown (the raw doc names only the talk itself). Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- Who is he professionally — independent consultant, agency, vendor? Affects how to weigh the "you don't need custom AI development" claim (it is also a consultant's pitch).
|
||||
35
wiki/entities/swepr.md
Normal file
35
wiki/entities/swepr.md
Normal file
@@ -0,0 +1,35 @@
|
||||
# SWEPR (Stanford Software Engineering Productivity Research)
|
||||
|
||||
#entity
|
||||
|
||||
## Summary
|
||||
|
||||
Research group at Stanford University measuring software-engineering productivity from private Git data — 600+ companies, ~100k–120k engineers since 2022 — using an ML model that replicates a panel of expert code reviewers. Public face: researcher **Yegor Denisov-Blanch**. Source of the corpus's only quantitative outside study of AI's productivity impact.
|
||||
|
||||
## Current Understanding
|
||||
|
||||
- Site: https://softwareengineeringproductivity.stanford.edu/ — offers an "AI Practices Benchmark" and "AI Impact" research to participating companies.
|
||||
- Known for three results: the **widening-gap DiD analysis** (46 vs 46 teams, gap 4.8% → 19%, 4×, Apr 2023–Jul 2025), the **~15–20% net average gain** figure (after rework; 30–40% gross), and the earlier **"ghost engineers"** finding (~9.5% of engineers show virtually no verifiable output).
|
||||
- Methodology is peer-reviewed (arXiv 2409.15152, 2502.20747); the headline AI-impact analyses are talk/deck-published (Sept 2025 AI Conference deck "Will AI Replace Software Engineers?").
|
||||
- Their measurement philosophy — functionality delivered, not commits or LOC — aligns with the corpus's own suspicion of volume metrics ([[make-more-cheap-code]]: generation volume is the *cheap* part).
|
||||
|
||||
## Evidence
|
||||
|
||||
- All claims and links — [[2026-07-30-stanford-swepr-widening-gap]].
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Sources: [[2026-07-30-stanford-swepr-widening-gap]]
|
||||
- Concepts: [[levels-of-ai-usage]] (team-level twin of the mastery gap), [[context-as-scarce-resource]] (codebase-size finding), [[make-more-cheap-code]] (review-time shift)
|
||||
- Queries: [[2026-07-30-stanford-widening-gap-source]]
|
||||
- Entities: [[allie-miller]] (her prediction, their measurement)
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- Data is proprietary and opt-in — no outside replication possible; participating companies may skew toward the measurement-friendly. Status: tentative.
|
||||
- The widening-gap analysis itself is not peer-reviewed as of 2026-07-30. Status: tentative.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- Track whether the DiD analysis lands in a peer-reviewed venue.
|
||||
- What do they say *causes* the gap (tooling vs hygiene vs practices)? The talks assert "quality of usage" without decomposing it.
|
||||
@@ -23,7 +23,7 @@ His second source in the vault sharpens the disposable-code stance into a discip
|
||||
|
||||
- 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)
|
||||
- Compare: [[konstantin]] (model-builder's orchestration view), [[allie-miller]] (personal-OS view), [[thorsten-ball]] (nearest ally — independently reaches "slop is a human problem" and code-is-cheap from inside a shipping company; where Theo defends cheap code with *verification discipline*, Thorsten defends it with *taste*)
|
||||
- Comparison: [[theo-konstantin-allie]] — three-lens side-by-side (Theo/Konstantin/Allie)
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
43
wiki/entities/thorsten-ball.md
Normal file
43
wiki/entities/thorsten-ball.md
Normal file
@@ -0,0 +1,43 @@
|
||||
# Thorsten Ball
|
||||
|
||||
#entity
|
||||
|
||||
## Summary
|
||||
|
||||
Founding engineer at [[amp]] (Sourcegraph's agent product); author of *Writing an Interpreter in Go* and *Writing a Compiler in Go*. The corpus's most extreme practitioner datapoint: **99% of the code at his company is written by AI**, and he uses **no skills, no MCP servers, and no custom slash commands**.
|
||||
|
||||
## Current Understanding
|
||||
|
||||
Thorsten's position is that the frontier has moved past tooling questions. What matters is (1) where the agent's information comes from, (2) how agent-friendly your codebase and workflow are, and (3) knowing what you want to build. Everything else — model choice, effort levels, prompt tricks — he treats as diminishing returns or hobby.
|
||||
|
||||
His operating discipline is **[[shedding-weight]]**: aggressively deleting processes and products that only made sense when humans were the bottleneck. AMP publicly kills its own features (the VS Code extension: "who has the editor open anymore?"), and he applies the same knife to backlogs, CI that repeats the agent's tests, and admin panels.
|
||||
|
||||
He is also the corpus's clearest voice on **taste surviving automation**: 99% AI-written code plus 15 AI-generated icon variants he picks between is not slop, because "slop comes from humans not having good product." This is [[theo-browne]]'s position stated from inside a company rather than from a podium — the two are the corpus's closest allies.
|
||||
|
||||
**Where he cuts against the vault:** his answer to "how does the agent know things?" is a good prompt plus a good codebase plus `AGENTS.md` — not [[skills-as-memory|skills]]. He talks to the model "like a Slack message to a senior engineer": set the standard, state intent, riff on design, specify process, set sub-agent economics. Worth holding as a live alternative rather than dismissing: he is a professional engineer working daily in one codebase he controls, which is the situation where codebase-as-context works best and portable skills matter least.
|
||||
|
||||
## Evidence
|
||||
|
||||
- Interview "Agentic Engineering, explained by a 10x developer" (42:33, with David Andre): shed weight, orbs, Emacsification, internal software, first-principles thinking, prompt structure, predictions — [[2026-07-28-agentic-engineering-10x-developer]].
|
||||
- Built a club food-ordering app from a menu photo in 3 × 5-minute iterations; encoded a 20-person club's ordering process in ~2 hours of phone typing.
|
||||
- Forked the diff viewer **hunk** and had AMP add a Gruvbox theme + sidebar file-checkoff in two minutes of agent time; never upstreamed.
|
||||
- Shipped a change to production live during the podcast recording.
|
||||
|
||||
## Related Pages
|
||||
|
||||
- Tools/orgs: [[amp]]
|
||||
- Concepts: [[shedding-weight]], [[build-for-the-agent-not-the-human]], [[emacsification-of-software]], [[explosion-of-internal-software]], [[async-by-default]], [[code-as-throwaway]], [[context-as-scarce-resource]], [[product-ownership]]
|
||||
- Compare: [[theo-browne]] (nearest ally — same slop-is-human, same code-is-cheap stance), [[konstantin]] and [[allie-miller]] (both build the skills layer he skips), [[sebastian]] (the enterprise reality that resists "kill your process")
|
||||
|
||||
## Contradictions / Uncertainty
|
||||
|
||||
- **The skills rejection.** "No custom slash commands, no skills, no MCP servers" is a direct counter to the vault's machine-side spine ([[skills-as-memory]], [[evolution-of-agent-tooling]]). Unresolved; likely scoped to his situation, but he does not scope it himself. Status: tentative.
|
||||
- **Model choice doesn't matter.** He says stop tuning between models; [[eugene]] deliberately runs 4.7 over 4.8 for over-proactivity ([[leave-less-room-for-imagination]]). Status: tentative.
|
||||
- The 99%-AI-written figure and the team poll are self-reported from inside a company that sells an agent. Status: tentative.
|
||||
- "Local dev is going away" is a prediction from someone selling remote sandboxes.
|
||||
- **The remix/internal-software predictions now have a sourced counter.** [[2026-07-29-what-if-we-vibe-code-it]] argues the cost of software is [[maintenance-is-the-real-cost|maintenance, not writing]], and offers an observed reversal (in-house Jira clone → back to Linear in four months). His club app passes that source's build-vs-buy checklist; his "teams will remix Riverside" prediction is exactly what the checklist rejects. Status: tentative on both sides — one anecdote against one prediction.
|
||||
|
||||
## Next Questions
|
||||
|
||||
- Would he still skip skills if he worked across many unrelated codebases, or as a non-engineer with no codebase to encode context into?
|
||||
- What is actually in AMP's `AGENTS.md`, and how is it maintained? That file carries the entire load his setup places on it.
|
||||
125
wiki/lint-reports/2026-07-28-lint.md
Normal file
125
wiki/lint-reports/2026-07-28-lint.md
Normal file
@@ -0,0 +1,125 @@
|
||||
# Lint Report — 2026-07-28
|
||||
|
||||
#lint-report
|
||||
|
||||
First lint pass on this vault. Scope: all 41 pages in `wiki/` plus `index.md`, checked against the operational contract in `CLAUDE.md`.
|
||||
|
||||
**Vault size at time of check:** 10 sources · 24 concepts · 14 entities · 4 queries · 1 comparison · 1 timeline · 1 overview.
|
||||
|
||||
**Headline:** structurally the vault is in good shape — zero broken links, zero orphans, zero template violations, zero tag errors. The real defects are all *staleness of synthesis*: five references to files that moved, four contradictions recorded on only one of the two pages they concern, and two synthesis pages that predate the last two ingests. Twelve findings; **nine fixed in this pass**, three left as recommendations because they are scope decisions rather than defects.
|
||||
|
||||
---
|
||||
|
||||
## 1. Clean — verified, no action
|
||||
|
||||
| Check | Result |
|
||||
|---|---|
|
||||
| Page-type tags present, correct for folder, on line 3 | **41/41 pass** |
|
||||
| H1 heading on line 1 | **41/41 pass** |
|
||||
| Source template sections (6 required) | **10/10 complete** |
|
||||
| Entity/concept template sections (6 required) | **38/38 complete** |
|
||||
| Evidence section cites ≥1 `wiki/sources/*` page | **38/38 pass** |
|
||||
| Broken `[[wiki links]]` | **0** |
|
||||
| Pages with zero outbound links | **0** |
|
||||
| Strict orphans (zero inbound) | **0** |
|
||||
| `index.md` concept list ↔ `wiki/concepts/` files | **24/24 in sync, no drift** |
|
||||
| `raw/` paths referenced from wiki resolve | 5 failures — see L1 |
|
||||
|
||||
Link-graph health is good. Most-referenced pages: [[eugene]] (33 inbound), [[skills-as-memory]] (29), [[context-as-scarce-resource]] (27), [[claude-code]] (24), [[code-as-throwaway]] and [[harness]] (22 each). Source fan-out median ≈ 17 citing pages.
|
||||
|
||||
---
|
||||
|
||||
## 2. Fixed in this pass
|
||||
|
||||
### L1 — Stale `raw/` paths after the notes move · **fixed**
|
||||
The four webinar deliverable docs moved from `raw/sources/` to `raw/notes/` (commit `1361dd7`), but three wiki pages still pointed at the old location. Five references, all now corrected and reworded to say *authored deliverable*, not *not yet ingested* — the distinction the move was making.
|
||||
- `wiki/concepts/levels-of-ai-usage.md` → `raw/notes/Webinar script.md`
|
||||
- `wiki/queries/2026-07-22-webinar-theses.md` → three paths
|
||||
- `wiki/sources/2026-07-14-sebastian-eugene-interview.md` → `raw/notes/Ideas for webinar.md`
|
||||
|
||||
### L2 — Stale source count on [[claude-code]] · **fixed**
|
||||
Summary read "cited across all four ingested sources" — written when the vault had four. Now rewritten to state the actual situation, which is more useful than a number that will rot again: cited across most of the corpus, and used by every practitioner in it **except** [[thorsten-ball]], who runs [[amp]].
|
||||
|
||||
### L3 — Dead reference in [[overview]] open questions · **fixed**
|
||||
The question "should Ideas for webinar / **HR Contacts** / Webinar Plan / Webinar script be ingested?" named a file that does not exist in the vault. The 2026-07-21 ingest caught this and corrected `index.md`, but the fix never propagated to `overview.md`. The question is also now answered — those docs are authored deliverables in `raw/notes/`. Marked resolved, with the phantom file noted.
|
||||
|
||||
### L4–L7 — Contradictions recorded on only one side · **all four fixed**
|
||||
Rule 5 requires contradictions be recorded explicitly. Four were logged on one page but not on the page holding the opposing view, so a reader arriving from the other direction would see an uncontested claim.
|
||||
|
||||
| # | Contradiction | Was recorded on | Was missing from |
|
||||
|---|---|---|---|
|
||||
| L4 | Wide latitude vs tight specs | [[leave-less-room-for-imagination]] (×2) + overview | [[think-wider-not-bigger]] |
|
||||
| L5 | The skills dissent | [[skills-as-memory]], [[evolution-of-agent-tooling]], [[thorsten-ball]], overview | [[levels-of-ai-usage]] — whose *top rung* is the thing contested |
|
||||
| L6 | Memory as anti-feature | [[skills-as-memory]], [[allie-miller]] | [[personal-ai-operating-system]] — whose *layer 1* is the thing contested |
|
||||
| L7 | Skills vs RAG | [[context-as-scarce-resource]] | [[skills-as-memory]] — which asserts the winner in its Summary as settled |
|
||||
|
||||
L5 and L6 are the consequential ones: in both cases the page that *makes* the contested claim was the page not carrying the objection.
|
||||
|
||||
### L8 — [[2026-07-22-webinar-theses]] is two ingests out of date · **staleness note added**
|
||||
Synthesized from 7 sources; 10 now exist. Preserved rather than rewritten (Update Policy: no silent large rewrites), with a note recording two specific gaps:
|
||||
1. **Thesis 3 — "Skills are the new memory" — is load-bearing for the talk and now has a live counter-example absent from its own "Honest tensions" list.**
|
||||
2. Nothing from the last two ingests appears as a candidate: [[make-more-cheap-code]], [[shedding-weight]], and especially [[explosion-of-internal-software]], which is the corpus's strongest *outside* validation of thesis 5 ("you build it, one small tool at a time").
|
||||
|
||||
### L9 — [[theo-konstantin-allie]] predates Theo's second source and Thorsten · **staleness note added**
|
||||
Two specific problems, both noted on the page: its reading of Theo's position on code omits the verification discipline he later supplied; and its closing line — "None of the three directly contradicts another; the disagreements in this corpus are elsewhere" — now misleads, because the skills convergence it calls "the vault's strongest cross-source thread" is exactly what the newest source contradicts.
|
||||
|
||||
---
|
||||
|
||||
## 3. Open findings — recommendations, not defects
|
||||
|
||||
### L10 — "Taste" is the vault's largest uncovered concept · **recommend a page**
|
||||
Appears in **12 wiki pages / 17 occurrences**, including three entity pages and the vault's one-sentence through-line ("judgment, ownership, **taste**, and in-person relationships"). It is named as *the meta-skill* by [[allie-miller]] ("knowing what good looks like — you don't need to do the graphic design to judge whether the ad is good") and is [[thorsten-ball]]'s entire answer to the slop objection ("taste at AI speed" — 15 generated icon variants, one chosen by hand; "slop = lack of ideas, lack of playfulness"). [[theo-browne]] supplies the third leg via the ship/no-ship line.
|
||||
|
||||
It currently has no page, split across [[product-ownership]] and [[make-more-cheap-code]]. Given that it is one of four nouns in the through-line and the other three all have pages, this is the clearest coverage gap in the vault.
|
||||
|
||||
### L11 — Query pages are a weakly-linked class · **recommend backlinks**
|
||||
Durable Q&A outputs are not cited back from the concept pages they inform:
|
||||
|
||||
| Query page | Inbound (excl. index/overview) |
|
||||
|---|---|
|
||||
| [[2026-07-22-webinar-theses]] | **0** |
|
||||
| [[2026-07-14-best-first-skill-for-beginner]] | 1 |
|
||||
| [[2026-07-14-network-from-standing-start]] | 2 |
|
||||
| [[2026-07-24-non-engineer-throwaway-verification]] | 2 |
|
||||
|
||||
The theses page is effectively orphaned — reachable only from the catalog — despite being the most directly webinar-relevant page in the vault. Rule 7 asks for at least one inbound link; it has none from any content page.
|
||||
|
||||
### L12 — [[2026-07-22-ai-is-stupid]] is thinly integrated · **watch**
|
||||
Cited by 2 pages against a source median of ~17. Consistent with the 2026-07-22 ingest note that it *restates* the machine-side spine rather than adding to it — so this may be correct rather than a defect. Worth revisiting only if it stays at 2 after the next ingest.
|
||||
|
||||
### L13 — Possible future merge · **watch**
|
||||
[[emacsification-of-software]] and [[explosion-of-internal-software]] were created in the same ingest, from the same source, as "sibling mechanisms" of one shift (software becomes personal — by remixing vs by building). Both currently carry distinct evidence and distinct open questions. If neither gains independent support from a second source by the next lint, they should merge.
|
||||
|
||||
Also considered and **rejected** as a new page: *trust calibration / what to verify*. It touches 15 pages, but is substantively covered by [[make-more-cheap-code]] (tier discipline), [[code-as-throwaway]] (the auth/payments carve-out) and [[seniority-and-the-junior-squeeze]] (the "read what you approve" habit). Creating it would duplicate rather than consolidate.
|
||||
|
||||
---
|
||||
|
||||
## 4. Contradiction inventory
|
||||
|
||||
The vault's live disagreements after this pass, all now recorded on both sides:
|
||||
|
||||
1. **Skills as memory vs no skills at all** — Konstantin/Allie/Eugene vs [[thorsten-ball]]. Three competing readings on [[skills-as-memory]]; unresolved, and the evidential asymmetry favours the dissent. The most consequential open question in the vault, because the webinar's central promise rests on it.
|
||||
2. **Personal vs company-managed vs vendor-managed harness** — [[eugene]] vs [[sebastian]] vs [[amp]].
|
||||
3. **Built-in memory as anti-feature** — Eugene vs Allie's untroubled persistent context docs.
|
||||
4. **Tight specs vs wide latitude** — [[leave-less-room-for-imagination]] vs [[think-wider-not-bigger]].
|
||||
5. **Diff summaries as sufficient review vs invisible drift** — Theo/Dax vs Eugene.
|
||||
6. **Model choice as a real lever vs a distraction** — Eugene (4.7 over 4.8) vs Thorsten (stop tuning).
|
||||
7. **Local consolidated workspace vs local dev disappearing** — Eugene vs Thorsten.
|
||||
8. **Skills vs RAG as the context mechanism** — Konstantin vs the business-facing short.
|
||||
9. **Online vs in-person networking** — Eugene vs Sebastian.
|
||||
|
||||
Items 6 and 7 arrived with the newest source and were recorded at ingest; 1, 3, 4 and 8 were the ones needing reciprocal entries in this pass.
|
||||
|
||||
---
|
||||
|
||||
## 5. Recommended next actions
|
||||
|
||||
1. **Refresh [[2026-07-22-webinar-theses]]** against all 10 sources — highest value, since it is the page closest to the actual deliverable and it is both stale and orphaned. Fixes L8 and most of L11 in one operation.
|
||||
2. **Create a `taste` concept page** (L10), consolidating Allie's meta-skill, Thorsten's taste-at-AI-speed, and Theo's ship/no-ship discipline.
|
||||
3. **Extend or supersede [[theo-konstantin-allie]]** with Thorsten as a fourth lens or explicit dissent column (L9).
|
||||
4. Consider the falsification test already flagged on [[skills-as-memory]]: same task, with and without a skill, in a non-engineer's hands. It is the cheapest experiment that would move contradiction #1, and nobody in the corpus has run it.
|
||||
|
||||
## Related Pages
|
||||
|
||||
- [[overview]] · [[index]]
|
||||
- Pages amended by this lint: [[claude-code]], [[levels-of-ai-usage]], [[think-wider-not-bigger]], [[personal-ai-operating-system]], [[skills-as-memory]], [[2026-07-22-webinar-theses]], [[theo-konstantin-allie]], [[2026-07-14-sebastian-eugene-interview]]
|
||||
@@ -10,7 +10,7 @@ A high-signal personal knowledge base. `raw/` holds immutable source materials;
|
||||
|
||||
## The through-line
|
||||
|
||||
Across nine sources — three talks/videos (two of them Theo's), five interviews, and a business-facing short — one spine recurs:
|
||||
Across thirteen sources — six talks/videos/interviews from practitioners (two of them Theo's), five interviews conducted for this project, a business-facing short, and one quantitative outside study ([[swepr|Stanford SWEPR]]) — 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.**
|
||||
|
||||
@@ -19,28 +19,34 @@ 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 frontier side** — what it looks like at the far end, from [[thorsten-ball]] at [[amp]] (99% of their code AI-written): [[shedding-weight|shed weight]] by deleting every process that only existed because humans were the bottleneck; [[build-for-the-agent-not-the-human|build for the agent, not the human]]; work [[async-by-default|async by default]] in remote sandboxes and ask for proof rather than claims. His two mechanisms for software becoming *personal* — [[emacsification-of-software|remixing what exists]] and [[explosion-of-internal-software|building what never did]] — are the corpus's strongest outside validation of the webinar's own thesis, "little tools you make for yourself." He is also its sharpest dissenter: he uses **no skills, no MCP, no slash commands**. Both mechanisms now carry a sourced counterweight — [[maintenance-is-the-real-cost]]: writing code was never the bottleneck, maintenance is, and an internal service is a second business. The reconciliation is a threshold, not a winner: tiny personal tools pass, replacing your Jira does not.
|
||||
- **The adoption side** — what goes wrong when organizations try this, from [[nikolai-sheiko]]'s multi-company casework ([[2026-07-30-rakes-in-ai-sdlc-adoption]]): the SDLC collapses *around the humans* — [[review-is-the-new-bottleneck|review becomes the bottleneck]] and volume metrics (LoC, PRs) go anti-informative, so measure **completed tasks without rework**; the developer's job flips from CPU-bound coding to [[developer-as-agent-manager|IO-bound agent management]]; and the winning company move is not custom AI development but installing and *evolving* a standard harness ([[enterprise-ai-reality]]) — with skills grown by walking the agent through real tasks and verified by a context-free subagent ([[solve-first-then-skillify]]).
|
||||
- **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.
|
||||
- **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 — Thorsten's version is the bluntest: **the dominant variable in output quality is the information you put in**, not the model or the effort level. 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**. Slop is a human problem, not an AI defect (Theo ↔ Thorsten, from verification discipline and from taste respectively). Software becomes personal — "little tools you make for yourself" (Eugene's webinar arc ↔ Thorsten's club app and bespoke forks ↔ Allie's personal OS). And the corpus's central *stakes* claim now has outside measurement: [[2026-07-30-stanford-swepr-widening-gap|Stanford SWEPR]] finds the productivity gap between AI-mastering and lagging teams grew 4.8% → 19% (4×) from April 2023 to July 2025 — Allie's prediction, measured; the same study's codebase-size finding independently supports [[context-as-scarce-resource|context as the binding constraint]]. [[2026-07-30-rakes-in-ai-sdlc-adoption|Sheiko]] cites that same Stanford chart as his stakes slide and lands on the spine independently — "companies no longer need custom AI development, install Claude Code or Codex and configure it" is harness-over-model as a service playbook, and his codebase-stores-context prescription converges with Thorsten's from the opposite direction. His review-bottleneck casework (+1% net despite more PRs) is SWEPR's +91%-review-time finding told anecdotally.
|
||||
- **Diverge:** personal vs company-managed vs vendor-managed harness ([[eugene]] vs [[sebastian]] vs [[amp]]); online vs in-person networking (Eugene/Sebastian); 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); model choice as a real lever (Eugene runs 4.7 over 4.8) vs a distraction past the frontier (Thorsten); local consolidated workspace (Eugene) vs local dev disappearing into remote sandboxes (Thorsten); build-your-own-tools ([[thorsten-ball]], the webinar arc) vs [[maintenance-is-the-real-cost|buy anything that needs ongoing support]] (the vibe-coding video, with the corpus's only observed reversal: an in-house Jira clone abandoned for Linear in four months); permit opting out of the agent-manager switch ([[nikolai-sheiko]] — "don't force everyone") vs the gap is irreversible and compounding ([[allie-miller]], [[swepr|Stanford]]) — see [[developer-as-agent-manager]]. These live under "Contradictions" on the relevant pages.
|
||||
- **The one that matters most for the webinar:** [[thorsten-ball]] runs a 99%-AI-written codebase with **no skills, no MCP servers and no slash commands** — his context lives in the codebase and `AGENTS.md`. That is the corpus's first credible rejection of the mechanism the webinar's central promise rests on. Three readings (situational / premature abstraction / same thing under another name) are logged on [[skills-as-memory]]; none is settled. The evidential asymmetry that favoured him narrowed on 2026-07-30: [[nikolai-sheiko]] is a second practitioner voice on the pro-skills side — his "Agentic Evolution" (guided tasks → agent writes the manual → context-free-subagent verification) is the corpus's first described *test* of a skill, though his cases are anonymous anecdotes where Thorsten's is first-hand daily practice at scale.
|
||||
|
||||
## 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]]
|
||||
- **Sources (13):** [[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)]] · [[2026-07-28-agentic-engineering-10x-developer|Thorsten Ball (agentic engineering)]] · [[2026-07-29-what-if-we-vibe-code-it|"What if we vibe-code it?" (maintenance trap)]] · [[2026-07-30-stanford-swepr-widening-gap|Stanford SWEPR (widening gap)]] · [[2026-07-30-rakes-in-ai-sdlc-adoption|Nikolai Sheiko (rakes in SDLC adoption)]]
|
||||
- **People:** [[theo-browne]] · [[allie-miller]] · [[sebastian]] · [[eugene]] · [[konstantin]] · [[nina]] · [[yulia]] · [[larysa]] · [[thorsten-ball]] · [[nikolai-sheiko]]
|
||||
- **Tools/orgs:** [[claude-code]] · [[amp]] · [[hermes]] · [[virtido]] · [[inspectron]] · [[swepr]]
|
||||
- **Concepts:** see the through-line above (27 pages) · **Timeline:** [[ai-agent-evolution]] · **Comparison:** [[theo-konstantin-allie]]
|
||||
|
||||
## 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.)
|
||||
- ~~Should the webinar docs be ingested to connect the corpus to the deliverable?~~ **Resolved 2026-07-28:** they live in `raw/notes/` as authored deliverables, not sources, and are cited as raw where used. (`HR Contacts.md`, named in the original question, does not exist in the vault.)
|
||||
- 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.
|
||||
- **Are skills necessary at all, or a 2025 scaffold?** [[thorsten-ball]] ships at the frontier without them. The corpus has never run the cheap test that would separate the readings — the same task, with and without a skill, in a non-engineer's hands. See [[skills-as-memory]].
|
||||
- Who pays for the **token budget** at *fleet* scale? *(Scoped 2026-07-28.)* For individuals the answer is settled and unremarkable — one subscription; the corpus's heaviest users ([[eugene]], 7 parallel agents on a $200 plan; [[allie-miller]], ~100 agents) report no ceiling, and the AI divide stays a **skill** gap. The open question is metered/fleet pricing and enterprise allocation — plus whether [[eugene]]'s price-*rise* prediction reopens it. See [[enterprise-ai-reality]].
|
||||
- If forms and admin panels die ([[build-for-the-agent-not-the-human]]), what does a non-technical person actually operate? "Prompt the agent" presumes exactly the competence the HR interviews identify as the bottleneck.
|
||||
|
||||
@@ -2,6 +2,14 @@
|
||||
|
||||
#query
|
||||
|
||||
> **⚠️ SUPERSEDED 2026-07-28 by [[2026-07-28-webinar-theses]].** Use that page. This one is preserved as the 2026-07-22 state of thinking (7 sources).
|
||||
>
|
||||
> What the refresh changed, in short:
|
||||
> - **Thesis 3 ("Skills are the new memory") was reframed** to *context you author beats context that's inferred* — the v1 wording has a live counter-example ([[thorsten-ball]] ships 99%-AI-written code with no skills, no MCP, no slash commands) and the reframe is what all four practitioners actually agree on. See [[skills-as-memory]] for the three competing readings.
|
||||
> - **Thesis 5 ("you build it, one small tool at a time") went from assertion to evidenced** via [[explosion-of-internal-software]].
|
||||
> - **Three theses added** that this set had no source for: verification / ask-for-checks, shedding weight, and ask-for-15-options.
|
||||
> - Flagged by [[2026-07-28-lint]] as two ingests stale and effectively orphaned; the refresh is the fix.
|
||||
|
||||
## 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)
|
||||
@@ -45,7 +53,7 @@ Grouped by the role they play in the talk. Each thesis is one sentence you could
|
||||
## 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`
|
||||
- Raw deliverables (authored, read directly; since moved to `raw/notes/`): `raw/notes/Webinar Plan - From Chat Box to Your Own OS.md`, `raw/notes/Webinar script.md` (script ladder: Chat box → ReAct → Tools → Memory → Skills → Process → OS), `raw/notes/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
|
||||
|
||||
@@ -2,6 +2,8 @@
|
||||
|
||||
#query
|
||||
|
||||
> Carried forward as thesis **T6a** in [[2026-07-28-webinar-theses]] — "ask for checks, not just work." That refresh flags the absence of any verification beat in the current webinar script as the talk's biggest gap, since "can I trust it?" is the audience's first question.
|
||||
|
||||
**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)
|
||||
|
||||
193
wiki/queries/2026-07-28-verification-beat-design.md
Normal file
193
wiki/queries/2026-07-28-verification-beat-design.md
Normal file
@@ -0,0 +1,193 @@
|
||||
# Designing the Webinar's Verification Beat
|
||||
|
||||
#query
|
||||
|
||||
## Question
|
||||
|
||||
"What are your suggestions for the verification beat? What can we add?" — following [[2026-07-28-webinar-theses]], which flagged the absence of any verification moment as the current script's biggest gap. (2026-07-28)
|
||||
|
||||
## Answer — the headline
|
||||
|
||||
**Make it one beat that closes both gaps, not two.** The refresh listed two holes in the script: no verification beat, and no "what stays yours" beat. They are the same beat. Verification is *precisely* where the human's remaining job lives ([[product-ownership]]), so a single moment can answer "can I trust it?" and "then what's left for me?" at once. In a 30-minute talk that matters — two gaps, one insertion.
|
||||
|
||||
The frame that makes it land for non-engineers, from [[2026-07-24-non-engineer-throwaway-verification]]:
|
||||
|
||||
> **You don't verify by reading everything. You verify by making a second, cheap, disposable agent try to break the first one.**
|
||||
> Generated *checks*, not generated *content*.
|
||||
|
||||
And the honest bottom line that becomes the "what stays yours" half:
|
||||
|
||||
> A checker catches **drift**. It cannot catch a **wrong rule**. Mechanical correctness is delegable; judgment is not.
|
||||
|
||||
## Placement — where the anxiety actually peaks
|
||||
|
||||
The script's emotional arc is capability rising as the human recedes: *I do everything* → *I click a button*. The audience's unease peaks at one exact line in the **Process** station:
|
||||
|
||||
> "I take my hands off the keyboard." … "Nobody is typing. It just... runs."
|
||||
|
||||
That is the moment to answer it — not earlier (they don't feel it yet) and not in Q&A (too late). Recommended split:
|
||||
|
||||
| Where | What | Cost |
|
||||
|---|---|---|
|
||||
| **Skills station** | Introduce the checker skill — the second species of skill | ~45–60 sec |
|
||||
| **Process station** | Cash it in: the unattended process checks itself | ~20 sec (reuses an existing reveal) |
|
||||
| **Closing arc** | The judgment half — what a checker *can't* do | ~30 sec, also fills gap #2 |
|
||||
|
||||
---
|
||||
|
||||
## Option 1 — Minimal: one line in an artifact you already show *(≈15 seconds)*
|
||||
|
||||
The Process station already reveals the prompt the shell wrote for its worker ("the AI wrote... a prompt. For another AI."). Add one visible line to that prompt:
|
||||
|
||||
```
|
||||
After moving the cube, re-read the shelf state and confirm it matches the rule.
|
||||
If it doesn't, report the mismatch instead of reporting success.
|
||||
```
|
||||
|
||||
Then one spoken line:
|
||||
|
||||
> Look at the last instruction it gave itself.
|
||||
>
|
||||
> "Check your own work — and if it's wrong, *say so* instead of saying done."
|
||||
>
|
||||
> It didn't just delegate the job. It delegated the *checking*.
|
||||
|
||||
**Why this is the cheapest possible win:** the reveal already happens, the artifact is already on screen, and you add zero demo steps. If time is tight, do only this.
|
||||
|
||||
---
|
||||
|
||||
## Option 2 — Recommended: the checker skill *(≈60–90 seconds)*
|
||||
|
||||
Slots into the **Skills** station, immediately after `"save what we just did as a skill"`. The apparatus needed already exists: cube, shelves, weather widget, Override slider.
|
||||
|
||||
**Draft copy, in the script's voice:**
|
||||
|
||||
> So now I've got a skill that does the job.
|
||||
>
|
||||
> But here's the question you're all actually asking.
|
||||
>
|
||||
> If I'm not watching... how do I know it did it *right*?
|
||||
>
|
||||
> Let's give it a second skill.
|
||||
>
|
||||
> "save a skill that checks the first one — read the rule, read the weather, look at where the cube actually is, and tell me if they disagree"
|
||||
>
|
||||
> {AI writes `check-weather-based-movement/SKILL.md`}
|
||||
>
|
||||
> Two skills now. One does the job.
|
||||
>
|
||||
> One does nothing *but* look for the job being done wrong.
|
||||
>
|
||||
> Now watch — I'm going to break it on purpose.
|
||||
>
|
||||
> {drag the cube to the wrong shelf by hand}
|
||||
>
|
||||
> "run the check"
|
||||
>
|
||||
> {AI reports: rule says top shelf, cube is on bottom — mismatch}
|
||||
>
|
||||
> It caught it.
|
||||
>
|
||||
> And notice what that check cost me.
|
||||
>
|
||||
> One sentence. No code. It's a folder with a note in it — same as the first one.
|
||||
>
|
||||
> That's the trick nobody tells you about working with AI:
|
||||
>
|
||||
> you don't check the work by reading all of it.
|
||||
>
|
||||
> You check it by asking for something *cheap* whose only job is to find the mistake.
|
||||
|
||||
**Why this specific demo works:** breaking it by hand is visible, instant, and unfakeable to a live audience — they see the cube in the wrong place *before* the agent says so. It also introduces the second species of skill (producers and checkers), which is a genuine corpus finding from [[2026-07-24-non-engineer-throwaway-verification]] and costs no new level.
|
||||
|
||||
**Audience translation to say right after** — the demo is a cube, the takeaway must not be:
|
||||
|
||||
> Same move, your work:
|
||||
> "Read this job description as if you were a candidate who'd be put off by it — what did you see?"
|
||||
> "Read this shortlist and argue *against* my top pick."
|
||||
>
|
||||
> That's not asking it to do the work. That's asking it to attack the work.
|
||||
|
||||
---
|
||||
|
||||
## Option 3 — The ambiguity moment: you already wrote the perfect example *(≈30 seconds, standalone)*
|
||||
|
||||
The Process station's goal line is:
|
||||
|
||||
> "keep the cube on the **right shelf**: below 20 — top, above 20 — bottom. continuously."
|
||||
|
||||
**"The right shelf"** is genuinely ambiguous — *correct* shelf, or the shelf on the *right*? The colon disambiguates it, so the script is safe as written. Which means you can deliberately show the unsafe version first:
|
||||
|
||||
> Before I give it the real goal — watch this.
|
||||
>
|
||||
> {type only: "keep the cube on the right shelf"}
|
||||
>
|
||||
> {agent moves the cube to the right-hand shelf}
|
||||
>
|
||||
> That's not what I meant.
|
||||
>
|
||||
> I meant the *correct* shelf. It heard the shelf on the *right*.
|
||||
>
|
||||
> And here's the part that costs you: it didn't ask. It didn't hesitate. It just confidently did the wrong thing.
|
||||
>
|
||||
> {now type the full goal with the rule spelled out}
|
||||
>
|
||||
> Every gap you leave, it fills. And it fills it *silently*.
|
||||
|
||||
This is the cheapest possible dramatization of [[leave-less-room-for-imagination]] — Eugene's sharpest claim, currently thesis T12 with no demo — and it doubles as verification motivation (*this* is what a checker catches). It costs one extra typed line and one cube movement.
|
||||
|
||||
It also inverts cleanly, which is the durable insight from [[2026-07-24-non-engineer-throwaway-verification]]: **a fresh agent's misreading is a free ambiguity detector.** Before sending a brief to a human, hand it to a zero-context agent and ask what it thinks you meant.
|
||||
|
||||
---
|
||||
|
||||
## The closing half — what a checker *can't* do *(fills gap #2)*
|
||||
|
||||
The script's closing arc is currently all harness ("the model never changed… that's the harness"). Add the human half immediately before "You don't buy it. You build it":
|
||||
|
||||
> One last thing — because I don't want to oversell this.
|
||||
>
|
||||
> That checker I wrote? It was written by the same AI it's checking.
|
||||
>
|
||||
> It'll catch the cube on the wrong shelf. Every time.
|
||||
>
|
||||
> What it will *never* catch... is Marcus's rule being wrong in the first place.
|
||||
>
|
||||
> If twenty degrees was the wrong number, both agents agree, confidently, forever.
|
||||
>
|
||||
> So here's the split, and it's the honest one:
|
||||
>
|
||||
> the machine checks whether the thing was done right.
|
||||
>
|
||||
> You check whether it was the right thing.
|
||||
>
|
||||
> That part doesn't get automated. That part is why you're still in the room.
|
||||
|
||||
**Why this is worth the 30 seconds:** it is the strongest available answer to "will this replace me," it is honest rather than reassuring, and it converts the talk's ending from *capability* to *the audience's own value* — which is what an inspire talk should land on.
|
||||
|
||||
## Recommended combination
|
||||
|
||||
If you add **one** thing: Option 1 (15 sec, free).
|
||||
If you add **one minute**: Option 2 + the closing half.
|
||||
**Best value for ~2 minutes total:** Option 3 at Process → Option 2 at Skills → closing half. Option 3 creates the fear, Option 2 resolves it, the closing bounds the resolution honestly.
|
||||
|
||||
Sequencing note: Option 3 sits *later* in the script than Option 2. If you use both, move the ambiguity moment earlier — into the Skills station just before the checker — so the problem precedes its solution.
|
||||
|
||||
## Evidence trail
|
||||
|
||||
- [[2026-07-24-non-engineer-throwaway-verification]] — the non-engineer analog: generated checks not content; checker skills as the second species; fresh-agent misread tests; the tier-D-stays-human caveat
|
||||
- [[make-more-cheap-code]] — the engineer form (100:1 slop-to-ship), "have AI review before humans do," reading costs attention
|
||||
- [[async-by-default]] — "you're async anyway, ask for proof," and the logged limit: *proof produced by the thing being checked is evidence, not verification*
|
||||
- [[leave-less-room-for-imagination]] — drift's damage is what you don't notice; the source of Option 3
|
||||
- [[product-ownership]] — verification as the human's remaining craft; taste as the meta-skill
|
||||
- [[2026-07-28-webinar-theses]] — T6a, and the two gaps this design closes
|
||||
- Script state: `raw/notes/Webinar script.md` (Process and Skills stations, closing arc)
|
||||
|
||||
## Open questions / honest caveats
|
||||
|
||||
- **A checker written by the agent, checking the agent, is not independent.** It catches mechanical drift, not shared misunderstanding. The closing half says this out loud rather than hiding it — but if a technical audience member pushes, the real answer is that independence comes from *the human choosing the rule*, not from a second model.
|
||||
- **Nina's finding is a standing counterweight:** transcript beat summary in her workflow ([[2026-07-14-nina-interview]]). A checker that reports "looks fine" is a summary. Don't let the beat imply reading is now optional — Theo's tier discipline is that some things still get read line by line.
|
||||
- Untested: none of this has been run in front of a non-engineer audience. The cube demo may make verification feel mechanical in a way that doesn't transfer to judgment work — which is exactly why the audience-translation lines after Option 2 are load-bearing rather than optional.
|
||||
|
||||
## Changed existing pages?
|
||||
|
||||
No concept or entity pages changed — this is design synthesis on top of existing pages. `index.md` and `log.md` updated; [[2026-07-28-webinar-theses]] links here from T6a.
|
||||
157
wiki/queries/2026-07-28-webinar-theses.md
Normal file
157
wiki/queries/2026-07-28-webinar-theses.md
Normal file
@@ -0,0 +1,157 @@
|
||||
# Webinar Theses v2 — From Chat Box to Your Own Agentic OS
|
||||
|
||||
#query
|
||||
|
||||
Supersedes [[2026-07-22-webinar-theses]] (7 sources). This set is synthesized from all **10** sources plus the current deliverable state in `raw/notes/` (`Webinar script.md`, `Webinar Plan - From Chat Box to Your Own OS.md`, `my theses.md`).
|
||||
|
||||
## Question
|
||||
|
||||
"Refresh the webinar theses" — restate the candidate theses for the talk *from chat box to your own agentic operating system*, now that [[2026-07-24-youre-reading-way-too-much-code]] and [[2026-07-28-agentic-engineering-10x-developer]] have been ingested. (2026-07-28)
|
||||
|
||||
## What changed since v1
|
||||
|
||||
| | Change |
|
||||
|---|---|
|
||||
| **Strengthened** | Thesis 1 (harness not model) — Thorsten states the strongest form: *the dominant variable in output quality is the information you put in*, and he tells people to **stop tuning model choice**. This is now the best-evidenced claim in the vault and it is already the script's literal closing argument. |
|
||||
| **Upgraded from assertion to evidence** | Thesis 5 (you build it, one small tool at a time) — [[explosion-of-internal-software]] supplies an outside, *non-engineer-shaped* case: a 20-person social club's ordering process encoded in **~2 hours of phone typing**, from a photo of a menu. The talk's least-provable claim is now its best-evidenced one. |
|
||||
| **Weakened — needs reframing** | Thesis 3 (skills are the new memory) — a frontier practitioner ships 99%-AI-written code with **no skills, no MCP, no slash commands**. See T3 below for the reframe that survives him. |
|
||||
| **New** | Three theses the earlier set had no source for: verification (T6a), shedding weight (T10), and variations-not-answers (T13a). |
|
||||
| **New honest caveat** | **Token budget** — Thorsten names it as one of two winner/loser variables. The talk currently promises a skill gap can be closed by effort; this says part of it is closed by spending. |
|
||||
|
||||
---
|
||||
|
||||
## The refreshed set
|
||||
|
||||
Grouped by the job each does in the talk. Bold = recommended for the 30-min cut.
|
||||
|
||||
> **Reading the numbers.** **T** = thesis; the numbers are stable handles so the theses can be referenced from other pages and in conversation ("T3 needs reframing") without re-quoting them. T1–T15 follow v1's order where the thesis survived, so a v1 number still points at roughly the same idea. A **letter suffix** (T6a, T13a) marks a thesis added in v2 next to its nearest relative rather than renumbering everything — T6a sits with T6 (both about where value goes when production is free), T13a with T13 (both method). Introduced in v2; v1 used plain 1–14.
|
||||
|
||||
### Spine — what the talk claims
|
||||
|
||||
**T1. The model isn't the product — the harness is.** *(strongest in the vault)*
|
||||
Same model at every station; only the harness around it grows. Two independent frontier voices now say the same thing: the harness *is* the difference ([[harness]]), and "the dominant variable in output quality is the information you put in, not the model or the effort level" ([[thorsten-ball]]). Corollary you can say out loud: **stop shopping for models.**
|
||||
— [[harness]], [[context-as-scarce-resource]] · script closing arc ("the model never changed")
|
||||
|
||||
**T2. A chat box is an app you open; an OS is a system that runs around you.**
|
||||
The rung ladder: stranger → doer → yours → teammate → knows you → always-on. Karpathy's framing (in the script's notes) is the same claim from outside: website → app you download → *self-contained, persistent, asynchronous entity working alongside teams*.
|
||||
— [[levels-of-ai-usage]], [[personal-ai-operating-system]] · Plan through-line
|
||||
|
||||
**T3. Context you *author* beats context that's *inferred*.** ⚠️ *reframed — see "The honest tension" below*
|
||||
The v1 form was "skills are the new memory." That form now has a live counter-example. This reframe is what **all four** practitioners actually agree on: Konstantin's skills, Allie's foundation docs, Eugene's anti-memory position ("a skill is a file you can read, edit, version and delete"), *and* Thorsten's `AGENTS.md` are all the same move — context a human wrote on purpose, beating context a system guessed. It keeps the script's Memory→Skills stations intact while surviving the dissent.
|
||||
— [[skills-as-memory]], [[personal-ai-operating-system]] · script Memory + Skills stations
|
||||
|
||||
**T4. Context is the scarce resource — every rung is a technique for spending it wisely.**
|
||||
Already dramatized in the script better than any slide could: *"the notebook is tiny. On purpose. Everything in it gets loaded into every single session — needed or not."* Then skills as two-stage loading: "the shelf can be huge — the desk stays clean."
|
||||
— [[context-as-scarce-resource]], [[evolution-of-agent-tooling]] · script Memory→Skills transition
|
||||
|
||||
**T5. You don't buy your OS — you build it, one small tool at a time.** *(now evidenced)*
|
||||
Tools made for exactly one person, in an evening, asked-for rather than written. The new outside evidence matters because it defuses the obvious objection ("sure, *you* can do that — you're technical"): Thorsten's example is a social club, a phone, and a photo of a menu, and the software it replaced was a spreadsheet.
|
||||
*(Scoped 2026-07-29: [[maintenance-is-the-real-cost]] adds the honest boundary — the cost of software is maintenance, not writing, and its pendulum case is a company abandoning its own Jira clone within four months. T5 survives because its examples pass that source's build-vs-buy checklist: tiny, personal, no users but you, no SLA. The claim is "little tools you make for yourself" — not "replace your vendors." Worth one sentence in the talk; it inoculates against the sharpest pushback a technical audience member could raise.)*
|
||||
— [[explosion-of-internal-software]], [[emacsification-of-software]], [[personal-ai-operating-system]] · script OS section ("I didn't write it — I *asked* for it")
|
||||
|
||||
### Stakes — why now
|
||||
|
||||
**T6. 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. Now has a hard datapoint: **99% of AMP's code is AI-written** — from inside a shipping company, not a demo.
|
||||
— [[code-as-throwaway]], [[product-ownership]]
|
||||
|
||||
**T6a. Verification is the new craft — and you get it by asking for checks, not just work.** *(new)*
|
||||
The audience's real objection is "can I trust it?", and the current script has no answer. There is one: generate disposable work whose only job is to check the work you keep. Engineer form: 100 lines of slop verifying every shipped line ([[make-more-cheap-code]]). Non-engineer form: fresh-agent misread tests, parallel interpretations, checker skills, synthetic-candidate simulations ([[2026-07-24-non-engineer-throwaway-verification]]). Delegated form: *"you're async anyway — ask the agent for proof"* ([[async-by-default]]).
|
||||
— **Designed in full at [[2026-07-28-verification-beat-design]]** (placement, drafted script copy, three options by cost).
|
||||
|
||||
**T7. 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 capability slots into a system that already knows them. *(Thorsten names **token budget** as a second winner/loser variable, but that is a claim about metered agent-fleet work; for this audience the budget is one consumer subscription — keep the thesis on the skill gap. See [[enterprise-ai-reality]].)*
|
||||
*(Measured 2026-07-30: this thesis is no longer prediction-only — Stanford SWEPR's 46-vs-46-team analysis shows the gap growing 4.8% → 19% (4×) from April 2023 to July 2025. One citable stage line: "Stanford measured it: the gap quadrupled in two years." See [[2026-07-30-stanford-swepr-widening-gap]]. **Added to the script's closing arc 2026-07-30** — T7 is now dramatized, upgrading it from Q&A material to an on-stage beat.)*
|
||||
— [[2026-07-14-gap-between-ai-users-irreversible]] · [[2026-07-30-stanford-swepr-widening-gap]]
|
||||
|
||||
**T8. 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]]
|
||||
|
||||
### Obstacles — what the audience actually hits
|
||||
|
||||
**T9. 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]], [[2026-07-14-yulia-interview]]
|
||||
|
||||
**T10. Ask which of your processes only exist because *you* were the bottleneck.** *(new)*
|
||||
Thorsten's knife, translated for a business audience: backlogs, status meetings, approval queues, the spreadsheet everyone re-keys. His test — *would this exist if agents had always been available?* His suggested exercise is a company-internal doc titled **"Software Is Dead — Now What?"**; the audience version is one honest list. Strong candidate for "Do this tonight."
|
||||
— [[shedding-weight]]
|
||||
|
||||
**T11. Even advanced users hit structural walls: no durable memory, integrations that dead-end, drift on loose specs.**
|
||||
— [[2026-07-21-larysa-interview]], [[integration-dead-ends]]
|
||||
|
||||
**T12. Leave less room for imagination.** Every gap in your instructions gets filled — invisibly. Now with a concrete, teachable structure instead of a principle: **set the standard → state intent → riff on the design → specify the process → set the constraints.** Thorsten's own gloss is the most quotable line for a non-technical crowd: *"This is how I would talk to a senior engineer. This is the Slack message I'd send."*
|
||||
— [[leave-less-room-for-imagination]]
|
||||
|
||||
### Method — what to do
|
||||
|
||||
**T13. Solve first, then skillify.** Don't design up front — solve the task once in conversation, then freeze the working recipe. (~3 messages of correction, or >5 tool calls, = it's skill time.) The script already demonstrates this exactly: *"save what we just did as a skill."*
|
||||
— [[solve-first-then-skillify]]
|
||||
|
||||
**T13a. Ask for fifteen options, not one answer.** *(new)*
|
||||
Generation is free, so the human's job moves from producing the artifact to **choosing among artifacts**. Thorsten's orb icon came from 15 AI-generated variants across 18 palettes; he picked one. This is the most immediately actionable thesis in the set for a non-technical audience — it needs no codebase, no skill, no setup — and it is the concrete form of "taste at AI speed."
|
||||
— [[make-more-cheap-code]], [[product-ownership]]
|
||||
|
||||
**T14. The assistant does the research; you do the judgment.** The Insights Collector meta-punchline: this talk was mined out of AI-processed interview notes.
|
||||
— script §3 / Plan §3
|
||||
|
||||
**T15. Walk in a week what took the industry three years.** One hour of foundation docs · one skill from your #1 recurring annoyance · one real file tonight.
|
||||
— [[levels-of-ai-usage]], [[personal-ai-operating-system]]
|
||||
|
||||
---
|
||||
|
||||
## The honest tension (Q&A ammo — read this before you present)
|
||||
|
||||
**Someone may ask whether skills are necessary at all.** They are right to. [[thorsten-ball]] runs a 99%-AI-written codebase with no skills, no MCP servers and no slash commands; his context lives in the codebase and a team-maintained `AGENTS.md`. The vault records three readings and settles none ([[skills-as-memory]]):
|
||||
|
||||
1. **Situational** — he works daily in one codebase he controls, so his context can live in the code. Your audience has no codebase; skills are how a non-engineer gets the same effect. *(Strongest answer, and honest, but note he never scopes the claim himself.)*
|
||||
2. **Premature abstraction** — skills are scaffolding for models that needed it, and a strong model plus a rich prompt may simply beat a skills library.
|
||||
3. **Same thing under another name** — his `AGENTS.md` and AMP's curated sub-agents *are* two-stage authored context; the dispute is over who curates, not whether curation is needed.
|
||||
|
||||
**The safe framing on stage is T3 as reframed above** — *authored beats inferred* — which is true under all three readings. Don't claim the skills mechanism is settled; it isn't, and the strongest counter-example is a frontier practitioner rather than a skeptic.
|
||||
|
||||
Other live tensions, if the room is technical:
|
||||
- Personal vs company-managed vs vendor-managed harness — [[enterprise-ai-reality]]
|
||||
- Built-in agent memory as anti-feature (Eugene) vs persistent context docs used happily (Allie) — [[skills-as-memory]]
|
||||
- Tight specs (T12) vs wide latitude — [[think-wider-not-bigger]]
|
||||
- Model choice as a real lever (Eugene runs 4.7 over 4.8) vs a distraction (Thorsten) — [[leave-less-room-for-imagination]]
|
||||
|
||||
---
|
||||
|
||||
## Recommended cut for the 30-min format
|
||||
|
||||
Seven load-bearing theses, mapped to script beats. Changed from v1: **T3 reframed**, **T6a added**, T12 promoted (it now has a teachable structure), T9 demoted to Q&A.
|
||||
|
||||
| # | Thesis | Script beat |
|
||||
|---|---|---|
|
||||
| T2 | App you open → system that runs around you | whole spine |
|
||||
| T4 | Context is the scarce resource | Memory → Skills transition (already scripted) |
|
||||
| T3 | Context you author beats context inferred | Memory + Skills stations |
|
||||
| T6a | Ask for checks, not just work | **currently missing — see gaps** |
|
||||
| T1 | The harness is the difference, not the model | closing arc (already scripted) |
|
||||
| T5 | You don't buy it — you build it | OS section (already scripted) |
|
||||
| T15 | Walk it in a week | "Do this tonight" |
|
||||
|
||||
## Gaps in the current script this refresh exposes
|
||||
|
||||
1. **No verification beat.** The script demonstrates capability at every station and never once shows the agent being *checked*. For an HR/BA audience whose first question is "can I trust it?", this is the biggest hole — and T6a fills it cheaply (one line in the Skills station: a second skill whose only job is to check the first).
|
||||
2. **No "what stays yours" beat.** T6 and T8 are in the thesis set and in the Plan (§4), but the script's closing arc is entirely about the harness. The talk currently ends on capability, not on the human.
|
||||
|
||||
*(A third gap — "the token-budget caveat is unsaid" — was proposed and **withdrawn 2026-07-28**. For this audience the budget is one consumer subscription, which is obvious and would land as a disclaimer. The corpus supports the withdrawal: [[eugene]] runs 7 parallel project-agents on a $200 plan and [[allie-miller]] runs ~100 agents, neither reporting a cost ceiling. Thorsten's token-budget variable describes metered agent-fleet work, not subscription use — see the scoping note on [[enterprise-ai-reality]].)*
|
||||
|
||||
## Evidence trail
|
||||
|
||||
- [[overview]] — through-line, agree/diverge map, vault-level open questions
|
||||
- [[2026-07-28-lint]] — flagged v1 as two ingests stale and effectively orphaned; this page is the fix
|
||||
- Sources: all 10, principally [[2026-07-28-agentic-engineering-10x-developer]], [[2026-07-24-youre-reading-way-too-much-code]], [[2026-07-14-skills-based-on-git]], [[2026-07-14-gap-between-ai-users-irreversible]], [[2026-07-21-larysa-interview]], [[2026-07-14-nina-interview]], [[2026-07-14-yulia-interview]], [[2026-07-14-sebastian-eugene-interview]]
|
||||
- Deliverable state (raw, authored): `raw/notes/Webinar script.md` (ladder: Chat box → ReAct → Tools → Memory → Skills → Process → OS), `raw/notes/Webinar Plan - From Chat Box to Your Own OS.md`, `raw/notes/my theses.md`
|
||||
|
||||
## Follow-up questions
|
||||
|
||||
- Does T6a earn a station, or one line inside the Skills station? (Recommend the latter — a checker skill is one sentence of demo and costs no new level.)
|
||||
- Should T10 ("which processes only exist because you were the bottleneck?") open the talk instead of closing it? It reframes the audience's own work before any capability is shown.
|
||||
- The falsification test still unrun: same task, with and without a skill, in a non-engineer's hands. It would settle the T3 tension and would itself make a strong demo.
|
||||
|
||||
## Changed existing pages?
|
||||
|
||||
Yes — [[2026-07-22-webinar-theses]] marked superseded and pointed here. No concept or entity pages changed; this is synthesis. `index.md` and `log.md` updated.
|
||||
55
wiki/queries/2026-07-30-stanford-widening-gap-source.md
Normal file
55
wiki/queries/2026-07-30-stanford-widening-gap-source.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# Stanford "widening gap" chart — original research located
|
||||
|
||||
#query
|
||||
|
||||
## Question asked
|
||||
|
||||
The user saved a chart screenshot (`raw/assets/G6g3O60bkAE05ZW.png`, filename pattern = X/Twitter image) of a Stanford slide titled *"Teams that master AI are accelerating their productivity gains, widening the gap with laggards"* and asked: **find the original Stanford research behind it.**
|
||||
|
||||
## Answer
|
||||
|
||||
The slide is from **Stanford's Software Engineering Productivity Research group (SWEPR)**, led by researcher **Yegor Denisov-Blanch**. Since 2022 the group has analyzed private Git repositories from 600+ companies and 120,000+ engineers, scoring every commit with an ML model trained to replicate a panel of human expert reviewers.
|
||||
|
||||
The specific chart is their **causal difference-in-differences analysis**: 46 teams that adopted AI, matched against 46 similar non-AI teams, with net productivity gains measured quarterly.
|
||||
|
||||
- **April 2023:** 4.8% gap between top-quartile and bottom-quartile AI adopters.
|
||||
- **July 2025:** 19% gap — a **4× increase** in ~2.25 years.
|
||||
- Slide footer: Stanford University / SWEPR; the specific slide (page 3) matches Denisov-Blanch's September 2025 AI Conference deck.
|
||||
|
||||
**Primary sources:**
|
||||
|
||||
- Research group home: <https://softwareengineeringproductivity.stanford.edu/> (AI Impact research, AI Practices Benchmark)
|
||||
- Talk the slide comes from: *"Will AI Replace Software Engineers?"*, AI Conference, Sept 2025 — [slide deck PDF](https://aiconference.com/wp-content/uploads/2025/09/Yegor-Denisov-Blanch-Will-AI-Replace-Software-Engineers_-.pptx.pdf)
|
||||
- Video walkthrough: [Can you prove AI ROI in Software Eng? (Stanford 120k Devs Study)](https://www.youtube.com/watch?v=JvosMkuNxF8)
|
||||
- Researcher site: <https://yegordb.com/>
|
||||
- Peer-reviewed methodology paper: [Predicting Expert Evaluations in Software Code Reviews](https://arxiv.org/pdf/2409.15152)
|
||||
|
||||
**Caveat (Status: tentative):** the 46-vs-46 difference-in-differences result itself has been presented via talks, webinars and decks — not (yet) a peer-reviewed paper. The peer-reviewed publications cover the *measurement methodology*, not this specific analysis.
|
||||
|
||||
**Surrounding findings from the same study** (useful nuance): AI raises developer productivity ~15–20% on average, with high variance — largest gains on greenfield/simple tasks in popular languages; AI can *decrease* net productivity in complex legacy codebases (rework eats the gains, ~2.6× increase in rework reported).
|
||||
|
||||
## Why this matters to the vault
|
||||
|
||||
This is the **first quantitative, external, longitudinal measurement** of a claim the corpus so far held only as practitioner assertion:
|
||||
|
||||
- [[2026-07-14-gap-between-ai-users-irreversible]] — [[allie-miller]]'s central prediction ("in 12 months the gap will be irreversible") is the same shape as this curve, asserted from advisory experience. Stanford now supplies measured team-level data pointing the same direction.
|
||||
- [[2026-07-28-webinar-theses]] — the "stakes" thesis group (irreversible gap) gains a citable number: *4.8% → 19%, 4× in about two years*. A Stanford chart is far stronger webinar ammunition than "an ex-Amazon AI leader predicts…".
|
||||
- The "AI can decrease productivity in complex legacy codebases" finding is honest-caveat material aligning with the vault's recorded tensions ([[maintenance-is-the-real-cost]], rework costs; [[make-more-cheap-code]]'s verification burden — cf. the study's 91% increase in PR review time).
|
||||
- The mechanism Stanford implies (teams that *master* AI compound, laggards stall) is the team-level twin of [[levels-of-ai-usage]] — the gap grows between rungs, not between haves and have-nots of licenses.
|
||||
|
||||
## Evidence trail
|
||||
|
||||
- Screenshot: `raw/assets/G6g3O60bkAE05ZW.png` (raw asset; likely captured from an X/Twitter post sharing the talk)
|
||||
- Web search + fetch of the SWEPR site and the AI Conference deck (2026-07-30); slide title, footer, chart annotations and page number all match the deck's era (data ends July 2025)
|
||||
|
||||
## Follow-up questions
|
||||
|
||||
- ~~Ingest-worthy?~~ **Done, same day:** the user authorized a new raw source file; the dossier lives at `raw/sources/Stanford SWEPR - AI and the widening productivity gap.md` and is ingested as [[2026-07-30-stanford-swepr-widening-gap]] — concept pages now cite it directly.
|
||||
- Does the webinar want the number? One line — "Stanford measured it: the gap 4×'d in two years" — would upgrade the stakes beat from prediction to measurement.
|
||||
- Watch for a peer-reviewed version of the difference-in-differences analysis; the claim's status upgrades from tentative when it lands.
|
||||
|
||||
## Whether this output changed existing pages
|
||||
|
||||
- [[2026-07-14-gap-between-ai-users-irreversible]] — added an external-corroboration pointer to this page under Connections.
|
||||
- `index.md` (Queries section) and `log.md` updated.
|
||||
- No concept pages changed — deliberately, since the underlying talk is not yet ingested as a source (citation policy: concept evidence should point at `wiki/sources/*`).
|
||||
@@ -1,45 +0,0 @@
|
||||
# Script coverage
|
||||
|
||||
#coverage
|
||||
|
||||
## Metadata
|
||||
|
||||
- **Script:** `raw/sources/Webinar script.md`
|
||||
- **Last synced:** 2026-07-28
|
||||
- **Stations:** Chat box · ReAct · Tools · Memory · Skills · Process · OS
|
||||
|
||||
## Coverage
|
||||
|
||||
| Concept | Status | Station | Pinned |
|
||||
|---|---|---|---|
|
||||
| [[harness]] | covered | Tools | |
|
||||
| [[evolution-of-agent-tooling]] | covered | Tools | |
|
||||
| [[skills-as-memory]] | covered | Skills | |
|
||||
| [[solve-first-then-skillify]] | covered | Skills | |
|
||||
| [[personal-ai-operating-system]] | covered | OS | |
|
||||
| [[context-as-scarce-resource]] | partial | Memory | |
|
||||
| [[agentic-loops]] | partial | Process | |
|
||||
| [[code-as-throwaway]] | partial | OS | |
|
||||
| [[levels-of-ai-usage]] | partial | all | |
|
||||
| [[integration-dead-ends]] | absent | — | |
|
||||
| [[leave-less-room-for-imagination]] | absent | — | |
|
||||
| [[product-ownership]] | absent | — | |
|
||||
| [[connections-as-moat]] | absent | — | |
|
||||
| [[network-from-a-standing-start]] | absent | — | |
|
||||
| [[seniority-and-the-junior-squeeze]] | absent | — | |
|
||||
| [[decoupling-identity-from-profession]] | absent | — | |
|
||||
| [[think-wider-not-bigger]] | absent | — | |
|
||||
| [[make-more-cheap-code]] | absent | — | |
|
||||
| [[enterprise-ai-reality]] | absent | — | |
|
||||
|
||||
## Notes
|
||||
|
||||
- Eight of the ten absent concepts are human-side or strategy-side, per the grouping in `index.md`. The script's spine is machine-side and it never reaches that material.
|
||||
- The remaining two absent concepts are machine-side: [[integration-dead-ends]] and [[leave-less-room-for-imagination]]. The script demonstrates the happy path, so it never reaches connector gating or spec ambiguity — the two ways the machine side fails in practice.
|
||||
- The `ReAct` station carries no wiki concept at all.
|
||||
- Set `Pinned` to `yes` on any row whose status is a deliberate decision. Sync will not touch it.
|
||||
|
||||
## Related Pages
|
||||
|
||||
- [[overview]]
|
||||
- `raw/sources/Webinar script.md`
|
||||
@@ -37,6 +37,7 @@
|
||||
- **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
|
||||
- **External corroboration:** [[2026-07-30-stanford-swepr-widening-gap]] — Stanford SWEPR's difference-in-differences study measured the gap between AI-mastering and lagging teams growing 4.8% → 19% (4×) from April 2023 to July 2025; the title claim's first measured, non-practitioner support. (Traced via [[2026-07-30-stanford-widening-gap-source]].)
|
||||
|
||||
## Open Questions
|
||||
|
||||
|
||||
@@ -35,7 +35,7 @@
|
||||
- **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).
|
||||
- **Raw reference (authored deliverable, not a source):** `raw/notes/Ideas for webinar.md` echoes many of these (harness, connections, "describe problems not waterfalls," Daniel, HR search demo).
|
||||
|
||||
## Open Questions
|
||||
|
||||
|
||||
62
wiki/sources/2026-07-28-agentic-engineering-10x-developer.md
Normal file
62
wiki/sources/2026-07-28-agentic-engineering-10x-developer.md
Normal file
@@ -0,0 +1,62 @@
|
||||
# Agentic Engineering, explained by a 10x developer — Thorsten Ball
|
||||
|
||||
#source
|
||||
|
||||
## Source Metadata
|
||||
|
||||
- **Date:** YouTube interview (publication date not stated in source), 42:33 — https://www.youtube.com/watch?v=FU5_kpTAVDo
|
||||
- **Raw path:** `raw/sources/Agentic Engineering, explained by a 10x developer.md`
|
||||
- **Source type:** podcast/video interview (conclusions doc)
|
||||
- **Speaker:** [[thorsten-ball]] — founding engineer at [[amp]] (Sourcegraph); author of *Writing an Interpreter in Go* / *Writing a Compiler in Go*
|
||||
- **Interviewer:** David Andre
|
||||
- **Ingestion date:** 2026-07-28
|
||||
|
||||
## Core Claims
|
||||
|
||||
- **The interesting variables moved.** Not "which model" or "how do I read every line," but: where does the information the agent needs live, how agent-friendly is your codebase/workflow, and what do you actually want to build. "The dominant variable in output quality is now the information you put in."
|
||||
- **Shed weight.** Kill anything that only made sense before agents — backlogs, CI that re-runs the agent's own tests, IDE extensions, admin panels, local dev. AMP kills its own features publicly and calls itself "AMP Frontier Corporation." See [[shedding-weight]].
|
||||
- **99% of AMP is written by AI**, and that is compatible with high taste. "Most of slop comes from humans not having good product. With AI they can just build trash products faster." Slop = lack of ideas and playfulness, not an AI defect.
|
||||
- **Build for the agent, not the human.** No human should fill out forms; anything a human can do on your site an agent should be able to do; ideally **bring your own agent**. See [[build-for-the-agent-not-the-human]].
|
||||
- **Software becomes bespoke** by two mechanisms: remixing existing software you don't upstream ([[emacsification-of-software]]) and building internal tools that used to be an Excel file ([[explosion-of-internal-software]]).
|
||||
- **Async by default.** An *orb* — a remote sandbox tied to one conversation — packages thread + agent + computation + diff in one shareable URL. Delegate, do something else, and **ask for proof** because you're waiting anyway. See [[async-by-default]].
|
||||
- **He uses no skills, no MCP servers, no custom slash commands.** The only thing that matters to him is where the agent gets its information: training data (lossy, stale) plus the context window (your prompt, the codebase, `AGENTS.md`). *This directly contradicts the vault's skills spine — logged below and on [[skills-as-memory]].*
|
||||
- **First-principles thinking is now the top skill.** "Everyone becomes an architect"; the value is seeing the workflow underneath the request and knowing solutions from other industries.
|
||||
|
||||
## Key Evidence / Details
|
||||
|
||||
- **Model choice:** once you have Fable 5 / GPT-5.6 Sol or equivalent, diminishing returns on which you pick, and on the effort level (medium vs high vs ultra). "If you're mad your model doesn't use camelCase, rethink your software engineering, not the model." AMP's default is medium.
|
||||
- **AMP's setup:** installed as a PWA from `ampcode.com`; a low/medium/high/ultra dial mapping to model + sub-agent choice; sub-agents **Oracle** (reviewer/advisor) and **Painter** (images); meta-agent **Puck** that controls other agents, spawns orbs, messages them, runs flows. GPT, Anthropic and GLM models all supported. Agent-to-agent communication shipped "last Friday."
|
||||
- **The hand-coding poll:** Thorsten polled the team with options 99%+, 90–99%, <90% — he didn't expect anyone under 80%. The one engineer who said "I still write a bunch by hand" landed at ~95% when pushed.
|
||||
- **Taste at AI speed:** he had AI generate **15 versions** of the orb icon (Braille characters, different styles, 18 palettes) and picked one. AMP news imagery came from turn-by-turn Midjourney with two colleagues while reading Moby Dick.
|
||||
- **The admin panel that dies:** he built a food-ordering app for a local club from a menu photo in 3 × 5-minute iterations; the agent also built an admin UI for prices and spelling. "I'm never going to open that. I'll just send another photo and say 'fix the pricing.'" A lot of admin UI existed only so that no code had to change.
|
||||
- **The remix:** forked a diff viewer called **hunk**, told AMP "add Gruvbox dark hard theme, add file-checkoff in sidebar, compile, drop it in `~/bin`" — two minutes of agent time, no reason to upstream.
|
||||
- **Internal software:** at his 20-person club he encoded the ordering process in ~2 hours of *phone typing*. Two variables separate winners from losers: knowing how to use agents, and **having the token budget** to do it.
|
||||
- **The printer anti-example:** asked to build an app so a tablet prints a paper receipt for the kitchen, he pushed back — "Why do you need a printer? Why not a second tablet?"
|
||||
- **Don't benchmark against the 1%:** Mitchell Hashimoto (Ghostty, GPU-accelerated terminal emulator) is cited in every online debate, but most software is CRUD, "MySQL and something-something," which agents handle fine.
|
||||
- **His prompt structure** (porting Puck to the CLI): set the standard ("look at how it's implemented in web UI") → state intent → riff on the design → give explicit process ("research, document, sit down and think, compile what you learned, then come up with a good idea") → set sub-agent economics ("Fable is expensive, it scares me — use GPT models for the implementation"). "This is how I would talk to a senior engineer. This is the Slack message I'd send."
|
||||
- **Velocity:** shipping velocity up in 4 weeks; designer Tim "never fixed so many paper cuts"; screenshot a bug → orb returns a fix → spot check → merge. A demo change was **shipped to production live during the podcast**.
|
||||
- **Predictions:** local dev goes away; model distinctions matter less ("a button with which you can spawn a John Carmack"); unclear what software survives remixability; infra margins get eaten (15+ sandbox providers racing to zero); everyone moves up a level of abstraction.
|
||||
|
||||
## Connections
|
||||
|
||||
- **Entities:** [[thorsten-ball]] (new) · [[amp]] (new) · [[claude-code]] (peer harness) · [[theo-browne]] (closest ally in the corpus)
|
||||
- **Concepts created:** [[shedding-weight]] · [[build-for-the-agent-not-the-human]] · [[emacsification-of-software]] · [[explosion-of-internal-software]] · [[async-by-default]]
|
||||
- **Concepts reinforced:** [[context-as-scarce-resource]] (information > tuning; the token-budget variable) · [[code-as-throwaway]] (99% AI-written at a real company) · [[make-more-cheap-code]] (15 icon variations; ask for proof) · [[product-ownership]] (first-principles thinking, everyone an architect) · [[harness]] (AMP as a second reference harness; Oracle/Painter/Puck) · [[seniority-and-the-junior-squeeze]] (what took 2–3 years to teach is now a 30-second output)
|
||||
- **Concepts contested:** [[skills-as-memory]] and [[evolution-of-agent-tooling]] (he skips the whole progression) · [[leave-less-room-for-imagination]] (model choice as a lever — he says stop tuning; Eugene selects 4.7 over 4.8)
|
||||
- **Related sources:** [[2026-07-24-youre-reading-way-too-much-code]] and [[2026-07-14-everything-we-knew-about-software-has-changed]] (Theo — same strategic register, same slop-is-human stance); [[2026-07-14-sebastian-eugene-interview]] (the enterprise counterweight to "kill your process"); [[2026-07-21-larysa-interview]] (his `AGENTS.md`-only approach is exactly what leaves Larysa's memory gap unsolved)
|
||||
- **Named but not in the vault:** Mitchell Hashimoto, Ghostty, hunk, Sourcegraph, Midjourney, Cloud9, Quinn (AMP CEO), Riverside
|
||||
|
||||
## Open Questions
|
||||
|
||||
- **Does "no skills, no MCP" generalize, or is it a property of his situation?** He works daily in one codebase he controls, with a company harness he helped build and a team-maintained `AGENTS.md`. The vault's skills case is strongest for people who move across many ad-hoc tasks and cannot encode context in a codebase (HR, BA). Neither side is tested against the other. Status: tentative.
|
||||
- **What replaces the token budget as a constraint?** He names it as one of two winner/loser variables but says nothing about who pays for it — the missing economics of [[explosion-of-internal-software]].
|
||||
- All ratios (99% AI-written, the team poll) are self-reported from inside the company that sells the agent. Status: tentative.
|
||||
- If admin panels and forms die, what does a non-technical person operate? Thorsten's answer is "prompt the agent," which assumes the prompting skill the corpus's HR interviews say is the actual bottleneck ([[levels-of-ai-usage]]).
|
||||
- "Local dev is going away" is a prediction from a company selling remote sandboxes, and sits against [[eugene]]'s consolidated local workspace pitch ([[harness]]). Status: tentative.
|
||||
|
||||
## Change Impact on Wiki
|
||||
|
||||
- Created 5 concepts: [[shedding-weight]], [[build-for-the-agent-not-the-human]], [[emacsification-of-software]], [[explosion-of-internal-software]], [[async-by-default]].
|
||||
- Created 2 entities: [[thorsten-ball]], [[amp]].
|
||||
- Updated [[skills-as-memory]] and [[evolution-of-agent-tooling]] with the corpus's first credible *rejection* of the skills abstraction (recorded as a contradiction, not smoothed).
|
||||
- Updated [[context-as-scarce-resource]] (information > tuning; token budget), [[code-as-throwaway]] (99%-AI-written datapoint; slop-is-human), [[make-more-cheap-code]] (variations-not-answers; ask-for-proof), [[product-ownership]] (first-principles as the top skill), [[harness]] (AMP; the minimal-harness position), [[seniority-and-the-junior-squeeze]] (the collapse of hand-taught senior knowledge), [[enterprise-ai-reality]] (token budget as a new access divide), [[leave-less-room-for-imagination]] (his prompt structure as a worked example; model-tuning tension), [[personal-ai-operating-system]] (the fourth layer — tools you build for yourself), [[claude-code]] (AMP as peer harness), [[theo-browne]] (ally cross-link), [[overview]] (9→10 sources; new "frontier side" of the through-line), `index.md`.
|
||||
51
wiki/sources/2026-07-29-what-if-we-vibe-code-it.md
Normal file
51
wiki/sources/2026-07-29-what-if-we-vibe-code-it.md
Normal file
@@ -0,0 +1,51 @@
|
||||
# А что если наВайб-Кодить? (What If We Vibe-Code It?)
|
||||
|
||||
#source
|
||||
|
||||
## Source Metadata
|
||||
|
||||
- **Date of material:** 2026 (references tweets from March and July 2026)
|
||||
- **Raw path:** `raw/sources/А что если наВайб-Кодить.md`
|
||||
- **Source type:** viewer's conclusions from a YouTube video (5:31), Russian; https://www.youtube.com/watch?v=zBcWcignqng
|
||||
- **Author:** unknown (a developer; his company uses Datadog and pays "literally millions a year" for it)
|
||||
- **Ingestion date:** 2026-07-29
|
||||
|
||||
## Core Claims
|
||||
|
||||
1. **Writing code was never the bottleneck — and never the cost.** Developers could always have written their own Jira or Datadog; they didn't because they didn't *want to run the result*. AI removes the writing cost, which was ~zero of the total, and leaves the real cost untouched.
|
||||
2. **The cost of software is maintenance, not development.** The problem starts after the first user: bugs, regressions, feature requests, logs, monitoring, on-call, uptime responsibility.
|
||||
3. **An internal service is an internal business.** A company that vibe-codes its own tracker/logger is either switching businesses or running two IT businesses at once — bad for the company (pays for one product, team builds another) and for the developer (two jobs, blamed for both).
|
||||
4. **"I can write it in a week" ≠ "it's worth writing."** Between those two statements sit years of support. The vendor's price buys the removal of operational load, not the code.
|
||||
5. **The pendulum case:** two tweets months apart — March 2026, a company builds its own Jira clone and migrates to it; July 2026, back to buying a tracker (Linear) because nobody wanted to carry the in-house product. "Assemble in two weeks — easy; carry it forward — impossible."
|
||||
6. **A build-vs-buy checklist** for the AI era: size of the dependency (small, non-evolving libraries — fine to rewrite); does it need ongoing support (if yes, it's a separate project); what operational load does it add; is the business ready to open a second IT business inside itself. If the answers are bad, stay on the paid service — even with Claude / Antigravity / Codex at hand.
|
||||
7. **Self-correction:** the author retracts his own earlier claim that "many services will die because of AI" — he now says he was wrong.
|
||||
|
||||
## Key Evidence / Details
|
||||
|
||||
- The Jira→Linear pendulum (claim 5) is the source's only external evidence; both tweets are second-hand and the company identification is fuzzy ("the same or a similar company"). Status: tentative.
|
||||
- The author's own company is living the case study: pays millions/year for Datadog, is building an in-house replacement while also evaluating cheaper vendors — i.e. he criticizes the pattern from inside it, not from abstention.
|
||||
- The checklist (claim 6) is prescriptive, not observed — the author's recommendation, not a documented practice.
|
||||
|
||||
## Connections
|
||||
|
||||
- Creates [[maintenance-is-the-real-cost]] — the source's central concept, new to the vault.
|
||||
- Direct counterweight to [[explosion-of-internal-software]] and [[emacsification-of-software]]: both pages already flagged "maintenance is assumed away" as their weakest point; this source is the first to make that objection its whole thesis, with a named failure case.
|
||||
- Sharpens the boundary of [[code-as-throwaway]] / [[make-more-cheap-code]]: throwaway code is safe *because it never has users*. The trap begins exactly where code stops being throwaway — the first user makes it a service.
|
||||
- Agrees with the vault's spine from an unexpected angle: "writing code was never the bottleneck" is the same premise as [[harness]]-over-model and Theo's verification bottleneck — the sources disagree only about *which* non-writing cost dominates (verification vs. maintenance).
|
||||
- Counters [[thorsten-ball]]'s prediction range: his club app passes the author's checklist (small, no SLA, no external users), but his "teams will remix Riverside" prediction is exactly what the pendulum case punishes.
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Where is the threshold? The checklist says "small, non-evolving libraries — yes; services with users — no," but the interesting zone is between: a 20-person club app, an internal HR knowledge base, a personal fork in `~/bin`.
|
||||
- Does the maintenance objection survive agents doing the maintenance? The author assumes ops load lands on humans; the corpus's outer-loop material ([[agentic-loops]], [[async-by-default]]) implies agents could carry some of it. Nobody in the corpus has evidence either way.
|
||||
- Who is the author, and does his in-house Datadog replacement ship or die? The pendulum predicts die.
|
||||
|
||||
## Change Impact on Wiki
|
||||
|
||||
- Created [[maintenance-is-the-real-cost]] (new concept).
|
||||
- [[explosion-of-internal-software]]: the "nobody owns the result" uncertainty upgraded from self-criticism to a sourced contradiction; scoping added (the club app passes the source's own checklist).
|
||||
- [[emacsification-of-software]]: the "maintenance is assumed away" objection now has a source and a failure case.
|
||||
- [[code-as-throwaway]]: boundary bullet added — throwaway is safe because unshipped; first user converts code into a service.
|
||||
- [[thorsten-ball]]: contradiction added (pendulum case vs. his remix-and-build predictions).
|
||||
- [[overview]]: divergence list and frontier-side bullet updated with the build-vs-buy counterweight.
|
||||
- [[2026-07-28-webinar-theses]]: scoping note added to T5 (the thesis survives — its examples are checklist-safe — but gains an honest boundary).
|
||||
55
wiki/sources/2026-07-30-rakes-in-ai-sdlc-adoption.md
Normal file
55
wiki/sources/2026-07-30-rakes-in-ai-sdlc-adoption.md
Normal file
@@ -0,0 +1,55 @@
|
||||
# Грабли во внедрении ИИ в SDLC — Rakes in AI Adoption in the SDLC (Nikolai Sheiko)
|
||||
|
||||
#source
|
||||
|
||||
## Source Metadata
|
||||
|
||||
- **Date:** talk published 2026 (references events through Dec 2025); conclusions doc saved 2026-07-30
|
||||
- **Raw path:** `raw/sources/Грабли во внедрении ИИ в SDLC.md`
|
||||
- **Source type:** viewer's conclusions from a Russian-language YouTube talk (45:59) — https://www.youtube.com/watch?v=Nm3MsnngCJg — "Грабли во внедрении ИИ в SDLC — почему ИИ есть, а результата нет и как это лечить" ("why the AI is there but the results aren't, and how to treat it"). Not a transcript.
|
||||
- **Speaker:** [[nikolai-sheiko]] — AI-adoption consultant/practitioner (works with client companies on SDLC adoption; background otherwise unknown)
|
||||
- **Ingestion date:** 2026-07-30
|
||||
|
||||
## Core Claims
|
||||
|
||||
- **AI in development already delivers real gains, but people, companies and metrics throttle it by an order of magnitude.** The real jump started Dec 2025 (Opus 4.5 / GPT-5.2 + Claude Code / Codex); the SDLC collapsed into days/hours — but *not fully*: two human "red squares" remain — the **reviewer** (tasks queue at review) and the **planner/product person**. Developer time redistributed from "coding in the middle" to "planning on the left + verification on the right." See [[review-is-the-new-bottleneck]].
|
||||
- **Universal error #0: a developer is not a manager.** A good developer is 3–5 hours of CPU-bound focus on one feature; a good AI-developer is an IO-bound **manager of an agent-employee**, running several tasks in parallel. "If you launched Claude Code and sit watching it work — you're a bad employee." Not everyone can make the psychological switch, *and that's fine* — don't force everyone. See [[developer-as-agent-manager]].
|
||||
- **Measure completed tasks without rework** — never LoC, commit count or PR count (all trivially hacked; the European-outsourcing case shipped more PRs for a +1% gain because rework ate everything). A task counts only if it doesn't come back for fixes; also track task lifetime + rework time.
|
||||
- **Review with the agent, not instead of it and not fully by hand.** Manual-only review → queue → burnout → quality collapse; fully delegated review is the opposite error. Treat the model as a smart student: direct it, pose hypotheses, find problems together.
|
||||
- **Companies no longer need custom AI development.** Key quote: *"Come in, install Claude Code or Codex, configure everything, attach connectors, think about security — and it works better than any custom build."* Corollary anti-pattern: hiring an external configurator who leaves behind a "magic artifact" nobody owns — teams must configure their own tools; what a company should buy is a **teacher/curator**, not a setup.
|
||||
- **Agentic Evolution** — the key concept. Don't ask the expert to explain how they work (you get theory); instead take the new employee (the agent) by the hand through hard tasks, show it the rakes, then say: *"remember all of this and write the manual for the next one."* Verify a skill by launching a **context-free subagent** that must solve the same task from scratch using only the skill; the mentor agent watches what fails and fixes the skill. Without evolution you live on defaults; with it, vertical growth begins.
|
||||
- **Best practices matter more with agents, not less.** The "compaction curse": on a huge codebase the agent gathers context → window overflows → compaction → re-gathers → compaction again, and the task barely completes. The cure is locality, isolated modules with interfaces — **the codebase stores the context**. Use AST search instead of grep on colossal projects. And **embeddings/RAG over code do not work** — don't use them unless you understand *very* well why.
|
||||
- **Role futures:** a **Product engineer** emerges (answers *why* we build it this way, what to cut, what to ignore); users vs **Agentic Operations** (who tune the SDLC, feedback loops, prompts, skills) gradually split; AI eats **Intelligence** (action sequences requiring intellect) while **Judgment** (taste built over years, or domain expertise — oil & gas, medicine) stays human for now.
|
||||
- **Tokens get more expensive near-term, cheaper later. It's the wild west — experiment at full throttle while subscriptions are cheap**; the goal is to land in the top half of the Stanford chart. Don't chase every new tool: what Claude Code / Codex doesn't absorb within a couple of months is probably useless.
|
||||
|
||||
## Key Evidence / Details
|
||||
|
||||
- **Timeline the talk builds on:** METR study (Jul 2025, measured a *slowdown*, but methodologically contested) → Stanford study (Aug 2025, +20% speed but top-performers pull away — this is [[swepr]]'s research, cited independently) → Karpathy's tweet (Nov–Dec 2025: "80% Claude Code, 20% by hand") → "SDLC is dead" article (stages collapse into days/hours).
|
||||
- **Case 1 (frontend migration):** no feedback loop → give the agent a browser (Playwright / Chrome DevTools) to compare old vs new front; crunch → invest in planning (20 min minimum, hours are normal; every 10 min of planning saves hours; target one-shot implementation); Cursor with per-token billing → team economizes instead of experimenting (~30% dearer than subscriptions at the same level); training rollout: record sessions → expert reviews → *writes feedback, team fixes their own agent instructions* → focus on the top 2 performers (an hour with them is worth 10× more).
|
||||
- **Case 2 (European outsourcer):** more PRs, +1% — rework was the cause; the metrics table (don't: LoC/commits/PRs; do: completed-tasks-without-rework).
|
||||
- **Case 3 (large codebase):** the compaction curse; "agents mean we can drop best practices" is exactly wrong.
|
||||
- **Mini-cases:** the middle dev who sped the team up by tens of %, was refused a raise, and left for much more ("if you're that middle — think; if you're the manager — think twice"); the startup doing spec-driven development without knowing what it wants — build the UI first (even with an in-memory browser DB), click around, *then* plan.
|
||||
- **Do-tomorrow list:** close the feedback loop; write a skill that analyses your own sessions daily; automate it (Codex schedules / Anthropic routines); voice input (more context, and Russian gives more context than English); ignore tool churn.
|
||||
- **Q&A notes:** GLM (good, no vision), Kimi (works, has vision), Xiaomi's agent (interesting memory implementation; ex-DeepSeek Head of AI) as the Chinese-model trend; hardware deficit (H100s unrentable); speaker's prediction that AI will be classed as a cyber-weapon with biotech-style licensing.
|
||||
- **One-shot recipe:** feedback loop (must-have) + explicit real *goal* the agent self-checks against + skill verification via the context-free subagent.
|
||||
|
||||
## Connections
|
||||
|
||||
- **Entities:** [[nikolai-sheiko]], [[swepr]] (its Stanford study is the talk's central chart — "be in the top half"), [[claude-code]]
|
||||
- **New concepts:** [[review-is-the-new-bottleneck]], [[developer-as-agent-manager]]
|
||||
- **Corroborates:** [[2026-07-30-stanford-swepr-widening-gap]] (independent practitioner citation of the widening-gap result *and* of review-as-downstream-cost); [[solve-first-then-skillify]] (Agentic Evolution is its strongest formulation, plus the missing verification step); [[skills-as-memory]] (a second frontier-practitioner vote *for* the skills/evolution layer, against [[thorsten-ball]]'s dissent — and a vote *against* embeddings/RAG over code, siding with Konstantin in the skills-vs-RAG contradiction); [[context-as-scarce-resource]] (compaction curse; codebase-stores-context converges with Thorsten from the opposite direction); [[async-by-default]] (IO-bound parallel management as the working mode); [[enterprise-ai-reality]] ("no custom AI development needed" names the same managed-harness market; per-token billing shapes behaviour — the metered-vs-subscription split already logged there); [[harness]] (install-and-configure beats custom builds); [[leave-less-room-for-imagination]] (explicit goal + planning discipline).
|
||||
- **Complicates:** [[make-more-cheap-code]] (rework-free-completion as the metric is the org-level answer to "generation moved the cost downstream").
|
||||
|
||||
## Open Questions
|
||||
|
||||
- The cases are anonymous client anecdotes with self-reported numbers (+1%, "tens of %"); none are verifiable. Status: tentative.
|
||||
- "Embeddings/RAG over code don't work" is stated flatly with no mechanism given — strong claim, no evidence in the doc. Status: tentative.
|
||||
- Does the context-free-subagent verification protocol actually measure skill quality, or only skill *completeness* for one task? Closely related to the corpus's proposed skills falsification test ([[skills-as-memory]]) — this is the first source to describe running one.
|
||||
- The Dec-2025 "real jump" periodization is the speaker's own; the corpus's other timeline ([[ai-agent-evolution]]) slices eras differently.
|
||||
- Predictions (AI as licensed cyber-weapon; token prices up then down) are speculation. Status: tentative.
|
||||
|
||||
## Change Impact on Wiki
|
||||
|
||||
- Created [[nikolai-sheiko]] (entity), [[review-is-the-new-bottleneck]] and [[developer-as-agent-manager]] (concepts).
|
||||
- Updated [[solve-first-then-skillify]] (Agentic Evolution + skill-verification protocol), [[skills-as-memory]] (second practitioner vote for skills; anti-RAG-for-code), [[context-as-scarce-resource]] (compaction curse, AST search, codebase-stores-context), [[async-by-default]] (IO-bound manager evidence), [[enterprise-ai-reality]] (no-custom-AI-dev quote; external-configurator anti-pattern; token-price prediction), [[make-more-cheap-code]] (related link), [[2026-07-30-stanford-swepr-widening-gap]] (independent citation).
|
||||
- Updated [[overview]] (12 → 13 sources), `index.md`, `log.md`.
|
||||
48
wiki/sources/2026-07-30-stanford-swepr-widening-gap.md
Normal file
48
wiki/sources/2026-07-30-stanford-swepr-widening-gap.md
Normal file
@@ -0,0 +1,48 @@
|
||||
# Stanford SWEPR — AI and the widening productivity gap
|
||||
|
||||
#source
|
||||
|
||||
## Source Metadata
|
||||
|
||||
- **Date:** research presented through 2025 (chart data April 2023 → July 2025; deck Sept 2025); dossier compiled 2026-07-30
|
||||
- **Raw path:** `raw/sources/Stanford SWEPR - AI and the widening productivity gap.md` (screenshot: `raw/assets/G6g3O60bkAE05ZW.png`)
|
||||
- **Source type:** research dossier — a slide read first-hand plus public coverage of the underlying study; **not** a talk transcript. The corpus's first *quantitative outside study* (every other source is practitioner testimony or synthesis).
|
||||
- **Authors:** [[swepr]] (Stanford Software Engineering Productivity Research group), public face Yegor Denisov-Blanch
|
||||
- **Ingestion date:** 2026-07-30
|
||||
|
||||
## Core Claims
|
||||
|
||||
- **The gap between AI-mastering teams and laggards is widening, measurably.** Difference-in-differences analysis of 46 AI-adopting teams vs 46 matched non-AI teams: net productivity difference between top and bottom quartiles grew from **4.8% (April 2023) to 19% (July 2025) — a 4× increase** in ~2.25 years. Early quarters hover near zero or negative; the curve only takes off from mid-2024, then accelerates.
|
||||
- **Average net gain from AI is ~15–20%, not 10×.** Gross delivered code volume rises 30–40%, but rework (fixing AI-introduced bugs) eats roughly half.
|
||||
- **Gains are strongly context-dependent:** greenfield/low-complexity 30–40%; brownfield/high-complexity 0–10% and can be *negative*. Popular languages gain more than niche ones; gains collapse as codebases grow 10k → 10M lines (context-window limits, signal-to-noise).
|
||||
- **The cost moved downstream:** coverage reports +91% PR review time and ~2.6× rework in AI-heavy workflows — writing got cheaper, reviewing got more expensive.
|
||||
- **Proposed mechanism for the gap:** quality of AI usage beats volume; teams with clean, modular, well-tested code compound gains, teams with poor hygiene accumulate debt and lose trust in the tools.
|
||||
|
||||
## Key Evidence / Details
|
||||
|
||||
- Data: private Git repos, 600+ companies, ~100k–120k engineers, since 2022; ML model replicating a panel of expert reviewers, measuring *functionality delivered* (not commits/LOC). Methodology peer-reviewed (arXiv 2409.15152); the DiD result itself is talk-published only.
|
||||
- The slide: "Causal Impact of AI on Software Engineering Productivity: Difference-in-Differences Analysis," DID covariate balance < 0.25, 95% CI band, model-release markers on the time axis. Deck: "Will AI Replace Software Engineers?", AI Conference, Sept 2025.
|
||||
- Full numbers, links, and per-claim provenance in the raw dossier.
|
||||
|
||||
## Connections
|
||||
|
||||
- **Entity:** [[swepr]]
|
||||
- **Corroborates:** [[2026-07-14-gap-between-ai-users-irreversible]] — Allie Miller's "irreversible gap" prediction is this curve, asserted 18 months earlier from advisory experience; Stanford supplies the measurement. Also the team-level twin of [[levels-of-ai-usage]] (the gap grows between *rungs of mastery*, not between license-holders and others).
|
||||
- **Corroborates:** [[context-as-scarce-resource]] — the codebase-size finding (gains collapse toward 10M LOC, attributed to context-window limits and signal-to-noise) is the corpus's first outside quantitative support for context as the binding constraint.
|
||||
- **Complicates:** [[make-more-cheap-code]] / [[code-as-throwaway]] — +91% PR review time and 2.6× rework externally confirm that generation moved the cost to review/verification, which is Theo's premise; but the *negative* gains in complex brownfield code sharpen the honest caveat that "code is cheap" holds least where most code lives.
|
||||
- **Independently cited by a practitioner source:** [[2026-07-30-rakes-in-ai-sdlc-adoption]] builds its stakes on this study ("the Stanford study, Aug 2025: +20% speed, but the top performers pull away — the goal is to be in the top half of the chart") and anecdotally mirrors its downstream-cost finding (the +1%-despite-more-PRs rework case; review as the bottleneck — see [[review-is-the-new-bottleneck]]).
|
||||
- **Queries:** [[2026-07-30-stanford-widening-gap-source]] (how this source was traced), [[2026-07-28-webinar-theses]] (thesis T7 gains its number)
|
||||
|
||||
## Open Questions
|
||||
|
||||
- Does the 46-team DiD analysis ever get a peer-reviewed publication? (Claim status upgrades when it does.)
|
||||
- What exactly distinguishes the mastering teams — tooling, codebase hygiene, or skills/context practices? The proposed mechanism ("quality of usage") is asserted in talks, not decomposed. Directly relevant to whether the webinar's skills rung is *the* differentiator. Status: tentative.
|
||||
- The study measures teams of engineers; how far do team-level results transfer to the webinar's non-engineer audience? Status: tentative.
|
||||
|
||||
## Change Impact on Wiki
|
||||
|
||||
- Created [[swepr]] entity.
|
||||
- Added measured external evidence to [[levels-of-ai-usage]], [[context-as-scarce-resource]] and [[make-more-cheap-code]].
|
||||
- Upgraded the corroboration pointer on [[2026-07-14-gap-between-ai-users-irreversible]] to cite this page.
|
||||
- Added the "Stanford measured it: 4× in two years" note to thesis T7 in [[2026-07-28-webinar-theses]].
|
||||
- Updated [[overview]] (11 → 12 sources; first quantitative outside study), `index.md`, `log.md`.
|
||||
Reference in New Issue
Block a user