The hottest Code Review Substack posts right now

And their main takeaways
Category
Top Technology Topics

Why aren't AI productivity gains higher?

Engineering Enablement • 18 implied HN points • 19 Mar 26
🕹 Technology Code Review
  1. AI does make writing code faster, but coding is only a small part of an engineer’s work, so those speedups only move the overall output a little.
  2. Speeding up code creation exposes or creates downstream bottlenecks — things like code reviews, validation, and handoffs haven’t kept up, so saved time often gets consumed later.
  3. Adoption and impact are limited by social friction, immature tools, skill gaps, and missing implicit context in codebases, so real gains require better workflows, documentation, and team alignment.

The imminent risk of vibe coding

Basta’s Notes • 900 implied HN points • 30 Jan 26
🕹 Technology Code Review
  1. LLMs and AI coding tools tend to take the shortest path and are lazy about cleanup, producing sprawling, poorly tested, and repetitive code that accumulates as “vibe code.”
  2. That sloppy output raises the review burden because authors often don’t fully understand AI-written changes, so reviewers end up doing more work and review fatigue lets problems slip through.
  3. To break the negative feedback loops, teams need process changes and tools: schedule cleanup time, enforce smaller PRs and paired reviews for large changes, and invest in automated review tools without shaming people for using assistants.

Code reviews

Basta’s Notes • 286 implied HN points • 05 Dec 25
🕹 Technology Code Review
  1. Code reviews are crucial for maintaining a clean and efficient codebase. By giving thoughtful feedback, you help improve the team’s overall coding practices.
  2. With the rise of AI in programming, it’s important to not just trust the AI’s output. You need to review and refine its work to make sure it fits well within the overall code structure.
  3. Looking for common issues, like duplicated code, is key during reviews. Small repetitive mistakes can pile up and make the codebase messy, so it's best to address them early.

Life Update: Just Moved to SF Bay Area

clkao@substack • 99 implied HN points • 26 Aug 24
🕹 Technology Code Review
  1. The move to the Bay Area was inspired by a feeling of belonging and the need for a supportive environment for their startup, Recce.
  2. Recce aims to improve the code review process for data-centric software development, addressing new challenges in correctness and testing.
  3. The writer appreciates the help from friends during the move and looks forward to sharing more about their experiences in this new chapter.

Code Reviews, Not Code Approvals

Rethinking Software • 299 implied HN points • 03 Nov 24
🕹 Technology Code Review
  1. Asynchronous communication is key for remote work, allowing people to respond when they can without blocking others. This way, everyone can keep working on their own tasks without unnecessary interruptions.
  2. Traditional code reviews often act more like approvals, which can slow down progress and cause delays. It's better to think of them as a way to give feedback after code is deployed, not as a gatekeeping step.
  3. By changing code reviews to be more like reviews after deployment, teams can keep moving forward. This helps avoid bottlenecks and allows for quicker corrections and improvements in code.
Get a weekly roundup of the best Substack posts, by hacker news affinity:

Edition 30: The SDLC is changing and so will AppSec (again)

Boring AppSec • 69 implied HN points • 22 Jul 25
🕹 Technology Code Review
  1. Software development is changing with new tools, especially those powered by AI. This means that AppSec will also need to adapt to keep up with these changes.
  2. The way we manage software development and security must evolve, focusing on how to handle code prompts and automated reviews more effectively.
  3. As non-developers start writing more code using AI tools, we need to be careful because this code might be less secure. Therefore, engaging with all team members involved in code creation is important.

Why Code Authors Should Have the Final Say on Code Reviews

Rethinking Software • 249 implied HN points • 27 Oct 24
🕹 Technology Code Review
  1. Code authors should have the final say in reviews to respect their expertise and autonomy. This helps them feel like true professionals.
  2. Mistakes in code are common and can be fixed quickly, so allowing authors to make decisions helps them learn and improve.
  3. Not all code needs to be perfect from the start, especially in the early stages of projects. Giving authors the control lets them decide how polished their work should be.

Fighting over Crumbs

Rethinking Software • 99 implied HN points • 30 Dec 24
🕹 Technology Code Review
  1. Many programmers feel like they have no control over their work, which can lead to unhealthy competition for the little power that exists. Instead of fighting for crumbs, they should focus on shared decision-making.
  2. Behaviors like land grabbing and excessive code reviews show that programmers crave autonomy but don't know how to get it responsibly. They need to find better ways to collaborate and share power, rather than hoarding it.
  3. Team leads and committees often create more bureaucracy and slow things down. Programmers should work more as peers, trust each other, and let go of the need for strict control to improve their work environment.

Digging into GitHub Actions

One Thing at a Time • 39 implied HN points • 24 Mar 23
🕹 Technology Code Review
  1. Automate project management and collaboration tasks with GitHub Actions to improve efficiency and code quality.
  2. Integrate GitHub Actions with Project Boards to streamline project management and task tracking.
  3. Collaborate with external teams and services using GitHub Actions to facilitate seamless communication and integration.

Software code reviews, and other empty rituals that waste time

Respectful Leadership • 54 implied HN points • 30 Nov 24
🕹 Technology Code Review
  1. Code reviews take up too much time and energy without giving enough value back. Instead of focusing on comments from reviews, teams should focus on writing tests to catch real problems.
  2. It's better to trust the skills of experienced engineers rather than rely on code reviews. If engineers are good, they won’t need to second-guess each other's work.
  3. Instead of worrying about all possible issues, focus on real problems that can be tested and fixed. Don't waste time on imaginary problems that are unlikely to happen.

The Busy Trap: How to Distinguish Being Busy from Being Productive

Wisdom over Waves • 3 HN points • 06 Mar 24
🕹 Technology Code Review
  1. The bulk of a work item's lifecycle in software development is often spent waiting in queues, not in active development or QA activities, highlighting inefficiencies in the process.
  2. More planning and parallel tasks do not necessarily lead to increased productivity; streamlined processes and effective collaboration are key for true productivity.
  3. Individual busyness does not equate to team productivity; focusing on removing bottlenecks and promoting collaborative efforts leads to faster project timelines and meaningful progress.

What Makes a Code Change Easier to Review?

Engineering Enablement • 4 implied HN points • 23 Feb 24
🕹 Technology Code Review
  1. Change description is crucial for code review, including explaining the motivation behind a change and what is being altered.
  2. Smaller code changes are easier to review and have a higher chance of acceptance.
  3. Commit history matters: a concise, self-explanatory message is preferred, and fewer commits increase the likelihood of acceptance.

Have Gordon Ramsay do your initial code review

Shrek's Substack • 0 implied HN points • 15 Jun 23
🕹 Technology Code Review
  1. Using humor in coding reviews can help remove ego and make feedback more enjoyable. It's like having a friend point out mistakes in a fun way.
  2. Modernizing outdated code is important. Just like using fresh ingredients in cooking, using current coding practices makes your code better.
  3. Clear names and proper documentation are key. Good code should be as easy to understand as a well-labeled recipe.

Improve Kotlin Code Review Part -1

Better Engineers • 0 implied HN points • 28 Mar 23
🕹 Technology Code Review
  1. Kotlin has specific types like Unit and Nothing that help clarify your code. Unit shows a function has no meaningful return, while Nothing indicates a function will never finish normally, like when it throws an error.
  2. Destructuring in Kotlin allows you to unpack data structures easily. You can assign multiple values from a list or map to variables in a single line, making your code cleaner and more organized.
  3. Type aliases in Kotlin let you create simpler names for existing types. This can make your code easier to read and understand by replacing complex types with more descriptive names.

💥 TTW #35: Design Patterns for Resilient Data Pipelines, Constructive Code Reviews, Exciting new features in C# 9 - 12, Async Functions In Python 2.1, Vertical Slice Architecture, ...

Tech Talks Weekly • 0 implied HN points • 31 Oct 24
🕹 Technology Code Review
  1. Data pipelines can be made more reliable by using specific design patterns. This helps in managing data flow more efficiently.
  2. Constructive code reviews are important for improving code quality. They can help developers learn and grow by giving helpful feedback.
  3. Learning about new features in programming languages like C# can enhance your coding skills. It's exciting to see how these changes can simplify tasks in software development.

Improve Kotlin Code Review — Part II

Better Engineers • 0 implied HN points • 23 Apr 23
🕹 Technology Code Review
  1. Using generics in Kotlin allows you to create code that can work with different types, making it more flexible and reusable. For example, you can create a box that holds any type of object.
  2. The 'in' and 'out' keywords help define how generic types can be used, allowing for safer and more organized code. The 'in' keyword is for consuming data, while 'out' is for producing it.
  3. Utility functions like 'applyIf' and 'withNotNull' help you write cleaner code by letting you conditionally run actions only when certain conditions are met or when values are not null.

The Hidden Secrets of Design Patterns: What No One Talks About

Weekend Developer • 0 implied HN points • 22 Jun 24
🕹 Technology Code Review
  1. Understanding design patterns helps in building robust and maintainable software by providing standard solutions to common problems.
  2. Challenges of design patterns include a learning curve, potential overuse, and selecting the right pattern for the context.
  3. To effectively use design patterns, invest time in understanding them, assess if they are necessary, regularly review and refactor code, seek feedback from peers, and document pattern choices.

RDEL #16: What makes a code review useful?

Research-Driven Engineering Leadership • 0 implied HN points • 30 Oct 23
🕹 Technology Code Review
  1. Good code review comments can enhance a coder's skills and lead to better implementation.
  2. Certain factors like the number of iterations and author participation can impact the usefulness of code review comments.
  3. Maintaining a positive tone, having focused conversations, and keeping reviews manageable in size are key to improving the effectiveness of code reviews.

#OpenSourceDiscovery 85: CodeRabbit AI PR Reviewer

#OpenSourceDiscovery • 0 implied HN points • 11 Feb 24
🕹 Technology Code Review
  1. CodeRabbit AI PR Reviewer is an AI-powered GitHub action that reviews code by commenting on relevant code snippets and additional commits.
  2. The AI PR Reviewer offers high-quality contextual review comments and allows discussions with the bot, enhancing developer awareness of code quality.
  3. Though the bot's response to comments may take around 20-30 seconds, it complements human review workflows and enables teams to handle initial code reviews efficiently.

Build it twice

Russell’s Index • 0 implied HN points • 11 Jun 25
🕹 Technology Code Review
  1. Start with a rough prototype to test ideas quickly. Don't worry about making it perfect; just get it to work and learn what you need.
  2. After your first build, take the time to create a cleaner, more polished version. You'll find it's easier because you've already discovered key challenges.
  3. Use your initial prototype as a reference, making it easier to improve and organize your code in a way that others can understand better.

The Art and Science of Testing Smart Contracts

Athena Scale • 0 implied HN points • 20 Jan 24
🕹 Technology Code Review
  1. Smart contracts must be properly tested before being deployed to production to avoid costly mistakes.
  2. Designing the architecture of smart contracts is crucial and ensures all team members are aligned.
  3. Testing on testnet and mainnet is essential to uncover issues and differences between environments.