The Contenders

I put four popular AI code review tools through their paces, scoring them on features, quality, and pricing (I tend to work and operate startups, so pricing is always front and center).

🥉 Qodo AI PR-Agent (6/15) - The Verbose One

What it does: Catches bugs early and auto-generates PR descriptions right in Github.

The good: Integrates with VS Code, JetBrains, GitHub, and GitLab. Has a generous free tier with 75 PR reviews per month.

The not-so-good: PR descriptions are terribly verbose and usually not very insightful. I know we’re getting to the point where we should be writing and generating content specifically for LLMs, but I’m old-fashioned and still prefer concise, specific insights. To wit, most recommendations here tend to focus on low-hanging fruit rather than deep architectural insights.

Price: Free tier available, then $19/user/month for teams.

Verdict: Good for basic bug catching, but don’t expect deep insights.

🥈 Greptile (9/15) - The Context-Aware One

What it does: AI code reviews that actually understand your entire codebase.

The good: Shows deeper understanding of your codebase than most tools. More insightful feedback that goes beyond simple linting suggestions. Focuses on reducing merge times.

The not-so-good: Limited to GitHub and GitLab integrations.

Price: Flat $30/developer/month with unlimited reviews.

Verdict: Better quality than most, but the price point might make you wince.

🥈 Cursor Bugbot (10/15) - The Bug Hunter

What it does: Specializes in bug detection and security issues beyond basic linting.

The good: Has reviewed over 1 million PRs and found 1.5 million issues during beta. Integrates well with the Cursor editor.

The not-so-good: Can be nitpicky and doesn’t maintain context well across iterations. Separate from main Cursor subscription.

Price: $40/month for unlimited reviews on up to 200 PRs/month.

Verdict: Good at what it does (bug hunting), but the pricing can get expensive if you exceed the basic limits

🥇 CodeRabbit AI (11/15) - The Overachiever

What it does: Real-time, context-aware feedback with conversational chat and line-by-line suggestions.

The good: Users rave about making code reviews 10x faster. Gets smarter over time and provides deep analytics. The conversational interface makes it feel less robotic than other tools.

The not-so-good: The free tier is limited to public repos and basic PR summarization.

Price: Free for public repos, $12/developer/month (Lite) or $20/developer/month (Pro) when billed annually.

Verdict: The clear winner in terms of features and quality. Worth the investment if you’re serious about improving your review process.

The Bottom Line

If you’re looking for the best overall experience, CodeRabbit AI is your winner. It strikes the right balance between features, quality, and price.

Greptile is solid if you need deeper codebase understanding and don’t mind the higher price tag.

Qodo is fine for basic bug catching, but don’t expect miracles.

Cursor Bugbot is worth considering if you’re already using Cursor and need specialized bug detection.

My Take

AI code review tools are getting better, but they’re still not magic bullets. They excel at catching obvious issues and speeding up routine reviews, but they still can’t replace human judgment for complex architectural decisions. Especially as most non-trivial code bases still have enough complexity to require a human at some point in the loop.

The key is finding the right tool for your team’s needs and budget. Start with a free tier if available, and scale up as you see value.

What’s your experience with AI code review tools? Have you found one that actually makes your life easier, or are they all just expensive toys? Drop a comment below!

While I’ve mostly built basic RAG solutions so far as part of the Fractional CTO work I’m doing at TechSight, it was fun taking some time to explore the potential behind graphs and how their inherent structure can improve quality and traceability.

TLDR

• Basic #RAG is always a good starting point and is effective for certain use cases (like specific queries/search)
• The structural nature of graphs can improve RAG by adding a layer of semantics and traceability (the challenge is building out the graph from large unstructured datasets)
• Call ahead to make sure the post-talk bar you go to has Prime so you can watch football :)

Here are the slides, reach out if you wanna chat further!

Here are the slides, reach out if you wanna chat further!

I’ve spent most of my career in tech working with data in all shapes and sizes, more recently in the cloud on AWS. And while I know how daunting AWS can be to knowledge workers across all levels of experience, I felt it was worthwhile to offer a foundational overview of how to build data analytics pipelines on (arguably) the de facto operating system for modern software.

Enjoy! Please let me know if you have any feedback at all!

• Book
• Code

P.S. I promise to get the KnowledgeGraphIndex debugging working with a (much shorter) snippet from Lord of the Rings, apparently trying to create a knowledge graph from a thousand page book can’t be done during a demo (and also cost $80 trying)

• SEC AI
• Code

Wouldn’t it be great if you didn’t have to manually sift through 100-page annual reports for your investments?

Just kidding, you should probably still do that.

But if you want a reading companion that can help you find the answers to quick questions, track trends over many years, or compare multiple competitors in an industry, then check out SEC AI. It’s a simple Q&A chatbot that lets you search for companies by ticker, load one or more SEC filings, and then ask questions of the loaded docs.

For example, let’s get a breakdown of Berkshire Hathaway’s revenue for 2023. First we search by ticker and select Add Filing for the latest 10-k filing:

Next, click Load Docs to selected filing(s) into a local in-memory vector store (powered by Chroma). Finally we ask our question and get a response:

This currently requires an OpenAI API key, however the next version will include model selection as an option with an open-source LLM option to avoid having to provision your own key. I’m especially excited to test this given the recent news that an open-source model surpassed GPT-4 in performance

Next Steps

In addition to testing open-source models, I’d also like to add the following:

• Including investor call transcripts in context
• Generating summary-level reports to focus on specific metrics and financials
• Automating reports based on company-specific prompts via email

Reflections on ChatGPT for Coding

While I’ve built some RAG-based tools in Python using frameworks like LangChain, I had zero upfront knowledge of Streamlit. So I also used this as an opportunity to see just how effective I could be with a brand new framework using mostly ChatGPT and Cursor. While I needed to hit the documentation in a few spots, overall these coding tools got me most of the way there. While this may not be production-ready per se, it certainly provides quick iterative feedback on ideas and gives me a feel for how the app should flow.

Suggestions?

Let me know what you think and if you have any suggestions. Thanks!

You know software with users is like the mule with a spinning wheel. No one knows how they got ‘em, and danged if they know how to serve ‘em!

It’s easy as a team to get distracted by struggles with process, tech debt, and debates over languages and frameworks. You can often forget that the ultimate goal of a software team is to provide a service, specifically by delivering working software. The quality and speed of this service is important (just like an API meeting certain SLAs), and the ultimate goal is to provide value to the software’s end-user that they couldn’t find otherwise.

Most engineers probably won’t attend sales calls or talk to users directly, fine. The quality of their code still impacts those end-users, so that voice of the customer needs to be front of mind in some form as they build out the product.

A previous manager of mine, struggling with a team’s delivery issues, had everyone think through the example of a pizza shop.

Think of our team as a pizza shop. Pizza shops need to deliver quality pizza. They also need to deliver quality pizza in a reasonable amount of time.

If we take forever to make pizzas, customers will leave.

If the pizza we make tastes like shit, customers will leave.

If customers leave, we can’t afford to keep the shop open and we all go home.

Customers don’t care about the oven you used to make the pizza (microservices, kubernetes, Java applets). They also don’t care how the pizza gets delivered (Agile bike delivery or Waterfall waiters). They’re hungry! Just make good pizza, and ask them what they liked and didn’t like!

Understanding this idea from a ground level really helps add perspective to your work. It’s common to feel disconnected from your product when living in abstract architecture land, but the technical decisions you make are important, and have a real impact on how damn good the pizza is.

Here’s some ideas to help break out of the silo:

• Gather feedback quickly and iteratively from customers, rather than build something in isolation for months
• Share that feedback with the entire org, and give engineers a chance to ask curious questions and even interact with customers. Your org should look and feel more like a living laboratory running experiments, not a slow-moving cruise liner
• Use data, not guesses, to figure out what the customer actually uses and where they get stuck
• Focus on the highest leverage points in the product that lead to the highest possible quality and best experience

I’m sure you can think of other principles that rhyme here, but the main point is to keep the focus on the customer.

So take pride in your pizza! There’s always ways to make it better and faster. And that’s part of the fun of building software, we’re never done. Yes, AI will help us immensely. But I bet backlogs and roadmaps still exist in 10 years, so regardless of how fast you run, you can’t leave the customer behind.

Munger was never one to mince words. He knew early on he wanted wealth, not for the material trappings but for the independence it brings (he felt it “uncouth” to send someone an invoice). So he read a lot, figured out what worked, and made a fortune. Meeting Buffett certainly helped but he was well on his way to his goal before that.

I admire this drive for independence because it’s such a rare trait in this world. We tend to live and think in highly regimented, engineered systems (schools, corporations, social media) that incentivize us to act in ways that might not align with our true nature. I know few people who actively (and “successfully”) reject organizational prerogatives and carve out a life they can truly call their own. It’s easier to live life on autopilot, especially with family obligations, and just stay within these systems. As Munger said, “Who’s bread I eat, his song I sing”.

I know, too, that independence is something I highly value, though the realization came to me later in life. I spent most of my school life worried about grades, not always pursuring learning for its own sake.

And then I saw The Matrix.

This was one of those “holy shit” moments where I begin to see reality through a different lens. Like what kind of systems are we currently plugged into, consciously or otherwise? Which thoughts are truly ours, or engineered by our environment? How can we free our minds from these systems? What is identity, really, if “the matrix cannot tell you who you are”?

This helped liberate my approach to learning and thinking, and I’ve been lucky to find and learn from many mentors from the “eminent dead” as Munger liked to say.

I don’t claim to have any answers yet, but that’s the point. You can get further in life not by finding all the answers but figuring out the right questions to ask. I think Munger did that exceptionally well.

I think the best way to honor his life is simply to emulate it (“shamelessly clone” it as his good friend Mohnish Pabrai might say). Learn as much as you can, try to stay rational, and find something useful to do with your life.

Source: Poor Charlie's Almanack: The Wit and Wisdom of Charles T. Munger

Nothing to add.

• bought more $PLTR, $HIFS, $PAR, and $JDC.DE
• fully sold $SNOW to finance the above - not necessarily bearish on $SNOW but felt much more confident in the other names, especially seeing $PLTR in the $7-8 range.
• still keeping an eye on $NICK but not sure what the catalyst would be to get above $5

While I’ve been bullish on $PLTR for a while, it was nice to see its surge amid recent profitability and the AI craze. Even after doubling this year, it’s hard to say it’s overpriced based on the sheer scope and capabilities of its platform (having 2B cash and no debt is a nice kicker too). I’ve been working with LLMs for a while now and it’s clear that operationalizing them will be vastly important, something that AIP seems well positioned to do.

I largely agree with the views Benjamin Miller has been expressing around an eventual recession, and his mid-year letter is a great exposition of those views backed by data (the best views usually are!). I’ll probably ease up on the equity inflows and focus more on Fundrise and other alternative investments in the short-term.

I recently re-read A Man for All Markets, Ed Thorp’s autobiography, and was amazed how much of the insight is still relevant today. I think the most important insight is just how well he designed his life to work on interesting problems and not get stuck in status or money traps like most folks. David Senra gives a great overview of the book in his podcast, showing why he uses Ed’s life as the blueprint for his own.

I’ve used two such tools extensively so far (QuickSight and Superset), and I was surprised to find how easy both were to use for someone as design-challenged as myself. Herein lies a quick review of their functionality (both work well!).

Intro - SEC data-driven portfolio tracker

As a motivating example, I’m using a few simple financial datasets to show off each tool’s capabilities. EDGAR produces quarterly data dumps of all publicly-traded companies in a TSV format. Companies must tag specific fields (e.g. NetIncomeLoss). I added my own portfolio activity and some historical daily price data to build a dashboard showing financial performance, price tracking, and portfolio composition. This afforded me some diversity of chart visuals and non-trivial datasets to work with. Here’s how the tools compare on some core data visualization concepts.

Working with Data - QuickSight (by a hair)

It became clear that with both tools, it’s always simpler to clean and combine data beforehand. While these tools support joins and other ways to massage data, I saved much time by just passing it clean data (reminded me of how to design tables in DynamoDB - think about queries in advance). However, if you choose to do more customization in the tools themselves, you can use custom SQL views (ideally at the source - JDBC for Superset or SQL/Athena for QuickSight).

Caching data seems to be simpler in QuickSight, specifically in relying on SPICE to store a cached version of your data. Superset has this capability using Redis, but this adds a bit more complexity (especially as you are likely hosting Superset on your own).

QuickSight’s come a long way over the past few years, and the biggest techdiff it has is its seamless integration with the AWS ecosystem and some other interesting third-party integrations as well (e.g. Twitter, Github). Despite the slight edge, I didn’t find much difficulty in managing data in Superset, and could use a myriad of ways (simple script, Airflow, hell even dbt) to prep data for visualization in either.

Building Charts - Superset (by a nose)

Both tools offer a wide and growing set of visualizations to use, but I was really impressed to see the full list of Superset plugins (even as far as Mapbox plugins and Handlebars for templating). This, for me, made up for the sometimes clunky interface for building charts. The biggest gripe I still have is that updating a custom dataset after building a chart won’t reflect those changes in the chart builder (you can still manually reference any new fields but this wasn’t obvious).

QuickSight works well and offers a wide set of visuals to choose from, and as you can see it was easy to replicate the work from Superset to QuickSight.

Superset

QuickSight

Embedded Visuals - Tie

Both tools take a bit of finagling to get the initial embedding working, but once up and running it works pretty seamlessly. Not much of a difference here, except that Superset doesn’t have a way to have visual-specific filters on a dashboard (the filters are only global), but that can be worked around pretty easily (SS embed, QS embed)

Measure What Matters

Modern BI tools have come a long way. While there’s dozens to choose from, you can’t go wrong with these two. If you’re cost conscious and not married to AWS, Superset should work great. If your heavy AWS users then you probably won’t mind the incremental cost of a few QuickSight seats given how fast you can design and create its easy-to-use visuals.

Looking to do a deeper dive into $HIFS and $NU in the midst of the banking turmoil to understand how they’re positioned and if there’s any additional opportunity there. Should be fun learnings either way!