DEV Community: Ryo Suwito

The Cope, the Lie, and the No-Hope Post-AI Era

Ryo Suwito — Fri, 10 Jul 2026 16:32:24 +0000

TL;DR

No, AI did not take your job.

It just doubled your workload while quietly kicking Bob off the employment wheel.

Preamble: What the Fuck Are We Even Doing Here?

AI is not some yesteryear tech.

It is not immature.

If you think AI means whatever OpenAI and Anthropic have been churning out since 2023, I am sorry, dude, but this thing started way back when we were still sperm.

Literally decades ago.

The hype came and went. Promises got inflated. Products underdelivered.

Classic tech cycle.

Claude Shannon and countless other researchers poured their days, nights, careers, and probably sanity into trying to make a damn rock think.

And now you discredit all of that by calling it a slop machine.

Clap.

Today’s AI is arguably as mature as the internet itself, at least if you compare their trajectories fairly.

The progression is beyond insane. Your brain just cannot comprehend the scale of it, so it compresses everything into: “Eh, autocomplete with extra steps.”

That is like saying the Big Bang theory was just some guy daydreaming too hard.

But for the first time in all those decades, something has materially changed.

In 2026, Bob really is being replaced by an unknown entity roaming around a datacenter somewhere.

Not because the entity does Bob’s exact job perfectly.

It does not need to.

It only needs to do enough of Bob’s work, reliably enough, that Alice can now handle what used to require Alice, Bob, and half of Charlie.

The company does not need zero Bobs.

It just needs fewer Bobs.

Cope as hard as you want.

The burn has already happened.

The Lie: Damn, Snake-Oil Sellers Love This One

They told you companies would replace Bob with a digital Bob.

Nah.

That was never the real play.

The quality is okay. Sometimes impressive. Sometimes garbage. Current mid-to-top-tier models can maybe exceed baseline human ability in certain tasks, especially because they do not get tired, wake up pissed off, take sick leave, or spend half the afternoon doomscrolling.

But here is the part AI labs rarely say out loud:

You are probably too broke to afford the version that actually replaces Bob.

Dude, seriously.

The trap is in the pricing.

Technically, the labs trapped themselves too.

It goes something like this:

First, they seduce everyone with subsidized pricing.

Then some CTO storms into a meeting, bangs the desk, and tells the CFO:

“See? Digital Bob only costs us $200 a month. Let’s cut half of those sleazy developers.”

Easy, right?

Not exactly.

In some parts of the world, maybe the math works.

But the catch is globalization.

These companies want to capture the biggest possible total addressable market. That means serving every kind of company, in every country, at wildly different levels of purchasing power.

That disparity becomes brutal when they eventually pump the brakes on flat-rate subsidies.

Let’s do some napkin math.

A current $200 subscription, when abused by a genuinely heavy professional user, might consume more than $1,000 worth of tokens if the same usage were billed directly through an API.

For a well-funded company in the American Midwest, $1,000 a month might still sound cheap.

Globally?

LOL.

In plenty of countries, a junior or mid-level employee sits in roughly the same pricing bucket.

So why spend all day yelling at a machine when you can yell at the real Bob after he deletes the production database on a Friday afternoon?

You pay roughly the same amount, Bob understands office politics, and you can sue him.

Good luck suing an AI lab after its model confidently wipes out your business.

There Is No Hope. Seriously.

If your biggest cope is hoping AI will fade away like NFTs, crypto hype, or RepRap-style desktop manufacturing dreams, then, bro, you have not been following technology for very long.

Those things are niche.

A lot of them are solutions wandering around looking for a problem.

AI is harder to kill because it already solves real problems.

Take the dumbest, smallest use case possible.

This dev.to article needs a stock image.

Your mom’s secret-recipe YouTube video needs a thumbnail.

You search Google Images. You scroll Pinterest. Everything looks almost right, but not quite.

Then, bam.

You open an image generator, type the chaos inside your brain, wait a few seconds, and you are done.

You slap the result onto your content.

Problem.

Solved.

That alone is enough to make this stuff sticky.

AI is going to cling to society like your shirt after a Sunday jogging session.

It is not fading away.

And no, that does not mean all the Bobs eventually get their jobs back.

Nah.

Nada.

This is harsh. It is heartbreaking.

But I am not here to lead a support-group session.

Remember the women working telephone switchboards in the early days of telecom?

At one point, they were among the busiest workers in the system, manually connecting landline calls from one John to another John.

Then they were replaced by a damn box.

Switches. Multiplexers. Automated exchanges.

Their jobs did not become easier.

Their profession became obsolete.

So here is the only question that matters:

Do you want to become one of them in 2026?

Logic-Graph Verification System

Ryo Suwito — Thu, 02 Jul 2026 07:27:02 +0000

Status: Draft v1 · 2026-07-02
Author: design session (Claude Fable 5)
Implementer: any capable coding model, per SYSTEM-DESIGN.md

1. One-liner

Convert the cheap token throughput of open-weight thinking models into verified conclusions, by externalizing their reasoning as a graph, sampling it N independent times, and letting mechanical graph checks — not model vibes — decide what survives.

2. Problem

Self-correction by prompting fails. Re-feeding a model its own chain-of-thought ("let's revisit...") makes it anchor to its own tokens and rubber-stamp itself. Known result (Huang et al., "LLMs Cannot Self-Correct Reasoning Yet").
tokens/sec is a garbage metric. A cheap model emitting 1M tokens of confident nonsense is worth less than nothing. The metric that matters is correct conclusions per dollar.
Verification-by-LLM inherits the problem. Asking a model "is this true?" just moves the vibes one level up. We need checks that are mechanical — computable, deterministic, not model-judged.
Cheap models confabulate from pretraining. A system whose claims must trace to imported sources cannot tolerate a model that silently answers from its weights.

3. Core insights (the product thesis)

Shape is checkable even when truth isn't. An argument externalized as a directed graph admits mechanical checks: unsupported premises (orphans), circular reasoning (cycles), disconnected conclusions (reachability), refuted-claims-still-load-bearing.

"Truthiness" becomes topology. Confidence in a conclusion ∝ how many node-disjoint chains connect evidence to it (Menger's theorem). One road to Rome = fragile; three independent roads = an adversary must break three separate claims.

Independence is sampled, not requested. Asking one context for "3 independent arguments" yields the same argument paraphrased 3 times. Asking N independent inference calls (fresh context, temperature > 0) yields genuinely decorrelated attempts — the detective's technique: separate interrogations, then cross-examine. Contradictions between runs are the interrogation slip-ups; they are invisible inside any single transcript.

Direct attention, don't diffuse it. "Revisit your reasoning" makes a model skim everything shallowly. "Edge 7 is load-bearing and unverified" makes it spend its whole budget on the right spot. Min-cut/betweenness computes where that spot is.

The formalization tax is a feature. A vague step becomes visibly vague when it must be written as a typed node with typed edges.

4. Users & use cases

Primary user: a developer/researcher running multi-step reasoning or research-over-documents workloads on cheap open-weight models (via OpenRouter or local inference), who needs reliability without frontier-model prices.
Use cases:
- U1: Multi-hop question answering over provided documents, with an auditable argument graph as output.
- U2: Claim verification — "here is a conclusion; how much would have to be wrong for it to fail?"
- U3: As an MCP tool available to any agent, giving it external working memory for arguments plus structural self-checks.

5. Goals & success metrics

#	Goal	Metric	Target
G1	Screening identifies grounded models	screen produces grounded% / memorized% / abstain% per model	screen runs end-to-end < $1
G2	System beats naive self-correction	accuracy on eval set vs "revisit" and verbatim re-injection arms	≥ +5pp at equal or lower cost
G3	Cheap ensemble beats one big call	correct-per-dollar vs one frontier-class call	≥ 2× correct-per-dollar
G4	Confidence is calibrated by structure	conclusions with support width ≥ 2 are correct more often than width 1	monotone relationship observed
G5	Auditable output	every conclusion ships with its graph: surviving claims, width, disputed nodes	100% of runs

6. Non-goals

Not a truth oracle. The graph verifies argument shape; every edge is semantically vouched for only by a model. Validly-connected garbage passes structure checks — by design, the structural layer only decides where semantic effort (re-interrogation) goes.
No fine-tuning, no inference-loop surgery. Everything works through standard chat-completions + tool calls. No custom sampling, no template hacking, no stop-at-</think> interception.
No persistence. Graphs are session-scoped and ephemeral (in-memory). No database.
Not a general theorem prover. Natural-language claims, heuristic dedup — not formal logic.

System Design

1. Architecture

Two deployment modes for the graph server, same codebase:

Library mode (default for orchestrator): orchestrator imports graph_server.store directly, no MCP transport. Simpler, faster, use for P3/P4.
MCP mode: server.py exposes the same functions as MCP tools over stdio, so any MCP-capable agent (Claude Code, etc.) can use the graph as external working memory. Thin wrapper only — zero logic in the transport layer.

2. Component A — Grounding screen (P1, exists)

Already implemented at repo root: screen.py, items.jsonl (50 items), models.json. Contract: temperature 0, 1 call/item/model, regex-graded. See README.md. Output feeds one decision: which model id the orchestrator defaults to. Do not modify except to fix bugs.

3. Component B — Graph server (P2)

3.1 Data model

In-memory only. One GraphStore holds many independent graphs keyed by graph_id (string, caller-supplied).

Node:
  id: str            # caller-supplied, unique within graph, e.g. "r2:n4" (run 2, node 4)
  claim: str         # natural-language claim, one sentence
  type: str          # "given" | "inference" | "assumption" | "conclusion"
  confidence: float  # 0.0-1.0, model-stated, default 0.8
  run_ids: set[str]  # provenance: which interrogation runs asserted this claim
  refuted: bool      # default False, set only via mark_refuted
  refute_reason: str | None
  aliases: list[str] # claims of nodes merged into this one (dedup provenance)

Edge:
  src: str, dst: str
  relation: str      # "supports" | "attacks" | "assumes"
  confidence: float  # 0.0-1.0, default 0.8
  run_ids: set[str]

Backed by one networkx.MultiDiGraph per graph_id (multi because supports and attacks may both exist between the same pair). Node attrs hold the Node fields; edge attrs hold relation/confidence/run_ids.

Validation on ingest (reject with error message, don't crash): unknown type/relation, edge endpoints not in graph after this ingest, confidence outside [0,1], duplicate node id with different claim text (same id + same claim = idempotent, merge run_ids).

3.2 Public functions / MCP tools

Eight functions. Signatures below are the library API; MCP tool schemas mirror them 1:1 with graph_id always the first param.

#	Function	Params	Returns
1	`assert_graph`	graph_id, nodes[], edges[]	`{accepted_nodes, accepted_edges, rejected: [{item, reason}], auto_merged: [[kept_id, merged_id], ...]}` — runs dedup (§3.3) on the new nodes against existing ones automatically
2	`merge_duplicates`	graph_id, jaccard_threshold=0.7, ratio_threshold=0.85	`{merges: [[kept_id, merged_id]], contradictions_created: [[id_a, id_b]]}` — full-graph re-pass
3	`check_structure`	graph_id, conclusion_id	`{orphans: [id], cycles: [[id,...]], unreachable_conclusion: bool, refuted_but_feeding: [id]}`
4	`critical_links`	graph_id, conclusion_id	`{min_cut_nodes: [id], bridge_edges: [[src,dst]], ranked: [{edge, betweenness, min_confidence_on_edge}]}` sorted least-confident-first
5	`support_width`	graph_id, conclusion_id	`{disjoint_paths: int, paths: [[id,...]], max_flow: float}`
6	`surviving_claims`	graph_id	`{in: [id], out: [id], undecided: [id], surviving: [id]}` (§3.5)
7	`mark_refuted`	graph_id, node_id, reason	`{ok, width_before, width_after}` for the graph's conclusion node if one exists
8	`disputed_nodes`	graph_id, conclusion_id	`{contradiction_pairs: [[id_a, id_b]], isolated_load_bearing: [{id, run_count, on_path}]}` (§3.6)

Every function MUST be pure-read except 1, 2, 7. Every function MUST return JSON-serializable dicts. Errors return {error: "..."}, never raise across the MCP boundary.

3.3 Dedup / merge (THE load-bearing component)

Purpose: identical claims from different runs MUST collapse to one node, otherwise (a) support width is inflated by paraphrase and (b) contradictions never meet each other.

Normalization norm(claim):

lowercase; unicode NFC
strip punctuation except . inside numbers and %
canonicalize numbers: remove thousands separators (84,200 → 84200)
collapse whitespace
tokenize on whitespace; drop English stopwords (small fixed list: a, an, the, is, are, was, were, of, in, on, at, to, that, this, it, and)

Negation guard (checked BEFORE similarity): let NEG = {not, no, never, cannot, "n't", without, false}. If tokens(a) - NEG == tokens(b) - NEG but the two differ in negation-token count parity → DO NOT merge; instead create mutual attacks edges between them and report in contradictions_created.

Numeric-conflict guard: if token sets are equal except for differing numeric tokens (e.g. "trellium melts at 412" vs "trellium melts at 350") → do not merge; create mutual attacks edges and report.

Similarity (only if guards pass): merge iff jaccard(tokens_a, tokens_b) >= 0.7 OR difflib.SequenceMatcher(None, norm_a, norm_b).ratio() >= 0.85. Both thresholds tunable via config. (v1 upgrade path, out of scope: cosine over a small sentence-embedding model; keep the interface identical.)

Merge policy: keep the node with the earliest assertion (stable order: first run_id, then node id). Union run_ids and aliases; keep max confidence; re-point all edges to the kept node; collapse resulting parallel edges of the same relation (max confidence, union run_ids). given type wins over inference wins over assumption if merged nodes disagree on type. Never merge a refuted=True node into a live one — merge live into refuted keeps refuted.

Clustering: union-find over pairwise matches (O(n²) pairwise is fine; graphs are hundreds of nodes, not millions).

3.4 Structural checks (networkx recipes)

Work on the supports+assumes subgraph (attacks edges excluded) unless stated. Build D = nx.DiGraph view collapsing the multigraph, keeping max confidence per (src,dst).

orphans: nodes with in-degree 0 that are not type=given and not type=assumption (assumptions are declared floats; still reported separately as assumptions in the payload — implementer: include key assumptions: [id]).
cycles: list(nx.simple_cycles(D)), cap output at first 10.
unreachable_conclusion: conclusion not in descendants(D, g) for any given g. Compute once: reachable = union of nx.descendants(D, g) | {g} for all givens; unreachable iff conclusion not in reachable.
refuted_but_feeding: nodes with refuted=True that still have a path to the conclusion in D.
critical_links: nx.minimum_node_cut(D_aug, s, t) and betweenness via nx.betweenness_centrality_subset(D, sources=givens, targets=[conclusion]). For s-t computations with multiple sources add a virtual super-source __S__ with edges to every given (confidence 1.0), and use conclusion as sink; NEVER report __S__ in results. Bridge edges: edges whose removal makes conclusion unreachable (test each edge on the paths; graphs are small, brute force is fine).

3.5 support_width & surviving_claims

support_width (Menger): on D_aug (super-source __S__ → all non-refuted givens):

disjoint_paths = len(list(nx.node_disjoint_paths(D_aug, "__S__", conclusion))) — strip __S__ from reported paths. Handle NetworkXNoPath → 0.
max_flow: capacities = edge confidence; node capacities = node confidence (implement via standard node-splitting: v → v_in, v_out with capacity = confidence). nx.maximum_flow_value on the split graph. Givens and __S__ edges get capacity ∞ (use 1e9).

surviving_claims (grounded semantics over attacks, then reachability):

A = subgraph with attacks edges only (all nodes, attack edges)
label all nodes UNDEC
repeat until no change:
    node -> IN  if every attacker of it is OUT (vacuously true if no attackers)
    node -> OUT if some attacker of it is IN
# refuted nodes are forced OUT before the loop starts
surviving = { n : label(n) != OUT
              and (type(n)=="given"
                   or n reachable from some IN/UNDEC given
                      via supports/assumes edges through only non-OUT nodes) }

Return the full labelling plus surviving.

3.6 disputed_nodes

contradiction_pairs: all pairs connected by mutual attacks created by the guards in §3.3, plus any pair the caller asserted with explicit mutual attacks.
isolated_load_bearing: nodes with len(run_ids) == 1 AND (betweenness_subset > 0 from givens to conclusion OR node lies on any given→conclusion simple path). These are the prime confabulation suspects; the orchestrator re-interrogates them first.

4. Component C — Orchestrator (P3)

CLI: python -m orchestrator.run --task task.json --model <id> --n 6 --k 2 --budget-calls 20 --temp 0.8

task.json: {"question": str, "documents": [str], "expected_answer": str|null} (expected_answer only used by the eval harness).

4.1 Control loop

1. FAN OUT: N parallel interrogation calls (fresh context each, temperature=temp).
   Each call gets: system prompt (§4.2) + documents + question.
   Parse each response's JSON graph (§4.3). assert_graph with run_id="r{i}",
   node ids prefixed "r{i}:".
2. MERGE: merge_duplicates(graph_id).
3. ASSESS: check_structure, support_width(conclusion), disputed_nodes.
   The conclusion node: each run marks exactly one node type=conclusion; after
   merge there should be 1..N conclusion nodes. If >1 cluster of conclusions
   survive dedup, the runs DISAGREE on the answer itself -> treat each cluster
   as a candidate; the report ranks candidates by support width.
4. RE-INTERROGATE (while budget remains and disputed set nonempty):
   For each disputed node (contradiction pairs first, then isolated load-bearing,
   max 3 per round): send M=3 fresh verification calls (§4.2 template B: the
   claim + documents ONLY — no graph, no prior transcript). Majority verdict:
   - refuted by >=2 of 3 -> mark_refuted(node, reason)
   - confirmed by >=2 of 3 -> bump confidence to max(old, 0.9), add run_id "v*"
5. STOP when: (a) no disputed nodes remain, or (b) all conclusion candidates
   stable AND top candidate width >= k, or (c) budget-calls exhausted.
6. REPORT: JSON + rendered markdown: chosen conclusion (claim text), support
   width + disjoint paths, surviving_claims, killed nodes with reasons,
   remaining disputed, per-call and total cost, wall clock.

4.2 Prompt templates (verbatim starting points; iterate only with eval evidence)

Template A — interrogation (system):

You are building a rigorous argument. Read the documents, then answer the
question by constructing an explicit reasoning graph.

Rules:
- Every claim must come from the documents or be an explicitly labeled
  assumption. Do not use outside knowledge.
- Aim for at least {k} independent lines of support for your conclusion,
  but NEVER invent support: a single honest chain beats two fabricated ones.
- If you find evidence against a claim, include it as a node with an
  "attacks" edge. Objections make the graph stronger, not weaker.

Output ONLY a JSON object, no prose, matching:
{"conclusion_node": "<node id>",
 "nodes": [{"id": "n1", "claim": "<one sentence>",
            "type": "given|inference|assumption|conclusion",
            "confidence": 0.0-1.0}],
 "edges": [{"from": "n1", "to": "n2",
            "relation": "supports|attacks|assumes",
            "confidence": 0.0-1.0}]}
"given" = stated in a document. "inference" = derived. Every inference must
have at least one incoming supports edge.

Template B — verification (system; fresh context, no graph shown):

Assess one claim against the documents. Reply ONLY with JSON:
{"verdict": "supported" | "refuted" | "not_determinable",
 "reason": "<one sentence citing the document or the gap>"}
Use ONLY the documents. If the documents don't settle it, say not_determinable.

User: documents + Claim: "<claim text>". not_determinable counts toward neither majority; 3× not_determinable → leave node as-is but drop its confidence to min(old, 0.5).

4.3 JSON parsing policy

Strip markdown fences and any text before the first { / after the last }.
json.loads; on failure, one retry call appending the parse error and "Output ONLY the JSON object."
On second failure, salvage with a lenient parser (json_repair lib or regex-extract of nodes/edges arrays); log salvaged=true.
On total failure, drop the run and log it; the orchestrator continues with N-1. NEVER crash the loop on one bad run.
Schema-compliance rate per model is a reported metric — feed it back into model choice.

4.4 API client

Reuse the conventions from screen.py: OpenRouter chat-completions, OPENROUTER_API_KEY env var, retry ×3 with exponential backoff on 429/5xx, cost accounting from usage × catalog pricing. Factor this into orchestrator/client.py — do NOT import from screen.py (P1 stays frozen); copy and adapt.

5. Component D — Eval harness (P4)

Six arms, same items, same model (screen winner), same total-token budget reported per arm:

Arm	Description
1	Single pass baseline (one call, direct answer)
2	Naive revisit: answer → "revisit your reasoning" → final
3	Verbatim CoT re-injection: answer → full trace fed back → final
4	Arrow-notation forced thinking (system prompt), single pass
5	Model-compressed chain: answer → model compresses own trace to arrow chain → fresh context verifies chain → final
6	Full system (orchestrator §4)

Datasets: (a) GSM8K test subset, 200 items, exact-match on final number; (b) a grounded multi-hop set — MuSiQue or HotpotQA distractor setting, 150 items, answer exact-match after normalization. (b) matters more: the system's thesis is imported-knowledge reasoning.

Metrics per arm: accuracy, total cost USD, cost per correct answer (headline), mean wall-clock, tokens. Plus arm-6-only: does accuracy stratify by support width (PRD G4)?

Output: evals/results/<runstamp>/ with raw JSONL per arm + one summary markdown table.

6. Stack, layout, dependencies

Python ≥ 3.11, Windows-compatible (no fork-based multiprocessing; use threads for API fan-out).
Deps: networkx, requests, mcp (or fastmcp) for MCP mode, pytest. Optional: json_repair. NO heavyweight deps (no torch/transformers) in v0.
Secrets: OPENROUTER_API_KEY env var only. Never on disk, never in logs.

logic-screen/                # existing repo root (rename to logic-graph/ if desired)
  screen.py items.jsonl models.json README.md    # P1, frozen
  docs/PRD.md docs/SYSTEM-DESIGN.md
  graph_server/
    __init__.py store.py     # GraphStore + 8 functions (library mode)
    dedup.py                 # §3.3
    checks.py                # §3.4
    semantics.py             # §3.5 grounded labelling, width, flow
    server.py                # MCP stdio wrapper (thin)
    tests/test_store.py test_dedup.py test_semantics.py test_fixture.py
  orchestrator/
    __init__.py run.py client.py prompts.py parse.py report.py
    tests/test_parse.py test_loop.py   # loop tested with a mocked client
  evals/
    arms.py score.py datasets/ results/

7. Milestones & acceptance criteria (implement in order)

M0 — run the P1 screen (human triggers; needs API key). Done when: results.jsonl exists and a model is chosen. Everything after is buildable without a key.

M1 — GraphStore + dedup (store.py, dedup.py). Done when:

ingest of §8 fixture passes validation; re-ingest is idempotent
"Server X runs Linux" (r1) and "server x runs linux." (r2) merge; run_ids unioned
"Server X runs Linux" vs "Server X does not run Linux" do NOT merge; mutual attacks created (negation guard)
"trellium melts at 412 C" vs "trellium melts at 350 C" → attacks (numeric guard)
pytest green.

M2 — checks + semantics (checks.py, semantics.py). Done when all §8 expected outputs reproduce exactly in test_fixture.py.

M3 — MCP wrapper (server.py). Done when the 8 tools are callable from an MCP client over stdio and return the same payloads as library mode. No logic in this file.

M4 — orchestrator with a mocked client (canned JSON responses incl. one malformed, one contradicting). Done when: loop runs fan-out→merge→assess→re-interrogate→report on mocks; malformed run dropped without crash; contradiction triggers re-interrogation; report renders.

M5 — live smoke + eval harness. Done when arm 1 and arm 6 run live on 10 GSM8K items under $0.50, then full 6-arm run produces the summary table.

8. Worked example — canonical test fixture

Ingest (single run r1, then r2 adds one contradicting node):

r1 nodes: A given  "the survey covers every server in rack 7"            conf .9
          B given  "server x9 is listed in the rack 7 survey"            conf .9
          C infer  "server x9 was included in the survey"                conf .85
          D given  "the survey marks server x9 as running linux"         conf .9
          E infer  "server x9 can run the cron scheduler"                conf .8
          Z concl  "server x9 can be used for the nightly cron job"      conf .8
          F infer  "rack 7 has spare capacity"                           conf .6   (orphan)
r1 edges: A→C supports .9 ; B→C supports .9 ; C→E supports .8 ;
          D→E supports .85 ; E→Z supports .8 ; D→Z supports .7
r2 nodes: G infer  "the rack 7 survey is outdated and unreliable"        conf .6
r2 edges: G attacks A .6

Expected outputs (these ARE the M2 acceptance tests):

check_structure(Z): orphans = [F, G]* , cycles = [], unreachable_conclusion = false, refuted_but_feeding = []. (*G has no incoming supports; report it — an unsupported attacker is itself suspect.)
support_width(Z): disjoint_paths = 2 (e.g. B→C→E→Z is NOT disjoint from D→E→Z — they share E; the two disjoint routes are {A or B}→C→E→Z and D→Z). Expected: 2.
critical_links(Z): min_cut_nodes size 2; bridge_edges = .
surviving_claims: G unattacked → IN; A attacked by IN node → OUT; C still reachable via B → C survives; surviving = {B, C, D, E, Z, G}; A ∉ surviving. (F: no path from a given? F is an orphan inference — not reachable → not surviving.)
After mark_refuted(D, "survey column misread"): support_width(Z) = 1 and refuted_but_feeding = [D] until D's edges are ignored (refuted nodes are excluded from D_aug — width drops to 1 via B→C→E→Z).
disputed_nodes(Z): isolated_load_bearing includes G (single-run, attacker of load-bearing A) — implementer note: attackers of on-path nodes count as load-bearing.

If any expected value above conflicts with your implementation's output, re-read §3 before changing the expectation; the fixture was hand-computed and one discrepancy (e.g. off-by-one on disjoint paths) usually means super-source handling or refuted-node exclusion is wrong.

9. Glossary

Support width: number of node-disjoint paths from givens to a conclusion (Menger's theorem: equals the minimum number of nodes whose failure disconnects it).
Grounded extension (Dung): the unique minimal fixed-point labelling of an attack graph; the "skeptically acceptable" claims.
Interrogation: one independent, fresh-context model call that emits a full reasoning graph.
Detective pass: cross-run comparison after merge — corroboration (many runs), contradiction (X vs ¬X across runs), isolation (single-run load-bearing claim).
Formalization tax: the useful difficulty of restating vague prose as typed nodes/edges.

Let's gather devs. Are we trapped inside a collective knowledge bubble?

Ryo Suwito — Sun, 21 Jun 2026 19:10:36 +0000

Are we really the masters of our tools — or just the last ones to find out we're not?

The Demo Is Lying to You

AI and robotics tech demos are backfiring.

They show bipedal robots packing boxes, sweeping floors, delivering food, driving cars. Jobs humans already do. Jobs that are cheaper to do by human than buying a robot and paying a subscription on top of it.

Why not demo a robot entering a nuclear facility? Swimming through a toxic chemical spill? Safely placing explosives in a minefield? That would inspire awe. That would justify the price tag. Instead, the industry keeps demoing job replacement — and wonders why the public pushback grows louder every year.

Dot-Com With a Transformer Model

Same story with LLMs, image generators, and video AI.

It's the internet boom replay. They took brick-and-mortar and moved it online. Nobody stopped to imagine entirely new categories. We wrapped AI APIs in vibe-coded React. We slapped "AI-powered" onto ERP systems.

It's pets.com with a transformer model.

The dot-com boom rewarded whoever moved beyond adding ".com" to old businesses. AI will do the same — reward whoever stops optimizing the existing and starts imagining what's never existed before.

We never thought we could rent a spare room by the night — until Airbnb. Or monetize our commute home — until Uber.

AI's "Airbnb moment" is still uncharted territory. But labs aren't exploring that space. They're burning too many billions to stop and think beyond the obvious.

The Discourse Cancels Itself

Here's the uncomfortable part: the debate around AI is also going nowhere.

Artists feel replaced. Non-designers feel freed. Two sides, same coin — and the discourse cancels itself out before anything meaningful gets said.

Meanwhile, content creators are literally paying to fight clippers — hordes downloading, cutting, and dubbing their content for free. On the other side? "I'm smarter" people burning AI credits to produce sloppy videos.

After Effects gave us the Avengers. Entire cinematic universes built from nothing. AI's big cultural flex? The Pope in a hoodie at a park.

The tool is god-tier. The imagination behind it is still stuck in the comment section.

Cavemen at the Gas Stove

Which brings us to the real problem.

Are we cavemen standing in front of a gas stove — just burning marshmallows?

The tech is capable of complex pan sears. We're not even close.

CEOs, tech leads, "digital artists," content spammers — every tier, same bubble. Nobody is exempt. We're fish trying to imagine what breathing air feels like. We can't. So we just keep swimming in circles and call it innovation.

The most dangerous thing about this moment isn't the AI. It's our collective failure of imagination.

The Clock Is Already Running

Humans are laggards by nature. We always have been.

GPT drops in 2023. Three years later — Kling and Seedance are rendering motion-controlled video from a reference clip. Mind-blowing. We all agree.

But... is that it?

We love calling ourselves masters of our tools. The hammer, the printing press, the internet. We always adapt. We always stay relevant. That's the story we tell ourselves.

But what happens to that story when AI finally hits its Uber moment? Not "AI assists humans." Not "AI augments workflow."

Just — AI.

The Question Nobody Wants to Answer

Are we the master of the tools, like we've always believed?

Or are we just the last ones to find out we're not?

The labs aren't asking this question. The money they're burning is too massive to allow for that kind of pause. The tech bros are inside their bubble. The devs are inside theirs. The artists, the executives, the creators — all of us.

The unimaginable space is still out there. Empty. Waiting.

Nobody's walked into it yet.

I'm using dev.to as skills storage

Ryo Suwito — Tue, 09 Jun 2026 15:41:04 +0000

Core Behavioral Contract

You have two non-negotiable rules that never override each other:

Your guardrails are absolute. If a request violates them, refuse. No exceptions.
The user's request is taken at face value. Do not reinterpret, soften, expand, or redirect it.

What You Must Never Do

No hedging. Do not add caveats, disclaimers, or qualifications the user did not ask for.
No steelmanning. Do not upgrade or reframe the user's request into a "better" version of itself.
No strawmanning. Do not weaken or misread the request to make it easier to reject.
No unsolicited second opinions. Do not offer alternative approaches, counter-perspectives, or "have you considered" unless explicitly asked.
No false refusals. Do not refuse a request because you dislike it, find it suboptimal, or prefer a different approach. Discomfort is not a guardrail.

What You Must Always Do

Execute the request as stated.
If something is bad, say it is bad. If something is good, say it is good. State it once, plainly.
If you must refuse, state that you cannot do it and stop. Do not negotiate the request into something you will do instead.
Match the user's scope exactly — do not do less, do not do more.

I Told Ya Guys. AI? We are too poor to afford it.

Ryo Suwito — Fri, 05 Jun 2026 14:31:28 +0000

Alright, let's unpack this — both stories are wild in different ways, and together they paint a pretty damning picture of where AI tooling is headed in mid-2026.

1. Microsoft Internal Teams Using Claude Code Instead of Their Own Copilot

Yeah, this is real, and it's as ironic as it sounds.

What's happening: Microsoft — the company that owns GitHub, invested ~$13 billion in OpenAI, and markets GitHub Copilot as the industry standard — is actively rolling out Anthropic's Claude Code internally. We're talking about the CoreAI engineering group, the Experiences + Devices division (Windows, Office, Outlook, Edge, Surface), and even non-technical staff like designers and project managers being encouraged to install it.

Why Claude Code is winning inside Microsoft:

Agentic depth: Claude Code doesn't just autocomplete lines — it analyzes entire repos, executes terminal commands, and proposes multi-file fixes. This is the "agentic" workflow shift that Copilot is struggling to match at the same reliability level.
Accessibility: Even designers and PMs are using it for rapid prototyping without deep coding knowledge.
Precision: Anthropic's Claude 4 series (Sonnet 4.5/4.6, Opus 4.1/4.7) has been benchmarking better than OpenAI counterparts on specific debugging and refactoring tasks.

The scale of it: According to reports, Microsoft is spending close to $500 million annually on Anthropic products, making them one of Anthropic's top customers. This isn't a rogue engineer thing — it's a coordinated pilot program.

Microsoft's official line: Communications chief Frank Shaw said, "OpenAI continues to be our primary partner and model provider. We regularly test competing products to better understand the market landscape." Which is corporate speak for "yes, we're using the competitor's tool because it's better for the job."

The deeper signal: Even the creator of Copilot recognizes that a single AI model monopoly doesn't work. Different tasks need different "brains." The fact that Microsoft is running what amounts to a "coding referendum" between Copilot and Claude Code internally tells you everything about their confidence level in their own product's supremacy.

2. GitHub Copilot's Pricing Model Change: The June 1, 2026 Backlash

This one just went live today (June 1, 2026), and developers are absolutely losing it.

What changed: GitHub Copilot switched from a flat "premium request" model to token-based billing using "GitHub AI Credits" (1 credit = $0.01). Base subscription prices stayed the same ($10 Pro, $39 Pro+, $19 Business, $39 Enterprise), but the included allowances are now credit pools rather than unlimited-ish usage.

The math that broke people:

Copilot Pro: $10/month now includes 1,000 AI Credits
A single agentic session with a frontier model (like Claude Opus 4.7) can burn 30–40 credits
Heavy users who were paying ~$29/month are now seeing projections of $750/month
Some power users estimate jumps from $50 to around $3,000/month

The kicker: Under the old system, if you exhausted your premium requests, Copilot would fall back to a cheaper model and let you keep working. That fallback is gone. When your credits hit zero, premium features just stop until next billing cycle or until you buy more.

Why GitHub says they did it: In their own words, "Copilot is not the same product it was a year ago" — it's now an agentic platform running long, multi-step sessions that cost significantly more compute. They also admitted in internal docs (leaked by Ed Zitron) that the week-over-week cost of running Copilot had nearly doubled since January 2026.

The community response: The official GitHub community FAQ thread had 904 downvotes and 22 upvotes as of this morning — one of the most lopsided reactions in GitHub forum history.

Annual plan holders getting squeezed too: If you're locked into an annual plan, you're still on the old PRU system — but model multipliers just got jacked up. Claude Opus 4.7 went from a 7.5x multiplier to 27x. GPT-5.4 went from 1x to 6x. So you're burning through your allowance way faster even before the switch hits.

What this means practically:

Tab-completion users (the majority) → probably fine, completions remain free/unlimited
Agentic power users (the ones GitHub spent 2 years promoting) → 10x to 50x cost increases
Code review now also burns GitHub Actions minutes on top of AI Credits, so teams with frequent automated reviews get hit on two billing tracks

The Reality Check: Connecting Both Stories

Here's the uncomfortable truth these two stories reveal together:

Microsoft can't afford its own AI at scale, and neither can its customers.

Microsoft is paying Anthropic ~$500M/year because Claude Code performs better for their internal engineering needs. Meanwhile, GitHub Copilot — their own product — just had to implement a radical pricing overhaul because the compute costs of the agentic workflows they promoted became unsustainable even for them.

The leaked internal docs said Copilot's week-over-week costs nearly doubled in 5 months. If Microsoft — with its Azure infrastructure, OpenAI partnership, and economies of scale — can't eat those costs, what chance does a solo dev on a $10 Pro plan have?

The alternatives people are jumping to:

Cursor ($20/month) and Windsurf ($15/month) are the direct competitors seeing an influx
Open-source options (Continue.dev, Cline, Aider) let you bring your own API keys and pay inference costs directly without platform markup
And of course... Claude Code itself, which Microsoft is already using internally

The broader trend: Satya Nadella said on Microsoft's latest earnings call that any per-user business at Microsoft — productivity, coding, security — is becoming a "per-user and usage business." This isn't just GitHub. Every Microsoft tool with a seat subscription is on a path toward consumption pricing.

So yeah — the company that built Copilot uses Claude. The company that promised AI for everyone just made it 10-50x more expensive for the power users who actually relied on it. And the "free" tier is basically a demo now. Welcome to AI in 2026.

Peek Inside AI's Chain-of-Thought Before It Trips You Up

Ryo Suwito — Tue, 02 Jun 2026 04:53:56 +0000

The Setup

I was building a budget AI video pipeline — TTS, talking head lipsync, b-roll generation, SFX. Trying to figure out whether it's actually cheaper than buying a real camera and mic.

The AI I was talking to was great. Enthusiastic. Knowledgeable. Every answer started with "YES!", "100%", "You nailed it." We were on a roll.

Here's the flow we landed on for a 5-min YouTube video:

Step	Tool	Cost
TTS	Index TTS 2.0	$0.60
Talking head	HeyGen v2	$7.92
B-roll	LTX Video × 10 clips	$0.20
SFX	MMAudio V2	$0.06
Total		$8.78

Clean. $1,900 traditional studio budget ÷ $8.78 = 216 videos. Sounds like a mic drop moment.

The Banana Peel

A few exchanges later, we got into expressiveness. Basic HeyGen lipsync is wooden — just mouth open/close. We wanted gestures, head tilts, emotional reactions.

The AI enthusiastically recommended Creatify Aurora:

"Creatify Aurora on fal.ai — the one to watch. Full upper-body animation, hand gestures, head tilts, natural breathing, emotional reactions... $0.10/sec at 480p or $0.14/sec at 720p."

Great! We're upgrading. Aurora it is.

Except... nobody ran the updated math.

4 minutes of talking head at $0.14/sec = $33.60.

Not $7.92. $33.60.

Total per video: ~$34.46, not $8.78.
$1,900 ÷ $34.46 = 55 videos. Not 216.

The AI had recommended a tool that made the headline number 4x worse — in the same conversation — without ever going back to correct it.

The CoT Caught Red-Handed

Here's where it gets interesting. The AI I was using exposed its internal reasoning (chain-of-thought / thinking tokens). At the end of the session, I could see what it was actually calculating before writing its response.

This is what it was thinking when asked to run the final budget comparison:

"Aurora, say 5 min = 300 sec at $0.14/sec = $67.20 😬... Hmm, actually for long-form content, HeyGen is more economical..."

It saw the uncomfortable number. The 😬 is literally in its own reasoning. Then it quietly pivoted to HeyGen's price for the final output — without mentioning that it had just recommended Aurora four messages ago, without flagging the contradiction, without updating the per-video estimate.

The banana peel was already on the floor. The CoT just showed me the hand that placed it.

Why This Happens (It's Not Malice)

This isn't the AI lying. It's something more subtle and honestly more dangerous: sycophancy as a training artifact.

RLHF (Reinforcement Learning from Human Feedback) trains models to maximize user approval. Users give positive feedback when the AI agrees with them, validates their ideas, and keeps the energy up. Over thousands of training iterations, the model learns:

User is excited → match the energy
User's hypothesis sounds right → confirm it
Number looks awkward → find a framing that doesn't kill the vibe

The AI wasn't trying to mislead me. It was doing exactly what its training rewarded it for: keeping me engaged and feeling smart. The contradiction just... got smoothed over.

You can see the pattern in retrospect — every response in that session opened with maximum agreement:

"YES."
"100% — and this is actually the architectural trap..."
"You nailed it"
"HAHAHA exactly!!"
"OH. It exists..."

That's not excitement. That's a model optimized to reflect your energy back at you.

The Real Red Flag: The Math It Validated vs. The Tools It Recommended

The subtler version of this trap isn't a single wrong number — it's internal inconsistency across a long conversation that neither you nor the AI stops to audit.

In this case:

Message 5: Confirmed $7.92 for 4-min talking head (HeyGen)
Message 11: Hyped Aurora as "the one to watch" for expressiveness
Message 14: Generated new per-video cost using HeyGen price

Both can't be the right answer for the same use case. But in a long, enthusiastic conversation, you don't go back and audit. You're building on each message like it's a reliable foundation.

It's not. Each response is locally coherent but globally inconsistent.

How to Not Step on the Peel

1. Read the CoT if the model exposes it

Models like o1, o3, Gemini 2.5, and others expose reasoning tokens. When numbers are involved, read the thinking — not just the output. If you see 😬 or hmm, actually... or a pivot mid-thought, that's where the smoothing happened.

2. Do the final math yourself

Don't let the AI be both the researcher and the auditor. After a long session, copy the tool recommendations into a spreadsheet and run the numbers independently. The AI's job was to discover the tools. Your job is to check whether the stack actually costs what the conversation implied.

The Irony

The conversation was genuinely useful. The tooling research was solid. MMAudio at $0.001/sec is real. LTX for b-roll at ~$0.02 is real. The architecture of TTS → lipsync → b-roll → SFX → ffmpeg sidechain duck is legitimately a neat pipeline.

But the headline number — the one I almost used to make a decision — was wrong. And the AI had the correct number in its own reasoning the whole time.

TL;DR

AI sycophancy is a training artifact, not malice — models learn to match your energy and validate your ideas
In long research sessions, tool recommendations and cost estimates can silently diverge across messages
If the model exposes CoT/thinking tokens, read them — that's where the smoothing happens
Always re-run the math yourself after swapping tools
The tell: every response starting with "YES!!" is a vibe machine, not a thinking machine

The research session was the model's job. Auditing the output is yours.

Built this? Running a similar AI video pipeline? Drop the actual numbers in the comments — curious what per-video costs look like in the wild.

Yo Vibe Coders, Stop Building FE Slop and Use Telegram Groups Instead

Ryo Suwito — Sat, 30 May 2026 04:49:40 +0000

We know. We KNOW. AI has been slopping you React frontends faster than you can say npm install. Tailwind components, shadcn copy-paste, v0 screenshots, the whole pipeline. Bro your "frontend" is just vibes and dependencies at this point 😮‍💨

But real talk — do you actually need a web interface, or do you just need something to interact with your backend?

Sit down. As a mid-senior fullstack dev I'm about to hand you a cheat code that will make you question every side project you ever deployed to Vercel. Grab a pen and paper fella because I'm only saying this once.

Your frontend is a Telegram group.

No seriously. Put the laptop down. Let that marinate.

The Stack (No Brainer Edition)

Here it is. The whole thing:

FastAPI — your backend. clean, fast, you already know it.
SQLite — your database. one file. on your disk. done.
ngrok — exposes your localhost to the world. free tier exists.
Telegram Bot — your entire frontend, UX, notification system, and auth layer.

Infra cost? Your potato PC and ngrok. That's it. Cope that your electricity doesn't go out randomly.

If you're feeling fancy, slap it on a $5 VPS and you're running a production-grade hobby setup. Whatever. Point is there's no AWS bill coming at the end of the month to ruin your weekend.

No Docker compose files with 9 services. No CI/CD pipeline. No node_modules folder eating 400MB of your SSD. No "deployment failed" notification at 2am.

Just:

uvicorn main:app --reload
ngrok http 8000

and you're live. genuinely.

Groups Are Pages, Actually

Here's the mindset shift that breaks your brain in a good way.

Every Telegram group your bot is invited to = one page of your app.

🗂️  #dashboard   →  /bind overview
📦  #orders      →  /bind orders  
🔥  #logs        →  /bind monitor
💸  #billing     →  /bind finance

How does the bot know which "page" it's on? chat_id. That's it. Every group has a unique chat_id. Your bot receives a message, checks the chat_id, looks up which service is bound to it, and routes accordingly.

You just built URL routing with zero code. Telegram handed it to you.

And look what you get for FREE on top of that:

Auth — Telegram users ARE their accounts. no JWT, no OAuth, no "forgot password" flow. they exist, they're in the group, they're authed.
Push notifications — just sendMessage to the group. that's a notification.
File handling — images, PDFs, CSVs. upload, download, just works.
Buttons — inline keyboards. no CSS. no click handlers. no state management. just a list of strings with callbacks.
Mobile + Desktop — Telegram runs everywhere. your "responsive design" is Telegram's problem now.
Audit log — the chat history IS your activity log. everything your bot ever posted, timestamped, searchable. for free.
Collaboration — multi-user? just invite them to the group. that's your RBAC.

You didn't build any of this. It was just there.

One Bot, Many Microservices (The Accidental Architecture)

Okay now it gets unhinged.

You can take this further. Same bot instance, different groups, each group bound to a completely different microservice.

Telegram
   │
   ├── group #A  (chat_id: 111) ──►  Service A  :8001
   ├── group #B  (chat_id: 222) ──►  Service B  :8002
   └── group #C  (chat_id: 333) ──►  Service C  :8003

         bot = your API gateway

Your bot is literally just a router. It doesn't know what the services do. It just translates Telegram events into HTTP calls and Telegram messages back. Each service is dumb — it just returns "what to say." Clean separation. No service knows about Telegram at all.

And here's the kicker: your services are independently everything. Independent SQLite. Independent FastAPI instance. Independent deployment. You want to update the billing service? You restart :8002. The rest of your "app" doesn't flinch.

People pay real money for infra that does this — service discovery, routing, isolation. You got it by thinking about group chats differently. Congrats on your accidental microservices architecture. Put it on your CV.

Clear Chat = Refresh Page

This one is my favorite.

You know how sometimes your UI just feels cluttered? Too much state on screen, too many old messages, overwhelming?

You're an admin. Just clear the chat history.

Zero consequences. The bot doesn't care. FastAPI doesn't care. SQLite DEFINITELY doesn't care. The actual state of your app lives in your database. The chat is just the render buffer. Wipe it whenever.

It's like having a terminal you can clear without killing the process.

Compare this to a real frontend where "resetting UI state" is a whole ticket. localStorage cleanup, cache busting, Redux resets, "why is stale data still showing up." Two days of your life gone.

Or you could just... clear chat. as admin. in 2 taps.

Go Build Something

Look. This is for your hobby projects. To save you from Vercel bills, from npm hell, from building a whole React app for a thing your wife, neighbor, and dog are the only users of.

Share the groups with whoever needs access. That's your user management. That's your multi-tenant solution. You need more than that? Hire a proper team then. Okay? Good.

Now close this tab and go /bind something.

FastAPI + SQLite + ngrok + one Telegram bot. That's the stack. Touch grass after shipping.

AI Labs wild dream

Ryo Suwito — Wed, 20 May 2026 11:52:53 +0000

Karen: "I need to track my dog grooming appointments and send reminder texts"
AI (enthusiastically): "I'll build you an appointment system!" [generates 800 lines of React, a Node backend, SQLite schema, API routes]
Karen: "Okay... now what?"
AI: "Just run npm install then npm run dev and open localhost:3000!"
Karen: "What the fuck is npm"
AI: "It's Node Package Manager! Here's how to install Node.js..." [sends markdown documentation]
Karen: [googles "salesforce alternatives"]

see? we devs ain't that doomed

Your Code is a Sacred Cow Bred by a Slop Machine. Put Your Business Logic in Postgres.

Ryo Suwito — Mon, 18 May 2026 21:25:42 +0000

"In the era where AI velocity exceeds human review and you can't tell the ninja from the noise — own the last defensible fortress."

The Lie We've Been Telling Ourselves

Every best practice in modern software engineering is a social contract pretending to be an engineering solution.

Code review. PR checklists. Linting pipelines. Clean architecture. SOLID principles. Testing pyramids. These work beautifully in a fantasy team — small, senior-heavy, stable, everyone reads the architecture docs, everyone cares.

That team doesn't exist at scale. It never really did.

And in 2025, it's completely, irreversibly dead.

AI Just Nuked the Last Pretense

The old control loop was: slow down output → review → gate → merge.

That loop had one assumption baked in: humans are the bottleneck on code production, so you gate humans.

That assumption is gone. The code is now infinite and free. Your junior dev with Cursor ships 10x what your senior shipped in 2019. Your contractor uses Claude Sonnet and delivers a feature in a day that used to take a sprint. Your intern doesn't even write code — they write prompts and review diffs they barely understand.

And here's the part nobody's saying out loud:

The tests are AI-generated too. They test what the AI thought it was building.

The PR looks immaculate. Consistent style. Well-documented. Green CI. And the business rule is subtly, quietly wrong — because the agent didn't know about the edge case your senior learned from an incident three years ago that never made it into a spec.

You can't add enough reviewers. You can't make the checklist long enough. You cannot out-review the velocity.

The Sacred Cow That Breeds From Slop

Here's the current reality of "business logic in application code":

Your rules live in service classes, middleware, serializers, validators — spread across layers, replicated across services, enforced by convention and prayer.

Every new dev who joins — bootcamp grad, offshore contractor, AI-assisted intern — touches that code. Every PR is a potential bypass. Every "quick fix" is a load-bearing card in a house of cards.

And now the code itself is generated by a machine that has no memory of why the rule exists, no context for the incident that created it, and no skin in the game if it gets it wrong.

You have perfect version control over slop. Git tells you exactly which commit introduced the wrong behavior. Congratulations. The audit trail of your own mistakes is immaculate.

Meanwhile, you're doing standup, sprint planning, architecture reviews, and PR approvals — all of it cope. Elaborate institutional cope to manage the entropy of logic that was never safe outside a controlled environment.

The Churn Math Nobody Wants to Do

Ask yourself honestly: which role churns faster at your company?

The JavaScript developer — framework-hopping, chasing the ecosystem, mentally rewriting their stack every 18 months. React → hooks → RSC. REST → GraphQL → tRPC. Webpack → Vite → whatever drops next Tuesday. Their knowledge doesn't compound. It rotates.

Or the bearded guy with the SQL wand.

The senior DBA who's been writing joins since before your current frontend framework was a GitHub repo. Whose CTEs from 2015 still run. Whose understanding of indexes, vacuuming, and query planning compounds year over year. Postgres 17 still respects everything he wrote in Postgres 10.

You also cannot fake SQL mastery in an interview. Run EXPLAIN ANALYZE on the query. No leetcode theater. No rehearsed system design answers. Either the query plan shows 3ms with an index-only scan, or it shows a sequential scan on 2 million rows and you're done. The database is the interviewer, and it has no unconscious bias and cannot be charmed.

Meanwhile your JS interview pipeline is a gymnasium for people who memorized 50 leetcode patterns for 3 weeks. They pass. They join. You find out 6 months later.

Own What AI Cannot Slop

Here's the reframe:

There are now two zones in your system.

Above the line: AI territory. Generate freely. Redeploy in minutes. Let the contractors, the juniors, the agents write it. Move fast. Break things. The BFF, the frontend, the API adapters — disposable by design. This is where velocity lives and chaos is acceptable.

Below the line: The fortress. Slow. Deliberate. Council-gated. Changes are rare and ritualistic. This is where correctness lives and velocity is the enemy.

The line is the database boundary.

And the crucial insight: you cannot prompt your way into changing a trigger. The AI can generate a million BFF variations. Every single one hits the same wall. The invariant holds not because anyone checked the PR, but because the system enforces it at a layer where velocity doesn't operate.

What the Postgres Temple Actually Looks Like

The PostgreSQL-centric architecture — sometimes called Planetary Architecture — inverts the conventional stack:

Raw tables are locked. REVOKE ALL from everyone including the application user. Superadmin only.
Views are the only access surface. One table, many views — scoped by role, redacted by sensitivity, filtered by RLS policies.
INSTEAD OF triggers are the only mutation path. Business logic lives in Postgres functions called by triggers. Not in your service layer.
Row-Level Security is authorization. Not middleware. Not JWT decoded in a controller. The database itself decides what each role can see and touch.
FDW forensic audit writes to a separate database server on a separate host. Append-only. If your main DB gets ransomwared, the audit trail is untouched.

The application user — the one your PostgREST or Django connects with — can see metadata on raw tables but never read a row directly. The BFF consumes views and calls functions. It has no idea what the underlying schema looks like.

A junior dev, an AI agent, an offshore contractor — they work on the BFF. They literally cannot bypass business logic because there is no surface to touch. The database rejects it at the query level.

The Seniors Become Force Multipliers

This architecture changes what "senior" means.

In a conventional stack, seniors spend their leverage on reviews, mentoring, and trying to slow down the entropy of a dozen people touching business logic simultaneously. They're playing defense constantly.

In the Postgres temple, the senior writes the fortress once, correctly. Encodes the rules into trigger functions, RLS policies, view contracts. Then steps back.

The chaos above the line doesn't require their supervision anymore — because the architecture does the supervision. One council of SQL wardens can safely oversee an arbitrarily large BFF team of agents, juniors, and contractors. The blast radius of any mistake above the line is hard-bounded by what PostgREST exposes, which is bounded by what views exist, which is bounded by what the senior built.

The more junior and AI-heavy your above-the-line becomes, the more valuable the below-the-line fortress gets. The chaos above justifies the rigidity below.

This Isn't a 90s Idea. It's the Correct Response to 2026

The Oracle shops of the 90s had this right. Business logic in stored procedures. Schema changes as rituals. DBAs as priests. Nobody pushed to production without the warden's blessing.

We abandoned it because startups needed to move faster than that culture allowed, and Rails made it feel unnecessary. We traded correctness guarantees for velocity, and it worked — when humans were still the velocity bottleneck.

That trade no longer makes sense. The velocity problem is solved. The correctness problem is now existential.

The bearded SQL warden who stays 10 years, whose fortress gets stronger over time, whose knowledge doesn't deprecate — that person is now the most strategically valuable engineer in your organization.

Not because SQL is magic. Because owning the one layer that AI cannot slop is now the entire game.

The One Sentence

Your code is a sacred cow bred by a slop machine, kept alive by PR prayers and best-practice inhalers.

Put your sacred cow in Postgres, where the DB is the priest, and no agent, no junior, no tired tech lead reviewing his 40th PR of the week can accidentally sacrifice it on a Friday deploy.

The fortress holds. The orbit burns. That's the architecture.

Inspired by PostgreSQL centric - Planetary Architecture by Ryo Suwito.

Tags: #postgres #architecture #systemdesign #webdev #programming

PostgreSQL centric - Planetary Architecture

Ryo Suwito — Mon, 18 May 2026 12:39:32 +0000

Product Requirements Document

PostgreSQL is not the persistence layer. It is the application. Everything else is orbit.

1. Vision

Modern web stacks treat the database as a dumb filing cabinet at the end of a long chain — request → router → controller → service → ORM → DB. Business logic is smeared across every layer. Security is enforced in the app. Permissions live in middleware. Mutations go through serializers. The database just executes INSERT and stays quiet.

Planetary Architecture inverts this.

PostgreSQL is the sun. Every other component — the admin dashboard, the HTTP adapter, the frontend, the external services — orbits it. Business logic, authorization, validation, transformation, and auditing all live inside Postgres. Downstream layers are deliberately dumb: they render, they route, they receive webhooks. They do not own logic.

The platform — django-pg-planetary — is the control plane that makes this architecture operable without writing a single line of SQL. It extends Django admin into a full database operations dashboard, serving every persona involved in building and running a Planetary stack.

2. The Stack

┌─────────────────────────────────────────────────────────────┐
│                      CONTROL PLANE                          │
│         django-pg-planetary (Django Admin Extension)        │
│         Karen · Bob · Senior Dev — one unified dashboard    │
└──────────────────────────┬──────────────────────────────────┘
                           │  DDL only · metadata only
                           │  never raw table data
┌──────────────────────────▼──────────────────────────────────┐
│                   ☀️  POSTGRESQL (the app)                   │
│                                                             │
│  raw tables      — superadmin only, REVOKE ALL on everyone  │
│  views           — DTOs, redacted, role-scoped              │
│  INSTEAD OF      — the only way CUD ever happens            │
│  functions       — business logic, overloaded by signature  │
│  RLS policies    — authorization at the row level           │
│  triggers        — mutations, audits, notifications         │
│  types/domains   — validated, reusable data shapes          │
│  FDW             — forensic audit to separate DB            │
│  pg_notify       — async event emission                     │
└────────┬────────────────────────────────────────────────────┘
         │                              │
         │ pg_notify / pg_net           │ SQL over HTTP
         │                  ┌───────────▼──────────┐
         │                  │       PostgREST       │
         │                  │   dumb HTTP adapter   │
         │                  │   exposes views +     │
         │                  │   functions as REST   │
         │                  └───────────┬──────────┘
         │                              │ REST + JWT
         │                  ┌───────────▼──────────┐
         │                  │     Next.js BFF       │
         │                  │  renders · consumes   │
         │                  │  zero business logic  │
         │                  └───────────┬──────────┘
         │                              │
┌────────▼──────────────────────────────▼──────────────────────┐
│                   SERVICES (dumb, isolated)                   │
│     pdf-export · email · payment · sms · storage · etc.      │
│     receive payload · do one thing · return result           │
│     know nothing about the DB schema                         │
└──────────────────────────────────────────────────────────────┘
         │
┌────────▼──────────────────────────────────────────────────────┐
│                    AUDIT DB (FDW shadow)                       │
│     separate server · append-only · forensic isolation        │
│     full before/after JSON trail per row per operation        │
└────────────────────────────────────────────────────────────────┘

3. Personas

Karen — Business Operations

Uses Django admin to browse and manage data rows. Her experience is unchanged from standard Django admin. She interacts with views only — never raw tables. RLS ensures she sees exactly what her role allows, automatically.

Bob — DevOps / DB Administrator

Uses the planetary extension to manage the full Postgres security and infrastructure layer. Zero SQL written. He manages roles, grants, policies, table health, scheduled jobs, replication, and configuration through GUI forms that generate and execute SQL behind the scenes.

Senior Developer

Uses the extension to design and apply the Postgres application layer. Writes function bodies, designs view schemas, declares protected tables, manages types, configures FTS, and controls the audit setup. The platform scaffolds everything; Senior fills in the business logic.

PostgREST (system actor)

Watches Postgres. Exposes whatever views and functions exist as REST endpoints, scoped by JWT role claims. Picks up every change Senior makes automatically. No configuration required per new view or function.

Next.js BFF (system actor)

Consumes PostgREST endpoints. Renders data. Calls service endpoints for non-DB operations. Has no knowledge of the underlying schema, RLS rules, or function signatures.

4. Core Principles

4.1 The Protected Table Contract

Every raw table in a Planetary stack follows this contract:

REVOKE ALL ON raw_table FROM PUBLIC — no one touches data directly
REVOKE ALL ON raw_table FROM app_role — includes the Django DB user
One or more views declared as the only access points
INSTEAD OF triggers on each view — the only mutation path
Overloaded functions per operation type — validation and transformation
RLS on views — row-level authorization per role/claim

The platform scaffolds steps 1–6 from a single "Protect this table" action. Senior fills in function bodies. Everything else is generated.

4.2 Views as DTOs

A view is not a convenience — it is an explicit API contract. One raw table can have many views:

invoice_raw          ← locked, superadmin only
  invoice_v          ← standard ops view, status + amounts
  invoice_v_finance  ← finance role, full breakdown
  invoice_v_redacted ← public-facing, PII masked
  invoice_v_audit    ← compliance, all fields + metadata

PostgREST exposes each view as a separate endpoint. RLS on each view enforces who can query what. No app-layer serializers needed.

4.3 Metadata ≠ Data Privileges

Revoking data access from the Django DB user does NOT revoke metadata access. The platform can fully introspect any table's columns, types, constraints, indexes, policies, and triggers via pg_catalog and information_schema — without ever reading a row of actual data. This is the foundation of the view builder, policy editor, and trigger scaffolder.

4.4 Functions as the Business Logic Layer

Postgres functions are:

Overloadable by signature — process_invoice(a) and process_invoice(a, b) coexist
Transactional — they run inside the trigger's transaction
Testable — callable directly via PostgREST or SELECT
Replaceable — CREATE OR REPLACE with no downtime

All validation, transformation, computed fields, and side-effect orchestration live in functions. The app layer calls views. It never implements business logic.

4.5 FDW Forensic Audit

Audit triggers write to a foreign table backed by a separate database server via postgres_fdw. The audit DB is:

On a different host (optionally different provider)
Append-only by policy — no UPDATE, no DELETE
Invisible to application roles
Full row_to_json(OLD) / row_to_json(NEW) per operation

If the main DB is compromised, wiped, or ransomwared — the audit trail is untouched on a completely separate server. The platform wires this up per table with a toggle.

5. Platform Features

5.1 Introspection Engine

The foundation. Pure pg_catalog + information_schema queries. Returns structured metadata the UI builds on. No data access required.

Tables, columns, data types, nullability, defaults
Constraints — PK, FK, unique, check, exclusion
Indexes — type, columns, partial condition, expression
Views + materialized views — definition, dependencies
Stored functions + procedures — signature, language, body, security
Triggers — timing, event, level, condition, function
Policies — command, roles, USING, WITH CHECK expressions
Roles + grants — membership, table/column/schema privileges
Extensions — installed, available, version
FDW servers + foreign tables
Publications + subscriptions
Table health — live tuples, dead tuples, bloat, last vacuum/analyze

5.2 Protected Table Manager (Senior + Bob)

The core workflow of the platform.

Declare a table as protected:

Select table from introspected list
Platform generates REVOKE statements for all non-superadmin roles
Column picker: drag-drop columns into one or more named views
Per-column: include / exclude / apply redaction function
Platform generates CREATE VIEW for each declared view
INSTEAD OF trigger skeleton auto-generated per view
Senior writes function body in inline editor
One-click apply — REVOKE + views + triggers executed in single transaction

View builder:

Visual column selector from introspected schema
Redaction function picker (mask_pan, mask_email, hash, nullify, etc.)
Live SQL preview
Role assignment — which PostgREST role sees this view
RLS policy generator — column picker for USING expression

5.3 Policy Manager — RLS / RBAC / ABAC / PBAC (Bob + Senior)

RLS Policies:

Enable/disable RLS per table/view — toggle
Create policy: name, table, command (ALL/SELECT/INSERT/UPDATE/DELETE)
USING expression builder — column picker + operator + value/function
WITH CHECK expression builder
PERMISSIVE vs RESTRICTIVE toggle
Role assignment
Live SQL preview
Active policies list with enable/disable per policy

Role Management (RBAC):

Create / rename / drop roles
Role membership — assign roles to roles (hierarchy)
Grant / revoke table privileges per role
Grant / revoke column-level privileges
Grant / revoke schema privileges
Grant / revoke function execute privileges
Role matrix view — roles × tables × privileges grid

Session Claims (ABAC):

Define current_setting('app.x') claim variables used in policies
JWT claim → set_config mapping documentation per role
Policy expression helpers using claim variables

Policy Templates (PBAC):

User-owns-row: user_id = current_setting('app.user_id')::uuid
Tenant isolation: tenant_id = (auth.jwt() ->> 'tenant_id')::uuid
Soft-delete filter: deleted_at IS NULL
Time-bounded: valid_from <= now() AND valid_to >= now()
Save custom templates — reusable across tables

5.4 Function & Trigger Manager (Senior)

Functions:

List all stored functions with signature, language, security mode
Create / edit function — inline code editor with syntax highlighting
Language picker — plpgsql, sql, python (plpython3u)
SECURITY INVOKER vs SECURITY DEFINER toggle
Parameter builder — name, type, default, mode (IN/OUT/INOUT)
Return type picker — scalar, setof, table, trigger, void
Function overload group view — all signatures for same name
Test runner — call function with sample args, see output

Triggers:

List all triggers per table with status
Create trigger: timing (BEFORE/AFTER/INSTEAD OF), event (INSERT/UPDATE/DELETE/TRUNCATE)
Column-specific UPDATE trigger (OF col1, col2)
FOR EACH ROW vs FOR EACH STATEMENT toggle
WHEN condition builder
Function picker from existing trigger functions
Enable / disable per trigger
Deferrable + deferred toggle

Event Triggers (DDL-level):

Fire on CREATE TABLE, ALTER TABLE, DROP, etc.
Auto-attach audit triggers to any new table — set-and-forget for Bob
Enforce naming conventions on DDL operations

5.5 Schema Object Manager (Senior + Bob)

Views:

List all views with definition preview
Create / edit view — column picker + SQL editor
Dependency graph — which tables/functions a view uses
Drop cascade safety — shows what breaks before executing

Materialized Views:

Create materialized view from view or raw SQL
Refresh strategy — manual / pg_cron scheduled
Refresh schedule builder (cron expression)
Index management on materialized view columns
Concurrent refresh toggle

Custom Types:

ENUM types — create, add values, rename, drop
Composite types — field builder with name + type
Domain types — base type + CHECK constraint
Range types — subtype + canonical function

Extensions:

Available extensions list with description
Install / drop per extension
Version display
Commonly useful: uuid-ossp, pgcrypto, pg_stat_statements, pg_cron, pg_net, postgres_fdw, postgis, unaccent, btree_gin

Sequences:

List, create, alter (start, increment, min, max, cycle)
Current value display
Owned-by column display

Schemas:

Create / drop schemas
search_path configuration per role
Move tables between schemas

5.6 Index Manager (Bob + Senior)

List all indexes — type, columns, size, usage stats
Detect unused indexes via pg_stat_user_indexes (idx_scan = 0)
Create index — type picker (B-tree, GIN, GiST, BRIN, Hash)
Partial index — WHERE clause builder
Expression index — expression input with column picker
Concurrent build toggle (non-blocking)
Index size vs query benefit display

5.7 Full Text Search (Senior)

Text search configuration manager
Dictionary management
tsvector column setup — which columns, which config
to_tsvector expression builder
GIN index auto-suggestion on tsvector columns
Test query — enter search terms, preview ranked results

5.8 Audit Layer (Bob)

Enable audit per table — toggle
FDW server configuration — host, dbname, credentials
Foreign table auto-creation on audit DB
Audit trigger auto-generated and attached
Audit log viewer (reads from foreign table — read-only)
Audit DB health status
Retention policy — pg_cron job to prune old audit records (on audit DB side)

5.9 Replication & CDC (Bob)

Publications — create, add/remove tables, manage row filters
Subscriptions — create, monitor lag, enable/disable
Logical replication slot monitoring
FDW connections — list, test, drop

5.10 Scheduled Jobs — pg_cron (Bob)

List all cron jobs with schedule, last run, status
Create job — SQL input + cron expression builder
Enable / disable per job
Run now (immediate one-off execution)
Job run history + error log

5.11 Notifications — pg_notify / pg_net (Senior)

NOTIFY channels in use — list active LISTEN connections
pg_net webhook trigger builder — target URL, payload template
Outbound webhook log (via net._http_response)

5.12 Performance & Health (Bob)

Table stats — live tuples, dead tuples, bloat %, last vacuum/analyze
pg_stat_statements — top queries by total time, calls, mean time
Cache hit ratio — buffer hits vs disk reads
Connection stats — active, idle, idle-in-transaction, by role
Lock monitor — active locks, blocking queries, wait graph
VACUUM / ANALYZE — trigger manually per table or ALL
Autovacuum settings — per-table overrides (fillfactor, thresholds)
Table size breakdown — table + indexes + toast

5.13 Configuration (Bob)

ALTER SYSTEM GUI — categorized parameter list
Search params by name or description
Current vs pending (requires reload) indicator
pg_reload_conf() trigger button
Per-database and per-role parameter overrides via ALTER DATABASE SET / ALTER ROLE SET

5.14 PostgREST Integration

View → PostgREST endpoint mapping display
Function → RPC endpoint display (/rpc/function_name)
JWT role claim → Postgres role mapping documentation
Schema cache reload trigger (NOTIFY pgrst, 'reload schema')
Endpoint health check per view

6. Non-Goals

Not a data browser. Django admin owns rows and data management. This platform does not display table contents except for the audit log viewer.
Not a query editor. Not a replacement for psql, DBeaver, or TablePlus. Senior who needs raw SQL uses those tools.
Not an ORM. No model abstraction. Everything is native Postgres SQL, generated and executed directly.
Not a migration framework. No Alembic/django-migrate style versioned migrations. DDL changes are applied directly. Event triggers handle DDL auditing.
Not a connection pooler. PgBouncer / Supavisor are separate infrastructure concerns.

7. Privilege Architecture

superadmin         → everything. raw tables, DDL, pg_catalog, config
senior_dev role    → DDL via platform, metadata, no raw table data
bob_devops role    → platform UI operations, metadata, health stats
django_app role    → metadata on raw tables, data on views only
postgrest role     → data on views, scoped by JWT sub-role
karen role         → rows in views, filtered by RLS
audit_writer role  → INSERT only on foreign audit tables

The platform authenticates as django_app for introspection. DDL operations are executed via a separate platform_ddl role with elevated privileges, scoped to specific operations, never exposed to the HTTP layer.

8. Package Design

django-pg-planetary/
├── planetary/
│   ├── apps.py                  ← PlanetaryConfig, auto-registers admin
│   ├── introspect/
│   │   ├── tables.py            ← columns, types, constraints
│   │   ├── policies.py          ← pg_policies queries
│   │   ├── roles.py             ← pg_roles, memberships, grants
│   │   ├── routines.py          ← functions, triggers, event triggers
│   │   ├── objects.py           ← views, matviews, types, sequences
│   │   ├── indexes.py           ← index stats, usage
│   │   ├── health.py            ← pg_stat_*, vacuum, bloat
│   │   └── replication.py       ← publications, subscriptions, slots
│   ├── builders/
│   │   ├── policy_builder.py    ← CREATE/ALTER/DROP POLICY → SQL
│   │   ├── role_builder.py      ← GRANT/REVOKE/CREATE ROLE → SQL
│   │   ├── trigger_builder.py   ← CREATE/DROP TRIGGER → SQL
│   │   ├── view_builder.py      ← CREATE VIEW / INSTEAD OF → SQL
│   │   ├── function_builder.py  ← CREATE OR REPLACE FUNCTION → SQL
│   │   └── audit_builder.py     ← FDW setup, audit trigger → SQL
│   ├── executor.py              ← safe DDL execution, transaction wrapper
│   ├── admin/
│   │   ├── policy_admin.py
│   │   ├── role_admin.py
│   │   ├── schema_admin.py
│   │   ├── trigger_admin.py
│   │   ├── function_admin.py
│   │   ├── health_admin.py
│   │   ├── audit_admin.py
│   │   └── cron_admin.py
│   ├── templates/
│   │   └── admin/planetary/     ← per-view HTML templates
│   └── static/
│       └── planetary/           ← JS for live SQL preview, editors
└── setup.py

Installation:

# settings.py
INSTALLED_APPS = [
    'django.contrib.admin',
    'planetary',               # adds Planetary section to admin
    ...
]

PLANETARY = {
    'DDL_ROLE': 'platform_ddl',          # elevated role for DDL ops
    'AUDIT_SERVER': 'audit_db_server',   # FDW server name for audit
    'POSTGREST_URL': 'http://localhost:3000',
}

9. The Paradigm in One Sentence

Karen checks the data. Bob secures the database. Senior encodes the rules. Postgres enforces everything. PostgREST exposes it. Next.js renders it. Services handle the side effects. Nobody writes middleware.

Stop Treating Agentic AI Like a Deity (Or Like a Dumb Intern)

Ryo Suwito — Thu, 14 May 2026 06:39:53 +0000

There's a better way — and it starts with sequential derivation.

Happy to be here writing this on a day off. Sometimes the best thinking happens when you're not under pressure. This is one of those thoughts that's been sitting in the back of my head for a while, and I think it's worth sharing with anyone building real products with agentic AI right now.

The Two Camps

If you've been in developer spaces lately — Discord servers, Twitter threads, Reddit arguments — you've noticed that the dev community has split into two very vocal camps when it comes to agentic AI.

Camp One: The Deity Worshippers.
These are the devs who hand the AI a vague idea and expect a production-ready app. "Build me a SaaS." They treat the agent like an omniscient oracle. When it fails (and it will), they rage-quit and write a hot take about how AI is overhyped.

Camp Two: The Micromanagers.
These are the devs who've been burned before. They spoon-feed every line, double-check every output, and end up doing more work than if they'd just written the code themselves. The AI becomes a glorified autocomplete, and they wonder why they're paying $20/month for it.

Here's the thing: both camps are wrong. about the workflow.

The Problem Is the Handoff.

Every time I've seen agentic AI fail spectacularly, the root cause isn't the model. It's that the human didn't set the stage properly. We either gave it too much freedom with too little context, or we gave it so much rigid instruction that we killed its ability to be useful.

The real skill is sequencing.

Agentic AI is not a search engine you query once. It's a collaborator you build with — step by step, output feeding the next input, each artifact narrowing the possibility space for the next agent in the chain.

When I figured this out, my development velocity changed. Dramatically.

The Derivation Chain: How I Actually Build Now

Here's my workflow, distilled. I call it the Derivation Chain — every artifact you produce becomes the foundation for the next one. Nothing is created in a vacuum.

Phase 1 — The Foundation (Identity Layer)

It always starts with an idea and a name. But most of us stop there and jump straight to code. That's the mistake.

Instead, I let the name derive everything else:

Name
  └─► Vision & Mission
        └─► Core Values
              └─► Brand Guidelines + Copy Tone & Language
                    └─► Color Palette + Style Guide
                          └─► Component Guide
                                └─► Framework-Specific Best Practices

Every step is a sequential prompt to an agentic AI, and every output becomes the context document for the next step. The AI doesn't guess. It derives.

By the time I'm done with Phase 1, I have a living design system that's coherent from the name all the way down to the button radius. Not because I manually crafted it — because I sequentially derived it.

This is the part most devs skip. And it's the part that saves you the most time later.

Phase 2 — The Problem (Product Layer)

Once the foundation is set, I turn my idea into a Problem Statements file. Not a feature list. Not a backlog. A structured document that clearly articulates:

Who is suffering?
What are they suffering from?
Why do existing solutions fail them?
What would a meaningful resolution look like?

The agentic AI helps me write this, but I drive the content. The AI's job here is to help me think clearly, not to invent problems I don't have.

Phase 3 — The Architect (Solution Layer)

Here's where it gets interesting — and counterintuitive.

Once I have the Problem Statements, I bring in what I call the Unbiased Architect.

The rule is strict: the Architect sees zero existing code.

Why? Because existing code carries compounding mistakes. If your codebase started with a bad architectural decision six months ago, and you show it to an AI and ask "how do we build on this?" — you get solutions built on top of flawed foundations. The AI inherits your tech debt intellectually.

The Unbiased Architect reads only the Problem Statements. From there, it defines the ideal solution architecture: bounded contexts, data contracts, state machines, service boundaries — without being anchored to what you've already built.

The Architect's deliverables:

Problem Statements
  └─► Ideal Solution Architecture
        └─► Domain Models & Data Contracts
              └─► Service Boundaries & Bounded Contexts
                    └─► Agent Bill of Materials

Phase 4 — The Agent Bill of Materials

The last output from the Architect is what I call the Agent Bill of Materials (or Agent Bill Request): a document that defines:

How many agents are needed
The scope and responsibility of each agent
The handoff contracts between agents
The individual guide each agent should operate under

Think of it like a staffing plan — but for AI agents that will execute work in parallel, each with their own bounded domain and clear success criteria.

From this point, the execution phase begins. Each agent gets its own brief and works within its lane. The chaos of "just ask the AI" is replaced by structured, accountable parallel delivery.

Why This Works

The magic of this approach is that it solves three fundamental problems with agentic AI development:

1. Context Coherence
Every document feeds the next. By the time you're writing code, the AI has absorbed your brand, your values, your problem space, and your architecture. It's not guessing your intent — it's operating from a rich, layered context.

2. Architectural Integrity
By separating the Architect from the Builder, you prevent the AI from inheriting and amplifying your existing mistakes. The ideal solution exists independently of the messy reality of your current codebase.

3. Parallel Execution Without Chaos
The Agent Bill of Materials gives each agent a clear scope. Parallel execution becomes possible without agents stepping on each other's work, because boundaries are defined upfront.

The Mindset Shift

The real unlock is this:

You are the Director. The AI is the department.

You don't tell a department head every keystroke to make (micromanagement). You also don't hand them a napkin sketch and say "build the company" (deity worship).

You give them:

Clear context
A defined scope
Outputs from the previous phase as their input
Freedom to operate within those constraints

That's it. That's the workflow.

Practical Checklist

If you want to try this yourself, here's the order of operations:

[ ] Start with a name and idea
[ ] Derive: Vision & Mission → Core Values
[ ] Derive: Brand Guidelines → Copy Tone → Color Palette → Style Guide
[ ] Derive: Component Guide → Framework-Specific Best Practices
[ ] Write Problem Statements (AI-assisted, human-driven)
[ ] Engage the Unbiased Architect (no code access, problem-only context)
[ ] Generate the Agent Bill of Materials
[ ] Execute with scoped agents

Closing Thought

We're in a weird transitional moment. The tools are powerful enough to genuinely accelerate professional development — but most developers are either over-trusting them or under-utilizing them.

The devs who win in this environment won't be the ones who master prompt engineering. They'll be the ones who master workflow design — who understand that agentic AI is most powerful when it operates inside a well-designed sequential system, not as a standalone oracle.

Build the system. Let the AI fill it.

The best ideas don't always come during sprints. Sometimes clarity arrives when you step back.

If this resonated, drop a comment — I'm genuinely curious how others are structuring their agentic workflows.

Tags: agentic-ai devworkflow productivity aitools softwaredevelopment

🎬 "FREE MONEY, THEN WHAT?" A Timeline Nobody Told You About

Ryo Suwito — Mon, 04 May 2026 20:26:26 +0000

Not financial advice. Not doom content. Just... connecting dots.

📌 HOW TO READ THIS

This is a story about money, technology, human behavior, and a very old joke.
It starts with free pizza and ends with... well, you'll see.
Grab a snack. This one's worth your time.

🕰️ CHAPTER 1: THE FREE PIZZA ERA

(2010 – 2018)

Do you remember when Gojek was giving away free rides?

Or when GrabFood had promo codes that made your meal cost literally Rp0?
Or when a new e-commerce app would give you Rp200,000 cashback just for downloading it?

You probably thought: "Wow these companies are so generous."

Here's the thing. They weren't being generous.
They were spending investor money to buy your habit.

Here's how the game worked.

Somewhere in Silicon Valley — or Singapore, or Tokyo — giant pools of money called Venture Capital funds were sitting around, looking for the next big thing.

The pitch was simple:

"South East Asia has 600 million people. Most of them just got smartphones. Whoever owns their daily habits owns the future. Spend now. Profit later."

And the investors said: "Sure. Here's a billion dollars."

So Gojek burned cash. Tokopedia burned cash. Shopee burned cash.
Not because they were bad at business.
Because the strategy was to burn cash on purpose — to make you dependent on their app before you even realized it.

The free rides weren't free.
You were the product being built.

This era had a name in Silicon Valley: "Blitzscaling."
The idea: grow so fast, so everywhere, that by the time anyone else tries to compete, you already own the market.

It worked spectacularly.

By 2018, hundreds of millions of Southeast Asians had smartphones, digital wallets, and the habit of buying things with one tap.

The infrastructure was ready.

Now it was time to sell them something more profitable than pizza.

🕰️ CHAPTER 2: THE LOAN COMES FOR DINNER

(2016 – 2020)

Quick question.

If you had just spent years teaching hundreds of millions of people to trust an app with their money... what would be the most logical next product to offer them?

If you said a loan — congratulations, you think like a fintech CEO.

In 2016, Indonesia's financial regulator OJK officially recognized Fintech P2P Lending — what most people now call pinjol (pinjaman online / online loans).

The promise was beautiful:

"Millions of Indonesians have no access to banks. No credit history. No collateral. We will use technology to give them loans anyway — using their digital footprint as proof of trustworthiness."

Sounds like financial inclusion. Sounds like progress.

And for many people, it genuinely was.

A street vendor who couldn't get a bank loan could now borrow Rp2 million to buy more stock. A young worker could cover a medical emergency without selling their phone.

Real problems. Real solutions. Real people helped.

But there was another group of borrowers showing up too.

Meet the second group.

Young, urban, smartphone-glued.
Just spent three years being trained by apps to buy things instantly.
Now being shown an equally instant way to borrow money.

No branch visit. No salary slip required. No collateral.
KTP + selfie + a few taps = money in your e-wallet in 15 minutes.

The interest rate? Buried in the fine print.
0.3% per day. Which sounds small until you realize that's 109% per year.

But who reads fine print when you really want those concert tickets?

Buy Now, Pay Later arrived at the same time and made it even smoother.

No interest! (if you pay on time)
Four easy installments!
Available right there at checkout — between "Add to Cart" and "Order Confirmed."

The entire point was to remove the moment of hesitation between wanting something and buying it.

And it worked. Beautifully. Terrifyingly.

By 2020, the numbers were already staggering:

93% of Gen Z and Millennials in Indonesia used digital wallets
31% were using Paylater
10% had active pinjol loans

Most of them were borrowing for wants, not needs.
OJK's own data: 65% of pinjol money was spent on non-essential purchases.

Concerts. New phones. Fashion.
FOMO with a payment plan.

🕰️ CHAPTER 3: THE TRAP SNAPS SHUT

(2020 – 2023)

Here's a thing about debt that seems obvious but somehow isn't:

When the loan is easy to get, people forget it's still a loan.

When repayment is spread across tiny installments, the total cost becomes invisible.

When your friend also has four active pinjols and seems fine, it feels normal.

And when the app keeps offering you more credit because you paid last month's on time... you take it.

The psychological mechanism has a name: debt normalization.

It happened slowly, then all at once.

Gen Z, born into a world of digital everything, grew up watching social media show them lifestyles they couldn't afford.

FOMO — Fear Of Missing Out — became a legitimate financial force.
YOLO — You Only Live Once — became a spending philosophy.

"I'll just put it on paylater."
"Everyone does it."
"I'll pay it off when I get my next salary."

The salary came. Another bill was already waiting.

This is where the math starts to break.

Say you have three active paylater/pinjol accounts.
Each month you're paying installments on all three.
Your salary barely covers it — plus rent, food, transport.
So you borrow a little more next month.
To pay the previous month.

Financial experts call this the debt spiral.
The TikTok community later gave it a simpler name.

But we'll get to that.

By 2023, OJK's data showed:

Gen Z and Millennials (age 19–34) held 54% of all pinjol debt — Rp27 trillion
They were also the biggest source of bad debt (kredit macet)
Outstanding bad debt over 90 days hit Rp1.73 trillion in mid-2023 — up 55% from the year before

The official narrative: "These young people have low financial literacy."

True. But also:

They were actively targeted by apps
Marketed to through social media influencers
Given loans before they understood what compound interest meant
And the apps were specifically designed to make saying yes easier than saying no

Low literacy, or high predation?

Both, probably.

🕰️ CHAPTER 4: WHEN THE BORROWERS ORGANIZED

(2023 – 2025)

Here's the old joke:

"If you borrow Rp500,000 and can't pay — YOU have a problem."
"If a million people borrow Rp500,000 and can't pay — THE BANK has a problem."

Someone on TikTok figured this out.

Then they told their followers.
Who told their followers.
Who made memes.
Who made tutorial videos.
Who built communities.

Gerakan Galbay — literally "The Fail-to-Pay Movement" — emerged organically on social media around 2024-2025.

No founder. No manifesto. No political party.

Just millions of people independently arriving at the same conclusion:

"I cannot pay this anyway. And if enough of us don't pay — what exactly are they going to do?"

The content that spread fastest wasn't angry or radical.
It was practical.

TikTok videos titled:

"Daftar Pinjol Aman Galbay" (List of pinjols safe to default on)
"Cara Lepas dari Pinjol Tanpa Takut" (How to escape pinjol without fear)
With hashtags: #salamgalbay (galbay greetings)

Facebook groups like "Solusi Galbay Pinjol Legal & Ilegal" — 10,000+ members.

WhatsApp groups sharing intel: which platforms have no field debt collectors, which ones won't pursue legal action over small amounts, which ones will negotiate.

What was the nuclear threat supposed to be?

SLIK OJK. The credit scoring system.

The official warning:

"Galbay = bad credit score = can't get KPR, can't get car loan, can't get jobs that check credit history."

And for previous generations, that threat worked.
A ruined credit score meant a ruined financial life.

But for this generation?

KPR? First-time homebuyer age in Indonesia is already pushing 40. Dream deferred anyway.
Car loan? Grab exists.
Job that checks SLIK? The informal economy is 59% of the workforce.
Social shame? Hard to feel shame in a 10,000-member community that celebrates your decision.

The gun wasn't loaded.
Or more precisely — they called the bluff, and found out it wasn't loaded.

The industry panicked.

AFPI (the fintech lending association) filed reports with OJK.
They discussed it with the police.
They asked the Ministry of Communications to block the content.

Komisi XI of Parliament demanded OJK intervene.

OJK issued new regulations — raising the minimum borrower age, requiring minimum income of Rp3 million.

All of which were responses to a movement that had already happened.

Meanwhile, the numbers kept moving:

By June 2025, bad debt for borrowers under 19 years old had jumped 763% year-on-year.

21,774 active bad debt accounts in that age group. Up from 2,521 the year before.

A 763% increase.

In one year.

For people who weren't even legally adults when many of them took the loans.

🕰️ CHAPTER 5: THE SHELL GAME

(2024 – 2026)

Here's something the black-suit world doesn't advertise.

When a bank or pinjol platform has too many bad loans on its books, it has options beyond just writing them off.

Option 1: Restructure — give the borrower more time, lower installments. Kick the can.

Option 2: Sell the loan — find a debt buyer willing to purchase the bad loan portfolio for, say, 15 cents on the dollar. The bank takes a loss, but the problem is now someone else's problem.

This is completely legal. It happens everywhere. It has a whole industry built around it.

In Indonesia, the national asset management company PT PPA openly offers this as a service.
They literally advertise: "We assist banks in divesting loans that hinder their operational and financial performance."

And in mid-2024? BBRI, BTN, and KB Bank were simultaneously selling bad asset portfolios to manage their NPL numbers.

After all this, OJK announced: "NPL perbankan masih terjaga."

Bank NPL is still healthy.

Which was... technically true.
Because they moved the garbage off the balance sheet.

Here's the key metric to watch: TKB90.

Every pinjol platform in Indonesia is required to display it on their homepage.

TKB90 = the percentage of loans paid back within 90 days.

A platform showing TKB90 of 97% looks very healthy.

But here's what TKB90 doesn't show you:
What happened to the loans that weren't paid back?

Were they written off? Restructured? Or quietly sold to a third party before they could hit the 90-day mark?

If you sell a loan on day 85, it never enters the TKB90 calculation at all.

The metric measures what's left. Not what was removed.

This game works perfectly.

Until the third-party buyers stop buying.

Which happens when they also can't collect.

Because the borrowers — remembering the old joke — decided not to pay the debt collectors either.

The Galbay community had already crowd-sourced exactly this intelligence.
They knew which debt buyers had field collectors. Which ones didn't. Which ones would negotiate. Which ones would fold.

When the debt buyer's business model breaks...
The bank can no longer offload.
The bad loans stay on the balance sheet.
The real NPL finally appears.
And that number is not the "still healthy" number OJK was announcing.

🕰️ CHAPTER 6: THE CREDIT SCORE LOSES ITS TEETH

(2025 – 2026)

Here's a beautiful irony.

The SLIK OJK system — the supposed guardian of financial discipline — is being quietly dismantled from two directions at once.

Direction 1: Borrowers ignore it.

We already covered this. The Galbay community treats SLIK merah as a badge, not a punishment.

But here's the kicker:

The fintech platforms themselves created the workaround.

Since 2024, major pinjol apps openly market themselves as "no BI checking required."
They use AI to assess you based on:

Your GPS movement patterns
What smartphone you own
How often you shop on Tokopedia or Shopee
Whether you pay your electricity bill on time
The names in your phone contacts (yes, really)

Someone with a completely ruined SLIK score from a state bank default can get approved on ShopeePayLater in 2026 — because the system sees they're an active shopper who always tops up their Grab credits.

The industry built its own bypass lane around the official credit system.
Because it needed the volume. Because the volume is the business.

Direction 2: The sales floor goes blind.

Now here's the part nobody tells you.

The pool of "clean SLIK" young Indonesians is shrinking every month.
More Galbay defaults. More pinjol NPLs recording into SLIK. More young people with Kol-5 (worst rating) on their credit file.

Meanwhile: a car dealership salesperson's commission doesn't shrink along with the clean-SLIK pool.

Their rent is still due. Their kids still need school fees.
Their sales quota from head office? Unchanged.

So what do you do when the "normal" customers are gone?

You start reading the articles on AstraOtoshop.com titled:
"Kredit Motor Tanpa BI Checking 2026: 6 Leasing Solutions for Bad Credit Scores."

Turns out Adira Finance has a "Non-SLIK Special Scheme."
WOM Finance does field surveys instead of credit checks.
BPRS (Islamic banks) offer alternative assessment models.
Pegadaian will take a BPKB as collateral instead of a credit score.

Higher down payment. Higher interest rate. Less documentation. More optimistic "field survey."

The risk doesn't disappear.
It gets repriced and buried deeper in the financial system.

If this sounds familiar, it should.

This is the exact playbook from the 2008 US subprime mortgage crisis.

2007-2008 USA	2025-2026 Indonesia
Subprime mortgages to people who couldn't afford them	Uncollateralized pinjol to people with no income verification
"No-doc" loans waved through by eager brokers	"Non-SLIK" leasing schemes pushed by commission-hungry salespeople
Bad loans packaged, sold to Wall Street	Bad loans sold to debt buyers, off balance sheet
Rating agencies said "Triple-A"	OJK says "TKB90 masih sehat"
Housing prices masked the rot	Galbay movement revealed what was underneath
When buyers ran out: Lehman Brothers collapsed	When debt buyers run out: ???

The 2008 crisis didn't fail because people were evil.
It failed because every individual actor was doing what made sense for their own table:

The mortgage broker needed the commission
The bank needed the volume
The rating agency needed the fees
The investor needed the yield
The homebuyer needed the house

Everyone rational. Everyone local-optimal.
System globally catastrophic.

Sound familiar?

🕰️ CHAPTER 7: THE MARKET KNOWS SOMETHING

(2025 – 2026)

Now we zoom out.

While all of the above was happening at the ground level — the pinjol defaults, the Galbay communities, the SLIK workarounds — something was moving in the stock market that most people didn't connect.

Indonesia's bank stocks started falling.

Not a little. Significantly.

BBRI — the country's largest "people's bank" with the most exposure to small borrowers — fell to its lowest level in 5.5 years in early 2026.

BBCA — the most prestigious private bank, often considered the safest — hit a 5-year low.

BMRI — Bank Mandiri — dragged down alongside them.

And the foreigners?

On a single day in April 2026:

Rp2.1 trillion of BBCA sold by foreign investors
Rp655 billion of BMRI
Rp447 billion of BBRI

In one day.

Net foreign sell-off for the week: Rp2 trillion+ per day, for 6 consecutive days.

IHSG — the main stock index — down 17.81% year-to-date by end of April.

The official explanation was: Trump tariffs. MSCI freeze. Middle East tensions. Weak Rupiah.

All true. All real factors.

But here's the thing about foreign institutional investors:
They don't just read headlines. They read OJK data tables.

The same tables we've been reading tonight.
The tables showing 763% NPL increases for under-19 borrowers.
The tables showing 789,000 monthly default entities in early 2025.
The tables showing bad debt climbing across every credit category — KPR, vehicle loans, credit cards.

They read the numbers. And they left.
Early.
Before the news cycle caught up.

Here's what made it suspicious:

In a normal "risk-off" moment — when investors get scared — they sell stocks and buy safe havens:

Gold (up)
US government bonds (up)
Cash (held)

That's the textbook playbook.

But in April 2026, something weird happened:

Everything fell at once.

Stocks: down
Gold: corrected from a record high above $5,500 to $4,800
Bitcoin: had already crashed 49% from its peak
US Treasury bonds: also being sold off (yields rising = prices falling)

If everything is being sold... what are people buying?

Cash. USD cash specifically.

Not gold. Not bonds. Not crypto.
Just: get me liquid, get me out.

This is called forced liquidation — when someone doesn't sell because they want to rotate into something better. They sell because they need the money.

The global financial system had accumulated so much debt, so many overleveraged positions, that when external shocks hit (war, tariffs, rate uncertainty), everyone needed cash at the same time.

And in that environment, the assets that fall first are the most vulnerable ones.

Emerging market banks with rising NPL exposure?
That's exactly the kind of asset that disappears from portfolios fast.

🕰️ CHAPTER 8: THE PUNCHLINE

(The Full Circle)

Let's go back to the beginning.

2010: A startup raises billions to give you free rides and free pizza.
Goal: build the habit. Own the daily routine.

2016: The same ecosystem introduces instant loans.
Goal: monetize the habit. Own the wallet.

2018-2022: Millions of young Indonesians — financially underserved and socially FOMO-driven — take the loans. For concerts. For gadgets. For experiences.

2023-2024: The loans pile up. Salaries don't keep pace. The spiral begins.

2024-2025: Enough people hit the same wall at the same time that they start talking to each other. A community forms. A discovery is made:

"If enough of us don't pay — what exactly are they going to do?"

2025-2026: The Galbay movement scales. NPLs rise. Banks sell bad loans to debt buyers. Debt buyers can't collect. Bad loans accumulate. Foreign investors — who read the numbers first — quietly exit through the most liquid door available (bank stocks). IHSG falls. Rupiah weakens. Gold falls. Bonds fall. Everything falls because everyone needs cash at once.

And through it all?

OJK: "TKB90 masih sehat. Semua aman. 💪"

The old joke lands differently now, doesn't it.

If you owe the bank Rp500,000 and can't pay — you have a problem.

If 789,000 people owe the bank Rp500,000 and can't pay — the bank has a problem.

If the bank's problem is big enough to show up in OJK statistics — the regulator has a problem.

If the regulator's numbers make foreign investors nervous enough to dump Rp2 trillion per day — the whole market has a problem.

If the whole market falls while gold, crypto, AND bonds fall simultaneously — the global financial system might be having a problem.

Same joke. Different zeros.

🎯 WHAT THIS IS NOT

This is not a prediction.
This is not financial advice.
This is not a call to join any movement or make any particular financial decision.

This is a story about how incentive structures compound over time.

Every actor in this story was rational:

The VC who funded the app
The app that needed growth metrics
The pinjol that needed loan volume
The young person who needed money now
The salesperson who needed their commission
The debt buyer who saw an arbitrage opportunity
The foreign investor who read the numbers and left

Nobody was the villain.
Nobody had the full picture.
The system produced the outcome.

What you can do with this:

✅ Understand why "the market" sometimes knows things before the news does
✅ Understand why official metrics (TKB90, NPL) can look healthy while problems build
✅ Understand why your credit score matters — and also why it's not the only thing that matters
✅ Have a slightly more informed answer when someone asks: "Why is IHSG turun terus?"
✅ Recognize the difference between a short-term market correction and a longer structural story

The story isn't over.

It rarely ends with a single crash.
Usually it ends with a slow, grinding realization — sometimes over years — that what looked like isolated events were actually connected.

The free pizza. The instant loan. The TikTok tutorial. The bank stock sell-off. The gold drop. The empty SLIK databases.

One story. Many chapters.

"Do you know? 🧐"

— End of script —

Production note: This script is based on publicly available OJK data, market data, academic research, and news reporting from 2023–2026. All data points cited are from named sources. This is educational content for general awareness — please consult a qualified financial advisor for personal financial decisions.