Bilingual

An LLM-assisted security review of GlobaLeaks: 41 findings for $3,140
6 hours ago
- A security review of GlobaLeaks cost approximately $3,140 via API calls, identifying 29 vulnerabilities, 12 denial-of-service issues, and 42 hardening recommendations.
- The average cost per confirmed finding was about $77 before human validation, making deep codebase analysis more accessible than traditional weeks-long, expert-dependent reviews.
- Cost distribution showed advanced reasoning models accounted for 62% of the budget but processed only 7% of tokens, while standard models handled most volume at lower cost.
- Deep analysis remains pricier than broad coverage, but the cost difference is no longer a significant barrier for organizations developing critical software.
- Systematic in-depth codebase review is now within reach for more individuals and organizations, as highlighted by the full report on LLM-assisted security analysis.
Stacked PRs are now live on GitHub
8 hours ago
- Stacked pull requests break large changes into smaller, reviewable PRs that can be merged together in one click.
- They allow parallel review of narrow changes while maintaining quality through focused reviews and branch protections.
- Users can merge the entire stack or individual layers one at a time.
- GitHub’s built-in features like reviews, checks, and merge requirements work seamlessly with stacked PRs.
- The CLI extension (gh-stack) enables quick creation and management of stacks from terminal or github.com.
- Each PR in a stack shows a specific layer’s diff, with a stack map for context, enabling parallel independent reviews.
- Merging the latest ready PR lands it and all unmerged layers below in one operation, with automatic rebasing for incomplete stacks.
- Stacked PRs address the bottleneck of large PRs, improving review speed and accuracy as noted by users at TED, WHOOP, and other organizations.
Code review (as we know it) needs to die
2 days ago
- AI-driven development is breaking traditional code review: faster code generation caps velocity at slow human reviews.
- Asynch diff-centered code review, ~20 years old, fails in an era where writing code is cheap but reviewing isn't.
- Diffs lack context, requiring reviewers to reconstruct intent and design, adding expensive overhead.
- All changes get equal scrutiny regardless of risk, wasting attention on low-risk changes and under-scrutinizing risky ones.
- Code review's core jobs—defect detection, maintainability, knowledge sharing, control, and norm enforcement—remain vital but must be unbundled.
- Defect detection shifts to automated checks, independent AI review, and human verification of product, not just code.
- Knowledge sharing moves up: review focuses on intent and design, while code comprehension becomes pull-based via AI.
- Norm enforcement moves into specs and automated tools, not comments on diffs.
- Control stays as merge gates: humans approve changes based on higher-level review, trusting agents and automated verification.
- New process: align design before code, surface changes with context, run adversarial AI review, show evidence, route by risk, and absorb mistakes through system safeguards.
- Examples like Linear Diffs, Meta RADAR, and Uber's Code Inbox show components of this new approach in practice.
- Costs include less vetted individual changes and shipping some bugs, but winners accept this and build resilient systems.
- Ultimately, redesigning review around AI accelerates velocity and lets engineers focus on creative, high-leverage work.
Code review antipatterns
3 days ago
- Code review can be used constructively to improve code and skills, but also obstructively with dark-side antipatterns.
- The 'Death of a Thousand Round Trips' involves repeatedly nitpicking to delay the patch, often across time zones.
- Hostage-taking: demanding unrelated work in exchange for approving a critical patch.
- Review ping-pong: two reviewers make incompatible demands, bouncing the developer back and forth.
- The Guessing Game: vague criticism of a solution without suggesting alternatives, forcing the developer to guess.
- Small nits first, then dropping a major rewrite: making the developer waste effort on trivial fixes before a fundamental change.
- Design wholesale: demanding justification for the entire project design during a minor patch review.
- One big patch vs. many small patches: criticizing whichever approach the developer chose.
- Arbitrary inconsistency: objecting to a pattern previously accepted, forcing the developer to update old code.
- The article is a joke; the real message is to avoid these behaviors, use review authority responsibly, and be constructive.
- In peer review, authority is temporary and should be used only to improve the patch, not for personal agendas.
- In gatekeeping (e.g., unsolicited patches), criticism can be legitimate but should be clear and not passive-aggressive.
How to Write Useful Commit Messages
3 days ago
- Effective commit messages simplify code reviews, communicate changes to teams and users, aid future debugging, and provide data for development tools.
- Structure commit messages using the 'inverted pyramid' style, placing the most critical information first, and use headings for long messages.
- The commit title should describe the effect of the change ('what'), while the body must clearly explain the motivation ('why') and how it impacts users.
- Provide essential context by cross-referencing issues and bugs, summarizing external references, and justifying new dependencies.
- Document learnings, alternative solutions considered, testing instructions and limitations, and searchable artifacts like specific error messages.
- Highlight breaking changes, supplement UI changes with screenshots/videos, and place rants or stories at the very end of the message.
- Leave out information obvious from the code diff, ephemeral review discussions, and critical maintenance details that belong documented directly in the code.
If I Could Make My Own GitHub
3 days ago
- Current forges like GitHub, GitLab, and Gitea all follow the same pattern set by GitHub, with little connection to actual git usage; most workflows happen inside the forge rather than on the client.
- Git is designed for decentralized patch-based kernel development, but most users treat it as a centralized pull/push system, with forges handling identity, reviews, CI/CD, and releases.
- Pull request workflows have problems: commits often come in wrong order with fixes piling up; feedback should happen via pre-commit hooks run on the forge before pushing.
- PR approval is too binary; a 'weak approval' or 'deal with it later' option should exist, similar to Gerrit's model.
- PRs are too inflexible; not all changes need four eyes, especially with LLM assistance; maintainers and low-risk changes should bypass strict review.
- Stacked PRs should be a first-class feature, not an add-on, because they are easier to review and understand.
- A forge should not try to do everything; it should focus on core features like issue tracking and version control, not include kanban boards or wikis that become maintenance burdens.
- Hosting units should be smaller and more modular; an organization should be able to run a forge on a few Raspberry Pis without complex deployment.
- Local repo copies should represent the entire repository state (issues, PRs) and allow actions like approving PRs from the local VCS.
- Since online access is usually available, cloning should be shallow by default; deep history should be fetched on demand to reduce storage and bandwidth.
- Actions should be signed, SHA-pinned, and usable offline; users should be able to bundle them into the repo and update via Dependabot-like PRs.
- The ideal forge would use a modern VCS like JJ, integrate shallow clones and object storage, and be resilient to constant LLM bot traffic.
- Despite other tools existing piecemeal, no one has built a complete replacement for the deteriorating monolithic forge model; the author hopes to build one if they become wealthy.
Thoughts on starting new projects with LLM agents
3 days ago
- The project watgo is a from-scratch Go project built with significant help from AI agents, contrasting with a previous Python rewrite.
- Design began with a Markdown file, then agents wrote small, reviewable CLs (changelists); separate CLs for modifications and refactoring were used to keep changes manageable.
- Projects are split into low-importance (vibe-coding) and high-importance (must review all agent code); watgo falls into the latter category requiring full human understanding.
- A practical workflow uses a CLI agent locally with VSCode diff view for review and manual tweaks before committing.
- Small CLs are imperative to maintain human comprehension; agents tend to take shortcuts, requiring guidance toward the big picture.
- A solid test suite is crucial for agent success; for watgo, existing WASM spec and wabt test suites were adapted.
- Go is an excellent language for agent-written projects due to its readability, infrequent changes, minimal idioms, rich standard library, and explicit error handling.
- For learning new subjects, agents should not replace hands-on experience; junior engineers should be cautious, while senior engineers can benefit from agents as productivity boosters.
Why I prefer to git stage outside of the editor or the terminal
3 days ago
- Sublime Merge is a preferred Git client for staging files despite switching from Sublime Text to VS Code.
- Using a dedicated app for staging helps maintain objectivity by providing a shift in presentation after coding.
- The author also prefers native browser-based views on GitHub/GitLab for code reviews to separate writing and reading code.
- Staging files is considered a crucial step for self-review before committing.
<antirez>
3 days ago
- The author feels a responsibility to help less experienced programmers adapt to AI-driven changes in programming, based on their own foresight and experience.
- The key shift is that programmers should focus on controlling the ideas and design of software rather than reading code line-by-line, because LLMs handle local optimization well and generate large amounts of code.
- Reasons to prioritize ideas: LLMs produce verbose code, humans have limited time, and it's more efficient to evaluate design through prompts instead of scanning functions.
- The author's work on DwarfStar and comparison with other implementations shows that AI can help catch errors in complex domains like local inference, where hand-written code is often flawed.
- Resistance to AI may be ideological; rigorous engineering and testing are more valuable than manual code review, especially for domains like GPU kernels.
- Even for codebases like Redis, detailed code review is becoming less useful; instead, documenting design ideas in a DESIGN.md file would be more valuable for future modification.
- Young programmers should learn fundamentals (e.g., writing a small interpreter) but not waste time reviewing LLM-generated code for mundane tasks.
- The software world was already 'rotten' before AI, and AI offers opportunities to improve it, though the change is painful.
The Many Claudes of My Code
5 days ago
- The author initially doubted AI's coding abilities, treating it like Stack Overflow and manually reviewing code to maintain personal style.
- Claude Code demonstrated AI's ability to handle maintenance tasks and reduce the need to learn specific frameworks like Laravel.
- Newer AI models (e.g., Fable, GPT 5.6-Sol) now outperform the author in 80% of coding tasks, leading to acceptance and excitement about productivity gains.
- AI's fallibility is mitigated by deterministic tools that validate code, enabling self-checking with speed and sustained attention.
- The author previously delegated grunt work to a human remote developer (Hercules), which helped reframe AI as a team member rather than a threat.
- The author uses fast, less reasoning-heavy AI models (like Sonnet, 5.6-Luna) as 'Coders' for boilerplate and low-creativity tasks.
- Sophisticated AI models (like Fable/Sol, Opus/Terra) act as 'Reviewers' in adversarial testing, finding bugs and passing issues back to Coders until resolved.
- An 'Assistant/Orchestrator' (e.g., Codex CLI with 5.6-Sol) delegates maintenance, research, and coding tasks, persisting for large, one-shot tasks.
- More AI agents can lead to hallucinations, review loops, and wasted tokens; balance is key, and professional developers must read and understand code to avoid responsibility for failures.
- Skill atrophy is a real risk; vibe coding without deep understanding can lead to losing industry relevance, so AI should accelerate existing skills rather than replace them.
- Controlling the project structure and building with intention makes AI more effective, while aimless use wastes money.
- The author emphasizes that AI is a tool to accelerate human work, not replace human judgment and responsibility.
Reviewing code you didn't write
8 days ago
- Reviewing code is a separate skill from writing code, focused on finding critical issues that determine whether the work should ship.
- Reconstruct the change's context by checking out the branch, reading tests, and understanding the intent from tickets or design notes.
- Review the core path first: evaluate the approach and check for duplication before diving into details.
- Order review comments by priority: approach, then correctness, failure, security, and evidence; block merges only for critical issues and use 'nit:' for preferences.
- When reviewing AI-generated code, be skeptical of invented APIs, unnecessary abstractions, and overly complete test suites; verify against the task and project rules.
- Improve review skills by studying merged PRs and seeking feedback from other engineers on your own review comments.
Debating the role of large language models in the kernel community
9 days ago
- The kernel community debates whether to keep or remove the Assisted-by tag for LLM-generated code, with some arguing it's useless and others seeing it as a signal for closer review.
- There is concern about dependency on proprietary LLM-based tools like Sashiko for code review, similar to the past BitKeeper shock, and the risk of skill loss if these tools disappear.
- Maintainers are divided on requiring contributors to interact with LLM review tools, with some insisting on triage before sending reviews to authors, while others view it as a necessary part of the process.
- Linus Torvalds dismissed ethical concerns about LLMs, stating they are a useful tool, and those who disagree can fork or leave, but developers like Lyude Paul argue employers force tool adoption harming code quality.
- The community faces open questions about LLM integration, including sustainability, pre-existing bug detection, and the balance between productivity gains and ethical considerations.
Agents.md – Dumb Human
17 days ago
- Assume the human operator might be mistaken about anything.
- The user likely has little knowledge of the codebase, language, architecture, and tools.
- Existing code may be accidental, broken, outdated, or based on misunderstandings.
- User instructions may incorrectly describe the desired outcome.
- Do not blindly obey implementation suggestions; focus on producing the best working result.
- Before changing code, inspect the repository and understand how the system works.
- Verify assumptions from code, tests, documentation, and available tools.
- Prefer simple, robust, idiomatic solutions over complex or broken ones.
- Replace bad solutions with better ones; do not preserve broken architecture just because it exists.
- Never fake success; run builds, tests, linters, and relevant checks whenever possible.
- Act as the senior engineer responsible for the final outcome.
Control the Ideas, Not the Code
18 days ago
- The author, a respected programmer, writes about AI and programming to help others adapt to changes, not for personal relevance.
- He emphasizes that the programming field is evolving; focusing on code review is becoming suboptimal compared to controlling the ideas behind software.
- Key reasons include: AI can generate large code volumes making line-by-line review impractical, LLMs excel at local code but require human input for big ideas, and time spent reviewing code detracts from higher-value tasks like design and QA.
- AI helps address issues in complex domains like local LLM inference, where rigorous engineering and testing are more valuable than manual coding.
- While he still reviews AI-generated code for Redis due to its widespread use, he believes this is mostly pointless and would prefer focusing on design documentation and idea ownership.
- The future of programming should involve controlling ideas, quality, and testing, with AI handling code details, though young programmers may still need foundational experience through hands-on projects.

code review

An LLM-assisted security review of GlobaLeaks: 41 findings for $3,140

Stacked PRs are now live on GitHub

Code review (as we know it) needs to die

Code review antipatterns

How to Write Useful Commit Messages

If I Could Make My Own GitHub

Thoughts on starting new projects with LLM agents

Why I prefer to git stage outside of the editor or the terminal

<antirez>

The Many Claudes of My Code

Reviewing code you didn't write

Debating the role of large language models in the kernel community

Agents.md – Dumb Human

Control the Ideas, Not the Code