• Large context windows are divided into a "smart zone" (sharp, attentive model performance) and a "dumb zone" (where attention drops off and the model begins forgetting details).
• The transition into the "dumb zone" typically begins around 100k tokens, regardless of advertised context limits.
• Coding agents quickly burn through tokens during debugging, file reading, and test runs, accelerating the transition into degraded context areas.
• While vendors advertise massive context limits (e.g., 200k to 2M tokens) as a marketing metric, academic studies (like RULER) and empirical reports confirm effective context is much smaller.
• Agent mitigation tools like "auto-compaction" (summarizing history) often trigger too late and create summarized data using a model that is already experiencing performance decay.
• A more reliable alternative is the "breadcrumb approach": manually opening a new session and passing a self-authored specification to keep the context focused in the smart zone.
• Entire agent workflows can be optimized by structuring data around small, modular artifacts (like PRDs, plans, or sub-agent handoffs) to strictly budget the live session context.

Hacker News Discussion

• Erosion of Engineering Rigor: Users expressed deep concern that LLM engineering has devolved into non-deterministic "cargo culting" and "gardening advice" rather than a rigorous, scientific discipline.
• Determinism vs. Flexibility: Systems engineers noted the cognitive friction of using opaque, non-deterministic workflows, though some find immense value in using LLMs strictly as a translation layer from human text into structured, deterministic tool calls.
• Heuristics Over Theory: Many agreed that the rapid iteration cycle of cloud models prevents deep theoretical understanding, forcing developers to rely on empirical heuristics, benchmarking, and structured constraints (like confining inputs) to ensure reliability.
• Architectural Limitations: Commenters speculated that training long-context windows suffers from a data and compute scaling bottleneck, leading to synthetic fine-tuning that trains models to treat early conversational history as noise.

• Transitioning from standard chat interfaces to autonomous, multi-file AI coding agents can cause API token consumption and monthly costs to skyrocket if left unmanaged.
• Including massive, multi-file codebases in every agent prompt rapidly exhausts context windows and inflates the cost per turn exponentially.
• To code at home without going broke, developers should shift to a modular architecture: isolating components, splitting projects into small modules, and relying heavily on mock data layers.
• Restricting the AI's visibility to a single file or a narrowly scoped subdirectory keeps context tokens low, prevents the agent from making sweeping changes across the codebase, and lowers billing.
• Leveraging free or low-cost tier tools to map out full architectural specs and test files before generating implementation code provides rigid constraints that minimize wasted AI loops.
• Developers can significantly curb expenses by opting for deep-context consumer subscription plans (such as $20 to $100 per month tiers) over uncapped pay-as-you-go API keys when executing heavy agent tasks.

Hacker News Discussion

• The Reality of the Cost "Squeeze": A debate emerged over what constitutes "going broke," with many users noting that standard $20 to $100 consumer tiers are more than sufficient for normal hobbyist workflows and are likely heavily subsidized by AI providers at break-even rates.
• The Culprit Behind Token Bleed: Commenters pointed out that users burning thousands of dollars in API credits are typically running automated pipelines, loading up dozens of Model Context Protocol (MCP) tools, or deploying recursive sub-agents that reload the entire codebase context on every single turn.
• Niche Utility for Unattended Grinding: While continuous, unattended AI coding is rarely efficient for daily tasks, an engineer shared a highly valuable edge case: letting an AI autonomously decompile, reverse-engineer, and rebuild five interrelated legacy firmware images back into recognizable C projects over several hours.
• The Sequential Refactoring Playbook: For managing large-scale modifications, users advocated for a strict, multi-step pipeline: first utilizing AI to ingest code and write unit tests, then breaking the files into tiny, isolated blocks, testing those blocks independently, and only then generating the actual refactored behavior.
• Interruption Management Advantage: A key human-centric benefit highlighted was how agentic setups alleviate cognitive load during family interruptions; a developer can step away for hours and simply tell the agent to catch them up and proceed without losing flow state.

Hacker News Discussion

• The Pull Request Fatigue Loop: A widely upvoted comment highlighted how a colleague using Claude flooded the team with AI-generated PRs, then complained when they languished; reviewers subconsciously avoided them because reviewing AI code for hidden hallucinations requires an immense, asymmetric amount of human effort.
• The Asymmetry of Feedback: Users noted that it feels deeply dismissive when a human invests an hour of intense cognitive effort to thoughtfully review a massive PR, only to receive an instantaneous, AI-generated reply or amendment from the author.
• Review Scalability vs. Guardrails: Some participants argued that traditional code review cannot scale to prolific AI agents or hyper-productive humans; they suggested transitioning to automated guardrails—such as linters, auto-formatters, and robust end-to-end continuous deployment testing—to offset the review bottleneck.
• Code Review as a Cultural Practice: The discussion underscored that code review should function as a collaborative team process for shared understanding and mentorship rather than a cold, adversarial gatekeeper blocking a developer from merging code.
• Exploiting Token Budgets: One commenter observed that large, complex PRs often trigger scrolling blindness in humans and cause LLMs to run out of token budget, leading both to blindly approve the change with a generic "looks good to me."

• Software engineering has a long history of aggressive automation—from assembly to high-level languages—and rather than replacing engineers, every leap in productivity has expanded the scale and complexity of what can be built.
• The demand for software is functionally insatiable; as soon as engineers become more efficient, the organizational goalposts move, leading to higher expectations rather than a reduction in staff.
• Current AI development tools act primarily as force multipliers rather than autonomous agents, meaning that an expert developer is still strictly required to drive, review, and handle the remaining high-value 10% of the work.
• For AI to truly replace software engineers, an autonomous AI system would need to consistently outperform an AI+human developer hybrid team, a milestone that current data and architectures are far from reaching.
• While generalist software engineers remain secure, specific narrow domains or commoditized skill sets (such as basic, boilerplate frontend development) face a heightened risk of being entirely absorbed by AI tools.
• The most significant hurdle for autonomous AI is not initial code generation, but rather the long-term maintenance, context retention, and reasoning required to safely adapt to changing ecosystems and walled gardens.
• Rather than destroying the engineering market, AI changes the underlying economics of production, allowing developers to rapidly clear backlogs, build minor utilities, and focus more on architectural architecture and system design.

Hacker News Discussion

• The Jevons Paradox of Code: Commenters emphasized that increasing the efficiency of software creation lowers its cost, which historically exponentially increases overall demand rather than exhausting the market.
• The Rise of Bespoke Consumer Software: A popular theory suggested that AI will enable everyday users to spin up personalized, ad-free, micro-utilities (like custom todo lists) on the fly, reducing reliance on bloated commercial applications.
• The Tinkering vs. Maintenance Chasm: Several users countered the "bespoke software" future by comparing it to 3D printing; while creating a custom script is easy with AI, the average user lacks the logical thinking and patience required to maintain software over time.
• A Cyberpunk Technological Stack: Users noted that the current trajectory feels reminiscent of science fiction, where individuals possess highly customized, personalized technology stacks modified specifically for their unique workflows.
• B2B Complexity and Standardization: Many participants pointed out that while consumer-facing apps might become fragmented, enterprise B2B infrastructure, distributed systems, and core data layers (like the Linux kernel or banking infrastructure) strictly require human-driven rigor, consistency, and standardization.

大多数人认为AI生成内容的改进主要依靠增加计算量和样本数量，但作者认为真正的进步在于AI能够像程序员一样调试视觉程序。这一观点将AI从内容生成者转变为问题解决者，暗示未来AI的发展方向是编程能力而非单纯的生成能力。

• Data Logged via Proxy: Over a 90-day period, a developer tracked all Claude Code activity using an HTTP proxy to capture full payloads, token counts, and costs directly interfacing with the Anthropic API.
• The Scale: The dataset spanning this study consists of 430 hours of actual work, 6 million input tokens, and a total spend of $1,340 on API costs.
• The Waste Discovery: Analysis revealed that only 27% of the total tokens processed did actual "productive work." The remaining 73% were consumed by nine hidden, automated inefficiency patterns.
• The Solution: By identifying and resolving these nine patterns—each requiring roughly a 30-second fix—productive token efficiency can be increased from 27% to approximately 65% without changing the underlying model or losing functionality.
• The 9 Major Cost Culprits:
  1. CLAUDE.md Bloat (~14% waste): Large, overly dense, or un-optimized systemic instructions files consume massive, unnecessary overhead tokens on every single interaction. Fix: Compress, aggressively prune rules, or split instructions into context-specific modular files.
  2. Conversation History Re-read (~13% waste): Long chat sessions exponentially multiply costs, as message #30 costs 30 times more than message #1 due to processing the entire accumulated history. Fix: Use a structured context-refresh cadence to summarize and discard older, unnecessary messages without losing the current task state.
  3. Hook Injection (~11% waste): Context injected via automated UserPromptSubmit hooks unnecessarily loads extra code and data into the prompt context for tasks that don't require them. Fix: Replace indiscriminate global hooks with conditional triggers that only attach context when explicit keywords or file types are targeted.
  4. Cache Misses (~10% waste): Expired prompt caches (which have a short 5-minute lifespan) force expensive, full-price re-tokenization of the codebase context when work pauses briefly. Fix: Set up an automated low-cost "keep-alive" ping task every 4 minutes to maintain the prompt cache active during active development blocks.
  5. Skill Loading (~7% waste): Inactive or irrelevant scripts (such as loading complex front-end UI design skills during a pure backend task) create up to 13,500 token overheads per command. Fix: Explicitly disable global skill auto-loading and isolate advanced capabilities to dedicated subdirectories or specific active profiles.
  6. Extended Thinking (~5% waste): Leaving the reasoning engine globally enabled forces Claude to burn 3,000+ reasoning tokens on simple commands (like basic camelCase naming changes) where deep logic is completely unnecessary. Fix: Disable extended thinking globally by default and explicitly toggle it on only for complex architectural or bug-hunting queries.
  7. Git Diff Inflation (~5% waste): Unfiltered or massive git diff outputs being fed into the context window when reviewing changes, rather than targeting specific file modifications. Fix: Configure the workflow to stream only targeted file diffs or summary statistics rather than pulling full repository diff text into active prompts.
  8. Directory Map Re-indexing (~4% waste): Redundant and frequent re-scanning of the entire project directory tree structure instead of utilizing cached file maps. Fix: Adjust system configuration to enforce a strict file-map caching policy that limits full directory re-indexing to manual project structural changes.
  9. File Read Overlap (~4% waste): Repeatedly reading the exact same source files multiple times within a short interaction window because the system lacks a localized, short-term memory of recent file states. Fix: Implement a session-level temporary cache structure that prevents the agent from re-fetching un-mutated target files in consecutive turns.
• Debunked Optimization Myths: Lowering costs by switching to a smaller model (like Claude Haiku) for simple tasks only yields a negligible ~3% cost reduction, while aggressively running the /clear command between every minor task proves to be completely counterproductive.
• Actionable Optimization Script: To automatically detect and patch these specific inefficiencies within a local workspace, the text recommends running a dedicated optimization script shared by the author.

大多数人认为GPU编译器已经提供了足够的优化选项，开发者可以通过手动调整获得最佳性能。但作者指出，在当前AI基础设施的竞争环境下，这种观点已经过时，暗示传统方法无法满足现代AI工作负载的性能需求。

• Shift in Role and Passion: The author has stopped writing manual code entirely after nearly two decades as a developer. They realized the actual enjoyment came from software design, architecture, and problem-solving, rather than the mechanical overhead of typing out code.
• The "Toll" of Typing: Writing boilerplate code, null checks, imports, and repetitive logic is characterized as a "toll" paid to bring systemic ideas into reality. AI agents now handle this translation layer entirely.
• New Core Responsibilities: The job has evolved into writing clear specifications, designing robust architectures, orchestrating multiple AI agents, and aggressively reviewing diffs to reject bad implementations.
• The Importance of "Taste": Utilizing AI agents successfully requires profound technical taste. An engineer must understand what to insist on, detect fake test coverage, and identify load-bearing assumptions that are likely to fail.
• Vibe-Coding Warning: Blindly relying on AI to write unread code into unverified systems results in fragile production software. Evaluating code is harder than producing it, meaning AI tools will make bad engineers worse and efficient engineers better.
• Identity and Future Uncertainty: The author admits they would likely quit engineering altogether if forced to return to manual coding. However, they acknowledge unresolved questions regarding how this shift affects the training and hiring of junior engineers who won't build foundational muscle memory.

Hacker News Discussion

• The Skill Disconnect for Juniors: A dominant theme is how junior developers will gain the necessary "taste" and evaluation skills if they completely skip the grueling phase of writing and debugging code manually.
• The Cognitive Load of Code Review: Many commenters argue that reading, auditing, and maintaining AI-generated code is mentally exhausting. They note that debugging subtle, hallucinated logic errors written by an agent is often more difficult than writing the logic from scratch.
• Loss of Mastery and Dependency: Users express concern over the degradation of raw coding skills. Becoming entirely reliant on a fluctuating AI tool stack risks leaving engineers stranded if the quality of the models regresses or changes.
• Analogy to Higher-Level Languages: Several participants view this evolution as a natural continuation of computer science history, comparing the shift to moving from Assembly to C, or from C to Python, where engineers routinely surrendered low-level control for higher abstraction.

• The Problem: Developers using multiple local AI terminal agents (such as Codex, Claude Code, or OpenCode) quickly face fragmentation when trying to manage custom skills, agent roles, and project-specific instructions. Files end up being scattered across varying default directories or duplicated manually across the user's home folders.
• The Solution: A centralized directory architecture within the project repository that acts as a single source of truth (ai/), sharing identical configurations across different AI tools through local symbolic links (symlinks).
• Directory Layout & "Source of Truth":
  • All active configuration files reside inside a single /ai folder, split into /ai/agents (who the model should be—e.g., Architect, Reviewer, Incident Commander) and /ai/skills (how the model performs tasks—e.g., API Review, Security Check, Frontend QA).
• The Symlink Mechanism:
  • Instead of configuring generic home directories (~/.claude or ~/.codex), local tool-specific directories are generated inside the project (.agents/ for Codex and .claude/ for Claude Code).
  • Using terminal commands (like ln -sfn on macOS/Linux or New-Item -ItemType SymbolicLink on Windows PowerShell), symlinks are established to point both .agents/ and .claude/ folders to the exact same /ai sub-directories.
• Key Advantages:
  • Centralization: Establishes a single, distinct source of truth for all AI interactions within the workspace.
  • Tool Compatibility: Seamlessly supplies the exact same data to different AI agents without manual file copying.
  • Team Portability & Version Control: Because Git natively tracks symbolic links, the entire team receives the exact same AI tooling, workflows, and prompts directly upon cloning the repository.

• The Risk of Skill Erosion: The author highlights the danger of automation leading to an engineering skill deficit. Similar to how ORMs or Garbage Collection can distance developers from underlying SQL or memory management, over-relying on AI agents risks creating developers who cannot debug or evaluate AI-generated production code.
• The "Remote Work" Parallel: Drawing an analogy to post-COVID remote work, senior engineers can currently leverage AI effectively because they already possess pre-existing, co-located-style foundational engineering skills. The true challenge lies in how newcomers will develop these baseline skills in an AI-first environment.
• Dual-Track Approach to Coding:
  • Vibe Coding (Internal/Prototypes): For internal productivity tools, quick local prototypes, and automation scripting (e.g., audio manipulation with ffmpeg), the author embraces complete AI delegation, ignoring code quality entirely.
  • Production Engineering: Every single line of AI code shipped to production is reviewed 100%. The author actively aims to write code manually roughly 50% of the time using traditional text editors to maintain sharp, fundamental skills.
• Strategic Leverage of Claude Code:
  • Planning: The author drafts structural plans independently first, then compares them against Claude's suggestions to ensure critical thinking isn't outsourced.
  • Omega Messes: Claude Code is intentionally deployed to write highly isolated, heavily tested components (referred to as Sandi Metz's "Omega Messes") to maximize speed without polluting core architectural layers.
• Reallocating Saved Time: Instead of using a 5x velocity boost to hyper-focus on building a frenzy of unneeded features (which ultimately increases stress and decreases user value), the saved time is strategically spent on deliberate breaks, deep architectural thinking, and vetting the actual product utility.
• Real-World Case Study (Shadow Boxing App): The author details migrating a 5-year-old app from Apple's legacy Speech Synthesis framework to an MP3-based ElevenLabs API approach:
  • Vibe Coded the batch audio processors, silence-removers, and config verification tools.
  • Manually Coded the initial core legacy API refactoring and the user interface layout.
  • Delegated to Claude the tedious edge-case handling for the stateful AudioManager (managing Bluetooth latencies, AirPlay interruptions, Siri, and incoming phone calls).

Summary: Agentic Coding Is a Trap

• The "Orchestrator" Illusion: The industry is pushing "Spec Driven Development" (SDD) where humans act as high-level orchestrators while agents handle implementation. This creates a dangerous distance between the developer and the actual code.
• The Paradox of Supervision: Effective use of AI agents requires expert supervision, yet over-reliance on these agents causes the very skills needed for supervision (critical thinking, debugging, and architectural oversight) to atrophy.
• Atrophy and "Brain Fog": Unlike previous abstractions (e.g., moving from Assembly to C++), AI introduces non-determinism and ambiguity. Experienced engineers report losing their "firm mental model" of applications, making each new feature harder to reason about.
• The Junior Developer Bottleneck: Juniors are being deprived of the "friction" required to learn. Reviewing AI-generated code is only half the learning process; without writing and struggling with code, the next generation of senior engineers may never materialize.
• Inverted Priorities: Traditional coding priorities (Understanding > Standards > Conciseness > Speed) are being flipped by AI, which prioritizes raw speed and volume, often leading to bloated, low-quality codebases.
• Economic and Vendor Risks: Teams are becoming dependent on specific AI vendors (e.g., Anthropic’s Claude). Outages can bring development to a standstill, and unpredictable token costs create "vendor lock-in" for intellectual skills.
• Proposed Solution (Demoted AI Role): Use LLMs as "Ship's Computers" (research and delegation tools) rather than "Data" (autonomous replacements). Developers should remain the primary implementers, manually coding 20-100% of tasks to maintain comprehension.

Hacker News Discussion

• Skill Decay Concerns: Many users echoed the sentiment that "taste" and "discernment" are muscles that require constant exercise. Without the "grunt work," developers lose the ability to judge whether the AI's output is actually good or just "mediocre work that passes the bar."
• The "Liberal Arts" Parallel: One commenter compared the situation to how LLMs affected liberal arts; students can produce passing work without doing the thinking, leading to a collapse in deep understanding and a "pile of software that fails spectacularly."
• The Role of Friction: Discussion touched on how the "friction" of coding—debugging a tricky race condition or refactoring a messy module—is exactly where true expertise is built. Removing that friction creates "hollow" seniors.
• Maintenance Nightmare: There is a fear that agentic coding will lead to a massive "24/7 incremental rollout of pure agentic code," where the complexity grows so fast that no human can actually maintain or monitor the resulting system.
• Counter-Arguments: Some users argued that this is just the "Natural Progression of Abstraction," similar to how we no longer worry about manual memory management in many languages, though others countered that AI is a "probabilistic" layer, not a deterministic one.

• Human-Centric Engineering: Senior engineers emphasize that while AI excels at writing syntax, it cannot replicate the human ability to understand customer problems, business context, and the "why" behind a project.
• Mastery of Fundamentals: Staying relevant requires a deep understanding of core computer science principles (data structures, algorithms, system design), as these allow engineers to vet and debug the often-flawed code generated by LLMs.
• Strategic Tool Adoption: Rather than fearing AI, experienced developers view it as a sophisticated "power tool" or "junior pair programmer" that accelerates boilerplate tasks, allowing them to focus on high-level architecture.
• Emphasis on Soft Skills: Communication, empathy, and leadership are highlighted as "durable skills" that AI cannot automate; being able to bridge the gap between technical constraints and business goals is more valuable than ever.
• The "Judgment" Gap: AI models lack the foresight to predict long-term maintenance costs or technical debt; senior engineers are now increasingly acting as "editors" or "judges" of AI-generated solutions.
• Continuous Adaptability: The consensus is that the role of an engineer is shifting from "writing code" to "solving problems," requiring a mindset that is willing to pivot and learn new paradigms as the tech stack evolves.

尽管Bun项目从AI辅助中受益，但Zig项目坚持其反AI政策，突显了项目间价值观的差异。

benchmarking AI against programming eval: discoverability, interpretation, predictability

• The author identifies two primary personality traits: "The Builder" (focused on velocity, utility, and shipping) and "The Thinker" (needing deep, prolonged mental struggle).
• "Thinking hard" is defined as sitting with a difficult problem for days or weeks to find a creative solution without external help.
• In university, the author realized this ability to chew on complex physics problems was their "superpower," providing a level of confidence that they could solve anything given enough time.
• Software engineering was initially gratifying because it balanced both traits, but the rise of AI and "vibe coding" has tilted the scale heavily toward the Builder.
• While AI enables the creation of more complex software faster, the author feels they are no longer growing as an engineer because they are "starving the Thinker."
• The lack of struggle leads to a feeling of being stuck, as the dopamine of a successful deploy cannot replace the satisfaction of deep technical pondering.

Hacker News Discussion

• The loss of the "clayship" process: Commenters compared coding to working with clay; skipping the struggle means missing the intimacy with the material that reveals its limits and potential.
• The "Vending Machine" effect: Receiving a "baked and glazed" artifact from AI removes the human element of discovery and learning.
• Risk of mediocrity: There is concern that AI guides developers toward "average" or conventional solutions, making it harder to push for unique or innovative ideas without significant manual effort.
• The tradeoff of efficiency: While some view the current era as the best time for "Builders" who just want to see results, many veteran developers feel a profound sense of loss regarding the cognitive depth of the craft.
• Clear communication as a new skill: Some argue that interacting with AI requires a different kind of "thinking hard"—specifically, the need to express creative boundaries clearly so the model doesn't "correct" away the uniqueness of the project.

[[Moral Codes by Alan F. Blackwell]] is open access published by MIT, stored in Calibre

programming as antidote to AI/programming

this.

Moral Codes: Designing Alternatives to AI. By Alan F. Blackwell, repositions AI not as the culmination of programming. Makes me realise that indeed others do tend to treat it as such.

https://doi.org/10.1215/2834703X-12096054

Moral Codes: Designing Alternatives to AI in Zotero

this is a review [[Moral Codes Designing Alternatives to AI Critical AI 20251231154007]]

[[Moral Codes by Alan F. Blackwell]]

Definitely true

Amazing that MCP is not funtamental.

less experienced developers accept more suggeted code (copilot) and benefit relatively versus more experienced developers. Suggesting that the set ways of experienced developers work against fully exploting code generation by genAI.

Programming with LLM = less stress

In a study, students who learned to code with AI made more progress during training sessions, had significantly higher correctness scores, and retained more of what they learned compared to students who didn't learn with AI.

Johnson, Khari. ‘AI Could Soon Write Code Based on Ordinary Language’. Wired. Accessed 21 June 2021. https://www.wired.com/story/ai-write-code-ordinary-language.

Coding skills are a plus but not necessary. Accessibility!...