• The author is a senior software engineer with a decade of professional experience, primarily focused on web backend development, including settlement processing and accounting systems.
• Historically, the author took pride in their deep domain expertise, debugging intuition, and ability to meticulously design complex systems before writing a single line of code.
• The author experienced a profound realization when their manager noted that while their code delivery speed was excellent, they were taking too long to write up design documents.
• Upon testing a high-performing LLM, the author was shocked to find that the AI could rapidly structure and organize the most complex, specialized logic that had taken them years of sweat and tears to master.
• While human engineers are still fundamentally necessary to pilot the models, review the output, and act as the "human in the loop," the author feels their role has been reduced to that of an "off-the-shelf," replaceable commodity.
• The decline in the perceived value of high-quality, handcrafted technical design has led to a sense of existential dread, making the author feel as though they spent ten years building a skillset that is rapidly becoming obsolete.
• The author expresses profound uncertainty and sadness regarding the future of their software engineering career, feeling trapped in a shifting landscape where their hard-earned specialization no longer differentiates them from generalists.

Hacker News Discussion

• The Leveling of the Playing Field: Commenters validated the author's observation that AI acts as a massive equalizer. A single domain expert paired with an LLM can now scale their output, write documentation, and conduct reviews at a pace that replaces a larger team of specialized human experts, drastically reducing the market premium for deep technical specialization.
• Management Misconceptions and Operational Risk: A major point of discussion centered on the behavior of non-technical leadership. Many managers mistakenly believe LLMs can completely replace engineering talent, leading them to substitute experienced seniors with cheaper juniors to prompt the AI; users warned this will result in long-term architectural debt and severe system maintenance crises.
• The Looming Threat of White-Collar Homogenization: Several users noted that this existential crisis is not unique to software engineering. If software development is disrupted to this extent, almost all knowledge-based, white-collar professions are vulnerable to similar devaluation, shifting the ultimate value away from individual expertise and toward the owners of capital.
• Loss of Cognitive Critical Thinking: Participants argued that outsourcing the initial design phase to AI erodes foundational critical thinking. Because LLMs automatically gloss over omissions with confident assumptions, engineers stop asking hard, preventative architectural questions, shifting the discovery of critical edge cases to much later in the lifecycle.
• A Counter-Perspective on LLM Limitations: Conversely, some engineers disagreed with the author's anxiety, asserting that fields like finance, taxation, and complex distributed infrastructure remain heavily insulated. They noted that AI agents regularly make confidently flawed logic errors, meaning true accountability, edge-case mitigation, and systemic understanding still absolutely require human experts.

大多数系统程序员认为 C 代码中的错误可能导致严重的安全漏洞或系统崩溃。但作者认为在 WebAssembly 环境中，即使 C 代码存在致命缺陷，最坏情况也只是执行失败并抛出异常，这挑战了人们对 C 代码风险的传统认知，暗示 WebAssembly 提供了一种更安全的执行环境。

在软件开发领域，尤其是涉及系统编程时，普遍认为非 C 程序员不应该编写或修改 C 代码，因为这需要深厚的专业知识和经验。然而，作者作为一个非 C 程序员，却自信地编写并发布了包含 C 代码的 WebAssembly 沙盒实现，这挑战了关于专业领域分工的传统认知。

大多数人认为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工作负载的性能需求。

• Introduction and Context: The author reflects on his experiences after being affected by layoffs at Atlassian, where he worked for approximately 8 years. He shares details about the technical architecture he built, key achievements, and non-technical lessons learned to inspire others in similar situations.
• The Interview Process (8 Years Ago):
  • Began with an online coding quiz on HackerRank, which he aced with full marks.
  • The first technical round involved reading a Cloudflare white paper on custom domains for 10 minutes and then answering architectural questions regarding microservices and containers.
  • The second technical round was a live troubleshooting simulation of a real Atlassian incident (an application issue causing a Denial of Service). He also faced questions about latency-based DNS routing.
  • During the values interview, when asked what success would look like in 12 months, the interviewers outlined the need for an internal platform application to provide self-service load balancing for Atlassian dewelopers.
• Building the Open Service Broker (OSP):
  • In his first few weeks, the author built an application adhering to the Open Service Broker API specification to automate infrastructure provisioning in a Kubernetes environment.
  • Internal developers declared their infrastructure requirements using configuration files in version control, which build servers then uploaded to the broker.
  • The system was originally built in Python using the Connexion library (routing based on OpenAPI documents), later migrated to pure Flask, and eventually transitioned to FastPI.
  • The architecture utilized an asynchronous task queue model: FastAPI received requests, pushed task details to AWS SQS, and background workers handled tasks (like creating DNS records or CloudFront distributions) while writing status updates to DynamoDB.
• Transitioning to Envoy Proxy and Sovereign (Control Plane):
  • Atlassian decided to replace expensive corporate enterprise load balancers with Envoy Proxy, an open-source, cloud-native proxy.
  • The author built a custom Envoy management server/control plane named Sovereign (which was open-sourced on Bitbucket).
  • Built with FastAPI, Sovereign pulled dynamic context data from the broker's database and AWS S3 buckets, injected it into templates for Envoy resources (clusters, routes, listeners), and dynamically pushed updated configurations to running proxies over the wire.
• Infrastructure as Code and Image Automation (AMI):
  • The entire proxy infrastructure—comprising around 2,000 proxies across 13 AWS regions—was deployed using AWS CloudFormation templates defining VPCs, subnets, Network Load Balancers (NLBs), Security Groups, and Auto Scaling Groups.
  • To create standardized images, the team used HashiCorp Packer combined with SaltStack (a declarative configuration management tool similar to Ansible or Chef).
  • The resulting AMI had pre-installed and optimized components, including Envoy, network tuning configurations, security hardening layers, and observability agents for logging, tracing, and metrics.
• Mass Migration and Edge Centralization:
  • Following the initial framework setup, the team spent roughly two years migrating major Atlassian core products (Jira, Confluence, Bitbucket, Statuspage) and thousands of microservices behind this centralized edge infrastructure.
  • The platform locked down public exposures; microservices could no longer be accessed publicly by accident. Developers had to explicitly signal intent through the proxy configuration.
  • Centralizing these features saved millions of dollars and massive development time, sparing thousands of developers from having to independently implement features like authentication, authz, or rate limiting on their own backends.
• Sidecar Architecture and Custom Rust Tools:
  • While DDoS protection was offloaded to AWS CloudFront and Access Logs were captured natively via Envoy's HTTP Connection Manager filters, more complex features required a sidecar container model running locally on the proxy EC2 instances.
  • The author personally designed and wrote a custom authentication sidecar container from scratch using Rust ("the Lord's language").
  • Other specialized internal teams contributed separate sidecar containers for authorization and rate-limiting.
• Non-Technical Growth and Professional Lessons:
  • Diplomacy and Conflict Resolution: Working with various managers and diverse personalities for nearly a decade forced the author to dramatically mature his skills in persuasion, mentoring, and navigating interpersonal friction.
  • Code Churn and Long-Term Maintenance: The author notes that building software is easy, but maintaining its malleability over time is hard. Codebases develop highly predictable areas of continuous modification ("code churn"), which serve as code smells indicating growing complexity that must be actively refactored before coupling paralyzes development.
  • Mentoring vs. Training: The author successfully mentored an intern to achieve the highest possible performance rating and a return offer. However, he reflects on mentoring as a highly challenging balancing act—knowing how to guide someone without giving away answers or letting them get overly frustrated—distinguishing it from his everyday engineering strength of breaking down complex system architectures into easily digestible mental models for peers.

Witarist (witarist.com/hire) helps startups hire pre-vetted remote developers fast. Full-stack, backend, frontend, AI/ML engineers. 48-hour onboarding, fixed monthly pricing.

• 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.

• Transition to Zed: The author has switched to Zed (v1) as their primary code editor, praising its sane defaults, fast and responsive performance, great integration with the VS Code ecosystem, and tasteful AI integration.
• The JetBrains Breakup: For years, the author paid ~$85/year for CLion and appreciated its UI, default settings, and powerful debugging tools. However, they decided to cancel their subscription because the IDE became frustratingly slow.
• Specific Technical Frustrations: - Creating a new file triggers a tedious popup and loading screen.
  • Startup and project-switching times are exceptionally sluggish.
  • Remote development features intermittently disconnect on older hardware.
  • Constant, unexpected re-indexing cycles exhaust CPU and RAM resources.
  • The massive on-disk installation footprint makes it unsuitable for older machines.
• Impact on Developer Flow: These combined performance regressions created friction, causing the author to hesitate before opening the editor and ultimately disrupting their ability to enter a productive flow state.

Hacker News Discussion

• Hardware and Environment Variables: Several commenters argue that complaints about JetBrains being slow usually depend on older hardware or a bloated setup packed with third-party plugins. Users with modern machines (like Apple Silicon) report cold start times of just a few seconds, noting that JetBrains IDEs are meant to be kept open all day rather than spun up per file.
• The Pushback Against AI and Bloat: A major pain point among long-time subscribers is JetBrains' aggressive push toward AI features. Commenters express frustration over persistent AI companion sidebars, the "minimalist" new UI (which some claim mimics VS Code and has poor icon contrast), and overall SaaS feature creep meant to justify subscription fees rather than improve core performance.
• The Text Editor vs. Full-Scale IDE Debate: A core disagreement centers around whether it is fair to compare Zed to JetBrains. Proponents of JetBrains argue it is a full-featured IDE with deep indexing and tooling capabilities that a lightweight editor like Zed may never natively match. Conversely, others counter that those features are useless if the resource-heavy footprint disrupts a developer's flow state or causes crashes.
• Alternative Workflows: Many developers mention abandoning full IDEs altogether in favor of highly optimized, lightweight text editors backed by the Language Server Protocol (LSP). Solutions like Neovim, Emacs, and Helix are praised for offering powerful code intelligence and debugging with a fraction of the memory and CPU overhead.

• 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).

Why Senior Developers Fail to Communicate Their Expertise

• Conflict of Interest: Senior developers and business leaders operate in different "loops." The business prioritizes the Speed Loop (reducing uncertainty by getting to market fast), while senior developers prioritize the Stability Loop (managing complexity to ensure the system remains debuggable and reliable).
• Vocabulary Mismatch: Communication fails because developers talk about "complexity" and "technical debt," which sound like excuses to non-technical stakeholders. Stakeholders are focused on "uncertainty" and "growth."
• The "Solution" Frame: To communicate effectively, seniors must frame their concerns as solutions to the business's problems. Instead of saying "no" to complexity, they should offer "something quicker" (reusing existing tools, Google forms, or minimal UI changes) to help the business learn faster without bloating the code.
• AI as a Destabilizer: AI-generated code accelerates the Speed Loop but creates a "complexity explosion" that threatens long-term stability. The senior developer’s role is shifting toward that of an Editor, responsible for extracting stable, scalable logic from the rapid "vomit drafts" produced by AI and junior staff.
• The Proposed Split: A potential workflow involves maintaining two versions of a system: a "Speed" version for rapid experimentation and a "Scale" version that is curated, stabilized, and owned by senior architects.

Hacker News Discussion

• The "World Model" Gap: A top-voted comment argues that true expertise is an internal "world model" or intuition that is inherently difficult to put into words. It isn't just a list of facts but a deeply integrated understanding of how systems behave.
• Recipe vs. Physics: Commenters distinguish between "recipe-following" developers (who use tools without understanding the underlying logic) and "physics-based" developers who understand the fundamental nature of computation.
• The Role of Failure: Discussion emphasized that senior intuition is built primarily through experiencing failures and reflecting on them over many years. This mental shift often happens when a developer stops trying to learn syntax and starts focusing on solving specific visions or problems.
• The "Senior" Title: There was significant debate about whether "senior" is a measure of years (tenure) or actual merit, with many noting that some developers with decades of experience still only follow recipes and lack the "world model" required for true expertise.
• Abstraction Struggles: Some users noted that while they have a "physics-level" understanding of physical sciences (like chemistry or biology), software abstractions feel arbitrary and "anti-physicalist," making it harder for some brilliant minds to build that same level of intuition.

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政策，突显了项目间价值观的差异。

大多数人可能认为工具创建应该独立于使用它的系统，但作者认为工具创建本身也应该是一个可执行的技能。这个观点挑战了传统工具开发与使用分离的范式，主张元编程和自举方法。

令人惊讶的是：尽管JavaScript/TypeScript在前端开发中占据主导地位，但OpenAI选择先为Python提供新的控制层和沙盒功能。这可能反映了Python在AI和机器学习开发中的核心地位，以及OpenAI对其用户群体技术栈的深刻理解，这对许多习惯使用TypeScript的开发者来说可能是一个意外。

1. The Scaling Crisis (Why Reviews are "Dead")

• Throughput vs. Cognition: The fundamental problem is a mismatch in speed. AI agents (like Cursor, Claude Code, or GitHub Copilot) can generate code at a rate 10x–100x faster than a human. If a developer uses an agent to clear 20 tickets in a morning, the human reviewer becomes a permanent, overwhelmed bottleneck.
• The "Rubber Stamp" Failure: In high-volume AI environments, human reviewers stop actually reading the code and start "rubber-stamping" (approving without checking). This creates a false sense of security while letting "slop" (low-quality, redundant, or slightly buggy AI code) leak into the codebase.

2. The Shift to "Spec-Driven Development"

The author posits that the "checkpoint" for quality is moving "upstream." * Reviewing Intent, Not Implementation: Engineers will spend their time reviewing the Specification or the Prompt rather than the resulting lines of code. If the spec is correct and the constraints are tight, the implementation is treated as a disposable artifact. * Natural Language as the New Source Code: The high-level description of a feature becomes the primary source of truth. If a bug is found, the human doesn't "fix the code"; they "fix the spec" and have the agent regenerate the solution.

3. Verification over Review

The traditional manual "looking at code" is being replaced by automated verification loops: * Agentic Testing: Agents are now responsible for writing their own unit tests and integration tests. The human's job is to review the test plan and verify that the tests actually cover the business requirements. * Formal Methods & Type Safety: The article emphasizes using "bounded interfaces" (like Infrastructure-from-Code or strict APIs). When the architecture is strictly typed, the AI is physically unable to make certain classes of errors, reducing the need for human oversight of the "plumbing."

4. The Emergence of "Cognitive Debt"

A primary warning in the text is the rise of "Cognitive Debt"—a state where a codebase is so dominated by AI-generated logic that no single human understands how the entire system works. * Tech Debt vs. Cognitive Debt: While tech debt is "bad code that's hard to change," cognitive debt is "working code that is impossible to reason about." * The New Senior Role: Senior engineers must transition into "System Curators" who manage this debt by enforcing architectural simplicity and ensuring that AI-generated modules remain modular and replaceable.

5. Future Prediction

• 2025: The year human-written code became the minority.
• 2026: The year the "Pull Request" as a human-to-human review ritual officially becomes obsolete in high-performing teams, replaced by automated agent-to-agent validation and human-to-spec oversight.

benchmarking AI against programming eval: discoverability, interpretation, predictability

Origin of the "Cognitive Debt" phrase

• The Complexity Bias: Engineering cultures often reward over-engineered solutions because they provide a more "impressive" narrative for promotion packets and design reviews compared to simple, effective ones.
• Hiring Pitfalls: The problem begins at the interview stage, where candidates are often pushed toward complex distributed systems even when a simple solution is more appropriate, teaching them that "simple isn't enough."
• Unearned Complexity: While complexity is necessary for massive scale or multi-team coordination, many teams adopt "unearned complexity"—sharding databases or adding abstractions for problems that don't yet exist.
• Invisible Virtues: Simplicity is harder to see and appreciate than complexity. Engineers who avoid problems by choosing simpler paths often find their contributions overlooked because there is no "big system" to point to.
• Shifting the Default: To fix this, teams should change the questions they ask in reviews from "how do we scale this?" to "what is the simplest version we can ship?" and reward the deletion of code or the decision to defer unnecessary features.

Hacker News Discussion

• The "Google Sheets" Interview Trap: A popular anecdote in the thread involved a candidate suggesting Google Sheets to solve a spreadsheet-sharing problem. While pragmatic, it led to an awkward "failure" because the interviewer wanted to see software design skills, highlighting the disconnect between business value and interview expectations.
• Interviewers vs. Candidates: Many users argued that if a candidate gives a simple, non-technical answer, a skilled interviewer should acknowledge it as correct and then pivot to a hypothetical scenario ("If we had to build it, how would you design it?") rather than penalizing the candidate.
• Professionalism vs. Compliance: Some commenters believe developers should be "difficult" by pushing back against unnecessary builds to save company resources, while others argued that refusing to engage in a technical interview exercise is a red flag for future collaboration.
• The Cost of "Acting Smart": There was a consensus that "acting smart" (building complex things) is often more financially rewarding than "being smart" (solving the problem simply), leading to a industry-wide "cargo culting" of complex architectures.
• Visible Deletion: Several users noted that the most valuable engineers are often those who delete thousands of lines of code, but that organizations lack the metrics or cultural frameworks to celebrate and promote based on reduction rather than addition.

No, this was never the case.

now a property of the program

To re-iterate: that's how it's always been. Programming languages and compilers are two different things. To conflate them is a category error.

No. Languages are neither fast nor slow. Only language implementations.

• 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

n::: what requirements can you list for programming that increases agency, not automating / replacing it and abstracting it away.

CODE (not the #pkm [[CODE 20200929164536]]

MORAL

'social means to learn everyday programming'

programming as antidote to AI/programming

this.

a, MORAL, as acronym, I came across that somewhere.

interesting, does this review explain, or get the book?

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

It's common enough to wonder about function behavior on null, undefined, etc., so consider "an LSP" (read: editor plugin) that could synthesize these annotations and insert the appropriate disclosure/disclaimer at the head of the function like this.

Amazing that MCP is not funtamental.

5 general rules for good reviews

Rather leave one comment about subtle things, than multiple ones

Tips on making effective code reviews (don't just focus on the diff)

Love this formulation of the classic "actions speak louder than words" wisdowm.

This Hive Chrome extension is called Web3 Switcher. It enables users to easily switch between different Hive frontends. For all Chromium-based browsers.

DeepWiki is an AI tool that creates a searchable wiki for GitHub repositories. So developers can ask for suggestions about their codebase and get code examples.

Hive Rewards SDK is an open-source npm library. To track blockchain earnings. With automatic price lookups and node management. Also fetches earnings over time.

The hive-authentication package guide. Learn how to do user authentication in ReactJS Hive dApps. Get step-by-step instructions for using this coding tool.

A step-by-step guide on integrating the AIOHA login system in a React application. Using Vite, Tailwind, and DaisyUI. Learn Hive blockchain project development.

Do you have display issues on the Hive blogging platform? Specifically regarding the alignment of text and images in blog posts. See these formatting problems. And see if you can help.

Creating a VNC service app using Bolt and Cursor. See the challenges of development. And the struggle to establish a monetization plan. Learn the value of open-source solutions in a market dominated by large corporations. With hope for future sustainability.

Transforming a chaotic navigation bar into a functional component using React Router. While also integrating AIOHA for user authentication. And creating a reusable layout to streamline React app development. The update emphasizes improvements in user experience and code organization. As foundational steps for their ongoing project.

A guide on using path aliases in React and TypeScript projects. To simplify and clean up import statements. Making code easier to maintain. See a step-by-step process for setting up path aliases. Ultimately transitioning from cumbersome relative imports to more readable ones.

How to integrate React Router into a new React application. See the steps to set up routing and create basic pages. While humorously acknowledging challenges faced along the way. Particularly with adding a navigation bar. Join the journey of learning and experimenting with React development today.

For ReactJS projects, you need to learn the useState and useEffect hooks. See the challenges faced while integrating environment variables in a Vite-based React app. With practical progress on the Distriator project. Including the successful integration of hotel room data and a live deployment.

Day 8 of the ReactJS learning journey is about implementing a secure login system using AIOHA and localStorage. Learn the use of AES encryption for storing user data safely. With managing multiple Hive logins. Also, a detailed explanation of the login API integration and data handling processes.

This ReactJS learning journey shows how to create and customize a custom toast component. Complete with various styles and icons. To enhance user notifications. See insights from previous learning days. With humor and enthusiasm for the coding process.

Learning ReactJS to call APIs and implement Context Providers for managing business data. See a new feature in the Distriator project that displays the Hive Power of businesses. Emphasizing the importance of organized code structure and TypeScript for predictable data handling.

Interesting outcome. Rarely (basically never) do you see "it's more verbose to write in $LANG2 what would be written in fewer lines if you were using $LANG1" touted as a positive.

What are overlay SCMs supposed to actually achieve again?

Why should the app even know let alone care about which version of the serialization format is in play?

Does this mean arguments against verbose "boilerplate" languages are going to be given less credence?

For example, the syntactic analysis stage builds a conventional expression tree, but this tree is expressed as objects—instances of various classes relevant to compilation: Class, Method, Message, Selector, Argument, etc. […] The code for these operations is encapsulated inside each object, and is not spread throughout the system so changes are easily made. And all these specialized classes rely heavily on reusable code inherited from more primitive classes like Object, HashTable, Symbol, Token, and LinkedList.

This is an interesting claim, given that one of the common criticisms of the classic, inheritance-heavy style of classic OOP is precisely that it leads to code that is indeed "spread throughout". Adele Goldberg commenting on the legacy of Smalltalk made a well-known quip, "In Smalltalk, everything happens somewhere else."

It's notable that although there many common word sequences between this paper and the later, similarly titled one that appeared in IEEE Software (1984), this passage doesn't appear to be present (based on a quick skim—I could be missing something), and the closest corresponding statements are significantly reworded.

Are they even well-formed hypotheses? That is, are they falsifiable?

Detailed Summary

1. You own your data, in spite of the cloud. <br /> Section summary: <br /> Local-fist software tries to solve the problem of ownership, agency and data lock-in present in cloud-based software, without compromising cross-collaboration and improving user control.

Section breakdown<br /> §1: SaaS<br /> Pros: Easy sync across devices, real-time collab Cons: loss of ownership and agency; loss of data is software is lost.

§2: Local-fist software<br /> - Enables collaboration & ownership - Offline cross-collaboration - Improved security, privacy, long-term preservation & user control of data

§3 & §4: Article Methodology<br /> - Survey of existing storage & sharing approaches and their trade-offs - Conflict-free Replicated Data Types (CRDTs), natively multi-user - Analysis of challenges of the data model as implemented at Ink & Switch - Analysis of CRDT viability, UI - Suggestion of next steps

2. Motivation: collaboration and ownership<br /> Section summary: <br /> The argument for cross-device, real-time collab PLUS personal ownership

Section breakdown<br /> §1: Examples of online collabs<br /> §2: SaaS increasingly critical, data increasingly valuable<br /> §3: There are cons<br /> §4: Deep emotional attachment to your data brings feeling of ownership, especially for creative expression<br /> §5: SaaS require access to 3rd party server, limitation on what can be done. Cloud provider owns the data.<br /> §6: SaaS: no service, no data. If service is shut down, you might manage to export data, but you may not be able to run your copy of the software.<br /> §7: Old-fashioned apps were local-disk based (IDEs, git, CAD). You can archive, backup, access or do whatever with the data without 3rd party approval.<br /> §8: Can we have collaboration AND ownership?<br /> §9: Desire: cross-device, real-time collab PLUS personal ownership

3. Seven ideals for local-first software<br /> Section breakdown<br /> §1: Belief: data ownership & real-time collab are compatible<br /> §2: Local-first software local storage & local networks are primary, server secondary<br /> §3: SaaS: In the server, or it didn't happen. Local-first: local is authoritative, servers are for cross-device.

3.1.1 No spinners<br /> SaaS feels slower because if requires round-trip to a server for data modification and some lookups. Lo-Fi doesn't have dependency on server, data sync happens on the background. This is no guarantee of fast software, but there's a potential for near-instant response.<br /> 3.1.2 Data not trapped on one device <br /> Data sync will be discussed in another section. Server works as off-site backup. The issue of conflict will also be discussed later.<br /> 3.1.3 The network is optional<br /> It's difficult to retrofit offline support to SaaS. Lo-Fi allows CRUD offline and data sync might not require the Internet: Bluetooth/local Wi-fi could be enough.<br /> 3.1.4 Seamless collabs<br /> Conflicts can be tricky for complex file formats. Google Docs became de facto standard. This is the biggest challenge for Lo-Fi, but is believed to be possible. It's also expected that Lo-Fi supports multiple collab.

TBC

I've been considering what it would look like to have state machines / state charts as a direct language primitive. I'm sure there are some out there. Is it actually a good idea? Are variant/enum types with pattern matching enough?

The benefit to ssh-agent is that you only need to enter your passphrase once. If your private RSA key is not encrypted with a passphrase, then ssh-agent is not necessary

Claude 3.7 Sonnet again excels at coding, as verified by multiple teams

About Claude 3.7 Sonnet

In my experience this is also the main benefit of using node.js as your backend. Being able to write your front and backend code in the same language (javascript) removes a switching cost I didn't fully realize existed until I tried node the first time.

speed of development vs. safety

Wrapping my head around what git-backed database would mean, finding it quite cool

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.

This is another way of achieving concurrency (progress made while waiting for other things) besides wrapping the timer's sleep in a separate thread like https://github.com/rubyworks/facets/blob/main/lib/standard/facets/timer.rb does.

App with javascript interview questions

See also Raskin on: * The Woes of IDEs * Comments are more important than code

What Is Tutorial Hell - Related Pages

• Learning is a Never-Ending Process - <q>Continuous learning helps your growth, problem-solving, confidence. Securing your future in a changing world. See why learning is a never-ending process.</q>
• Tutorial Hell (Programming) - <q>In Tutorial Hell (Programming), learners get too dependent on tutorials. For programs, graphics, and related skills. Learn to beat Programmer's Tutorial Hell.</q>
• Getting started with Hive app development - <q>… I don't recommend spending too much time doing tutorials as you will end up in tutorial hell where you just do tutorials but have no idea …</q>
• Taking The Wheel - <q>… tutorial hell by opting to watch a full tutorial or reading the entire blog post. I've found that after I've done so, I feel sad with the knowledge that I …</q>
• Learning web2 for web3 - <q>Simply because I was trapped in a tutorial hell, I don't think I have ever been so confused. I did all these for one year without developing something …</q>

"Tutorial Hell" is where individuals complete numerous tutorials without actually making meaningful progress. The key to escaping Tutorial Hell is to stop doing more tutorials and start building actual projects to solidify learning.

• Who: The author (Coding Defined), professional developers, junior developers.
• What: Facing Tutorial Hell - spending time watching tutorials without making meaningful progress.
• Why: To discuss the negative impact of constantly watching tutorials without implementing what is learned.

• How: The author discusses two concepts of Tutorial Hell

• How it impacts learning

• Why junior developers often fall into this trap

Then, he provides tips on how to escape Tutorial Hell by:

1. Focusing on building actual projects
2. Implementing what is learned from tutorials.

The author also shares personal experiences and examples to illustrate his points.

Tutorial Hell (Programming) - Related Pages

Learning is a Never-Ending Process - <q>Continuous learning helps your growth, problem-solving, confidence. Securing your future in a changing world. See why learning is a never-ending process.</q> What is Tutorial Hell? - <q>Are you asking "What is Tutorial Hell?" It is doing many tutorials without any meaningful progress. Escape Tutorial Hell and start building actual projects now.</q> Getting started with Hive app development - <q>… I don't recommend spending too much time doing tutorials as you will end up in tutorial hell where you just do tutorials but have no idea …</q> Taking The Wheel - <q>… tutorial hell by opting to watch a full tutorial or reading the entire blog post. I've found that after I've done so, I feel sad with the knowledge that I …</q> Learning web2 for web3 - <q>Simply because I was trapped in a tutorial hell, I don't think I have ever been so confused. I did all these for one year without developing something …</q>

• Who: The author (the100) and learners in various fields such as programming, graphics designing, video editing, learning a new language, and cooking.
• What: Discussing the concept of "tutorial hell" where learners become dependent on tutorials and struggle to apply their knowledge creatively.
• Where: Online courses and tutorials found on platforms like YouTube, Udemy, and other websites.
• Why: To caution learners against becoming too reliant on tutorials and encourage them to practice and apply their knowledge independently.
• How: By emphasizing the importance of practicing, building projects, making mistakes, exploring documentation, asking for help, and using problem-solving skills to truly learn and improve in a skill. The author shares their personal experience of falling into tutorial hell and finding success through practical application and problem-solving. The advice given is to follow a tutorial thoroughly before starting to create projects independently.

The post discusses the concept of "tutorial hell". Where learners become overly dependent on tutorials. Without applying their knowledge creatively. Using examples from programming, graphic design, and other skills. The author emphasizes the importance of practicing, making mistakes, and exploring on your own to truly learn and improve.

Programming , the very idea considered harmful. Can software be liberated from programming per se.

https://cryptpad.fr/pad/#/3/pad/view/4ed3203237745f09bf6699a7e71750fe/

TestRPC Related Pages

• Ganache CLI Install - <q>testRPC/ganache-cli testRPC/ganache-cli is a node.js Ethereum client for testing and development of the Smart… by technological.</q>
• Ethereum TestRPC and Tester Client - <q>This provider automatically spins up the eth-testrpc server for you so that you can test your web3.py code against an in memory EVM. This provides lightning …</q>
• Ethereum TestRPC vs. Geth - <q>Ethereum TestRPC vs. Geth explains that TestRPC is a client for testing and developing. While Geth is a full GO language client for connecting to the blockchain.</q>
• TestRPC & Ethereum Smart Contracts - <q>… testrpc. For truffle test, testrpc or geth is required to be run explicitly. Else, you get the following error: $ truffle test Could not connect to your …</q>

Blender Shrinkwrap Modifier Related Pages

Here are some examples of pages about the Shrinkwrap modifier for Blender:

• Get Good at Blender - <q>It's a tough one to make. So I go through the best practice with edge flow and pole placement. We also work with the shrinkwrap modifier. As a quick note, those …</q>
• Blender Shrinkwrap Model - <q>… Blender Shrinkwrap Model Purpose. @buttonm wants to showcase their artwork. And share their creative process by modeling a concept car for …</q>
• Blender Shrinkwrap & Mesh Deformer Modifiers - <q>For tighter clothes such as the croptop and the forgotten arm socks, shrinkwrap … Blender (I'll work that out when I start a …) #blender · #3d · #creativecoin.</q>
• ProgBlog #1 - <q>… Currently, 1 is Krita, 2 is keys I use excessively in Blender … Blender only when sculpting and/or animating … shrinkwrap" (I'm not sure why it …</q>
• June ProgBlog - <q>And fixed up anything that had gone slightly awry from the shrinkwrap which had mostly done its job at least. … Blender doesn't decide to lag massively (I'm not …</q>

Ganache CLI Install Related Pages

• dApp game with Solidity, Truffle, Ganache - <q>So we do a quick few install commands: Compiling & Testing a Smart-Contract. It's really … $ npm install -g ganache-cli (if you don't have installed ganache yet …</q>
• Ganache CLI Smart Contracts - <q>… ganache-cli (to generate fake accounts) Using npm: npm install -g ganache-cli Using yarn: yarn global add ganache-cli 3- Then b…</q>
• Ganache CLI Ethereum - <q>… Truffle Ganache. https://github.com/trufflesuite/ganache-cli. dApps- Decentralized Apps. I just thought about this, in the World of Bitcoin and …</q>
• Ganache CLI Blockchain App - <q>npm install — save ganache-cli mocha fs-extra web3@1.0.0-beta.35 npm install — save solc@0.4.25 npm install — save next@4.1.4 react react-dom. Next.js. If you …</q>

The core software development process

:)

git bisect run ./calc.py 14 0 ← example of running git bisect automatically. * If the commit is good, then the command should return 0; * If the commit is bad, then the command should return anything between 1 and 127, inclusive, except 125; * If it is not possible to tell if this commit is good or bad, then it need to be ignored, and the command should return 125.