cognitive debt in AI collaboration

Russell Miles argues developer AI literacy means engineering habitats, not constraining agents JAX London
TL;DW
  • Build habitats for human-AI collaboration, not just constraints on agents—focus on environment supporting all cognition in the room, not harnesses alone.
  • Three types of debt threaten AI adoption: technical debt (recognizable), cognitive debt (loss of understanding), and intent debt (lost purpose)—habitats must address all three.
  • LLMs are amnesiac every session with no emotional context, embodiment, or long-term memory—treat onboarding them like new developers who need full context each time.
  • Habitat engineering has three disciplines: context engineering (making your world knowable), architectural guidance (how you work), and guardrails/affordances (what agents can safely do).
  • The Choice Cartographer surfaces decision stories and patterns in codebases to combat intent debt; Devil's Advocate challenges specs and designs as friction brakes.
  • Remain cognitively sovereign—humans must retain decision authority because AI cannot see politics, understand scar tissue in code, or grasp why systems exist.
  • Future belongs to teams with best habitats, not best models—invest in environment design enabling human-AI cognition collaboration rather than model improvements alone.
  • Post-AI literacy shifts from syntax memorization and code wrangling toward semantics understanding, context capture, prompt composition, and debugging with distributed cognition.
  • Cognitive surrender happens fast when tired—use brakes like Devil's Advocate to stop velocity before understanding is lost; brakes enable going faster overall.

Miles introduces "habitat" (vs. harness) as the frame for human-AI collaboration, built on three disciplines: context engineering, architectural guidance, and guardrails. Demos include Choice Cartographer, which surfaces decision rationale in codebases, and Devil's Advocate, a critical-thinking agent that challenges specs to prevent cognitive and intent debt.

platform longevity by design

PostgreSQL outlasted 40+ databases over 30 years by designing for change, not speed FOSSASIA
TL;DW
  • PostgreSQL survived 30 years and outlasted 40+ databases by designing for change, not by being fastest or easiest.
  • 90% of web frameworks from mid-2000s are obsolete; 60% of infrastructure open-source projects abandoned within 5 years—PostgreSQL is rare exception.
  • PostgreSQL's core design assumption: the database model itself will change over time, enabling long-term architectural flexibility.
  • Extension framework separates stable core from innovation ecosystem, proving new features (e.g., pglogical→logical replication) before bringing into core.
  • Databases that bet on single new models (object databases, XML databases, NoSQL) without conservative approach didn't survive long-term.
  • PostgreSQL adapted to AI era not by becoming an AI database, but by safely adopting AI workloads through pgvector, pgai, and extensions.
  • Managed cloud services and distributed systems challenged PostgreSQL more than competitor databases, yet it adapted through platform flexibility.
  • Databases that specialized narrowly (vector DBs, distributed systems) or got acquired/refocused (Informix, Sybase) faded despite early strength.
  • PostgreSQL succeeded through strong community, stable architecture, and avoiding vendor lock-in—not aggressive marketing or technological dominance.
  • Stagnation is fatal in infrastructure software; PostgreSQL thrived by incremental, conservative evolution paired with extensible innovation ecosystem.

Evans traces PostgreSQL's survival through four computing eras—hierarchical, commercial RDBMS, NoSQL, and cloud/AI—showing how competitors failed by specializing too narrowly or rewriting for trends. PostgreSQL's extension framework absorbed each wave (pgvector, pgAI) without destabilizing the core.

LLM distillation defense failure

Distillation attacks recover 95% of proprietary model performance despite chain-of-thought compression CSharpCorner
TL;DW
  • Distillation attacks achieve 95% performance parity when reconstructing chain-of-thought from compressed reasoning at 50% or higher compression rates using STAR method.
  • Anthropic, OpenAI, and Google detected coordinated distillation campaigns targeting reasoning capabilities; Anthropic alone identified 16 million exchanges across Chinese companies.
  • Models compress reasoning into hashes to prevent distillation, but student models trained on reconstructed reasoning still capture ~30-35% of original thinking via polite prompting.
  • STAR method reconstructs reasoning by combining genuine student trajectories on simple steps with fabricated-but-plausible chain-of-thought for complex steps, circumventing compression defenses.
  • Distilled models inherit all teacher flaws; if all models derive from same source, systematic vulnerabilities propagate across entire ecosystem unchecked.
  • Compression-based defenses create collateral damage: end users pay token costs for anti-distillation measures like fake tool calls without receiving direct benefit.
  • Few-shot prompting with tool-call sequences and asking models to explain actions extracts 25-35% of hidden reasoning without needing jailbreaks.
  • Out-of-distribution generalization succeeds at 50%+ compression: model trained on Python dataset generalizes to C++ tasks using reconstructed reasoning.
  • Training on fabricated chain-of-thought at 0% compression fails; model learns style mimicry instead of reasoning, confirming genuine reasoning traces are essential.
  • Companies deploy multi-layered defenses: reasoning compression, fake tool calls, account banning, and GPU export restrictions, but no single measure prevents sophisticated distillation.

Reconstructing compressed reasoning via few-shot prompting and the STAR method lets attackers train student models to 95% of teacher performance even when only 50% of chain-of-thought is leaked. Validated on SWE-bench; countermeasures like fake tool calls and account banning don't close the gap.

POC-to-production agent gaps

Five gaps that kill AI agents between POC and production: observability, HITL, integration debt CSharpCorner
TL;DW
  • Five core components define production agents: LLM, memory (short/long-term), orchestration/planning, tools, and human-in-the-loop governance—not just LLMs and tools.
  • POC-to-production gap is massive: laptop demos ignore messy data integration, error handling, retries, secret management, and system hardening required in enterprise environments.
  • Accountability layer is critical business challenge: if an agent routes $2M shipment incorrectly, someone must own that decision—'the agent did it' is unacceptable.
  • Operations teams distrust non-deterministic agents that give different outputs for identical inputs; predictability matters more than raw accuracy in enterprise deployments.
  • Inference cost becomes bottleneck at enterprise scale, not training cost; 75% still depend on API-based LLMs with no fallback if services go down.
  • Human-in-the-loop design requires careful calibration: too many escalations and users bypass it; too few and they won't trust it—scope agent tasks to high-error-cost steps only.
  • Guardrails and cost-of-error analysis should gate agent autonomy: break workflows so humans decide high-risk steps (e.g., final loan approval), agents handle low-risk tasks.
  • Observability, state management, and auditability are non-negotiable: trace every agent action for debugging and regulatory compliance; cannot debug what you cannot see.
  • Security and PII handling are existential in regulated industries (healthcare, fintech, banking); must extract sensitive data before sending to LLMs or run agents in sandboxes.
  • Integration debt is massive: agents need tools connecting to SAP, Workday, Salesforce, legacy systems—enterprise historically never trusted software with direct system access until now.

Rajesh Gupta (Scan, ex-Metacoders) demos a supply-chain agent that reroutes shipments and escalates conflicts in hours of build time, then enumerates what breaks at scale: hallucination costs, non-determinism, context limits, PII handling, missing kill switches, and the accountability gap copilot-style thinking ignores.

microservices cost architecture

Wix cuts Kubernetes node count 50% by collapsing 4,000 microservices into shared-runtime host-guest pairs GeeCON
TL;DW
  • Wix runs ~4,000 microservices but most receive low traffic; single-runtime architecture bundles them into virtual monoliths to reduce costs and improve efficiency.
  • Achieved 50% reduction in Kubernetes nodes and 27% CPU, 32% memory reduction by moving from isolated services to host-guest architecture on shared pods.
  • Guest isolation achieved via separate Docker containers; host-guest gRPC communication adds only ~2ms latency, negligible vs. cross-service calls requiring database access.
  • Framework code (~90% of each service) moved to shared host; guests contain only business logic, reducing footprint from ~1.8GB to ~900MB memory per service.
  • Kubernetes daemon sets deploy single host per node (like log scrapers); multiple guest replicas use standard deployments for independent scaling and gradual rollout.
  • Custom deployment tool manages host upgrades across node groups (host-canary, host-1, host-2) separately from Kubernetes to ensure safe gradual rollout of critical infrastructure.
  • Backward and forward compatibility required for host-guest protocol; deploy protobuf changes before logic changes to safely handle staggered host and guest deployments.
  • Nile backend platform with code generation enables smooth migration; developers see no change—services automatically split into guest/host behind the scenes.
  • Framework upgrades deploy once on host instead of 4,000 times; infrastructure team controls centrally, eliminating need to chase service owners for updates.
  • Guest affinity planned: co-locate domain services (e-commerce, bookings, etc.) on same nodes to reduce network hops, improve latency via locality principle.

Wix's Nile platform bundles related JVM microservices as thin "guest" pods communicating via gRPC with a single "host" daemon set per node that owns all framework concerns—data access, Kafka, feature flags. Result: 27% CPU reduction, 32% memory reduction, half the node count across 5 billion daily requests.