dsifry

Just got an alert that we would owe $12 Billion. BILLION. After getting me out of bed and a breathless 15 minutes of investigation, I found: https://health.aws.amazon.com/health/status#billingconsole_1... which notes this is an ongoing issue on Amazon's Global Billing Console.

Thanks for the heart attack, Amazon!

I have been helping people get onboarded with Claude Code and the orchestrator I wrote called Metaswarm [1) and the response has been way beyond my expectations.

But don't take my word for it, try it out for yourself, it is MIT licensed, and you can create new projects with it or add it to an existing project.

[1] https://github.com/dsifry/metaswarm

Some github comments are marked as sctionable, some have threads and suggestions, some are suggestions or are nitpicks. This provides you with a deterministic, reliable red/green approach that you cn use to enforce your policy. Give it a try and you will see how it is much more reliable than using a nondeterministic agent, especially for complex reviews!

Yeah, it is about making sure that EVERY actionable PR comment gets addressed - whwther by fixing, resolving, creating a new issue, commenting that it is a will not fix, or blocking for human review - and then giving you a clear deterministic check you can do to reliably enforce your policy.

Just to be clear - the hook is deterministic, but the subagent running with an mcp server loaded is not - and for medium/large PRs, it can run out of context window or just forget what it is trying to do and get lazy and say 'Everything is good, ready to merge!' when in fact tests are failing or there are still unaddressed PR comments.

I found that it has improved overall code quality significantly, at the cost of somewhat slower velocity. But it has meant fewer interruptions where the ai is just waiting for me, or saying "Everything is ready!" only to find that ci/cd failed or there were clearly existing comments/issues.

Lol, I thought it did a reasonably good job, but to each their own - this was the difference between releasing the project so others could use it with decent documentation, or not releasing and just using it internally. :)

Exactly right!

No, it just prepares the PR - it doesn't automatically merge. That would be very dangerous, imho!

That's EXACTLY right. Ready to merge is an important gate, but it is very stupid to just merge everything without further checks/testing by a human!

Right! It doesn't assume that all comments are actionable, or need to be worked on. However, if you allow anyone to comment on your PRs, it could be a malicious vector. So don't let anyone review PRs on projects that you care about!!!

That's why I intentionally don't have this hooked into an ingest flow - you still get control over what issues/stories you want the agent swarm to work on... Just now, I can know that the code that was written has been reviewed and all comments have been fully addressed!

Yup! Software engineers aren't going to be out of work anytime soon, but I'm acting more like a CTO or VPE with a team of agents now, rather than just a single dev with a smart intern.

Sure, but that mcp still missed actionable comments that are marked as Out of Scope or Outside the PR - and this doesn't require having the context window loss of having another mcp instantiated, either. Anyway, give gtg a competitive look against the mcp - you should be able to see the difference

I did! The issue however, is having a clear, deterministic method of defining when the code review was 'done'. So the hooks can fire off subagents, but they are non-deterministic and often miss vital code review comments - especially ones that are marked in an inline comment, or are marked as 'Out of PR Scope' or 'Out of range of the file' - which are often the MOST important comments to address!

So gtg builds all of that in and deterministically determines whether or not there are any actionable comments, and thus you can block the agent from moving forward until all actionable comments are thoroughly reviewed, acted upon or acknowledged, at which point it will change state and allow the PR to be merged.

Pure awesomeness.

This is awesome.

Just used the service and had a great chat with Chap, one of the founders. There's something qualitatively different when you're talking to someone using voice - it makes it easier to articulate some of the bigger questions that aren't just syntax or "help me debug this" type of questions. Anyway, I think this is a great idea, and love that these guys are making it happen. Kudos.

Of course, that's completely true - and all the more reason to follow your love and passion if you happen to be privileged by luck of birth, family, and genetics. I think that this is true of many HN readers and certainly describes me. I'm incredibly grateful for being born into that lucky circumstance.

And I don't mean to put down people who can't do that because they have to figure out how to stay alive in a war torn country, or figure out how to keep your family from starving.

Thanks for your excellent point.

Just do what you love. Period. I've had times in my life when that was programming - and it got me a long way, and I loved doing it while I did it. Then I felt the challenge of learning how to build a business. So I made a choice, and stepped away from coding, and started pursuing my passion of building businesses. There's nothing wrong with your passions changing - think of it as opportunities to learn new skills.

One of the funny (paradoxical?) results of this is that I've had my eyes opened on things that I'd love to code. So, I've gotten passionate about programming again. Ain't life funny?

You don't need to apologize for being honest and self-examining - you only need to apologize if you aren't following your love and passion.

That's gotta be one of the craziest post titles I've read on HN lately ;-)

Technorati was a side project for me.

The beta message is back in there. Thanks!

Great feedback, you make some very good points. This is, after all, what a beta is all about - to get out there, learn as much as we can, and iterate iterate iterate.

Thanks for being brutally honest, this is just what we want to learn!

Dave

Good point. We actually had the beta label in there, but somehow it got dropped out when we did our final QA. We'll get it back in there.

Thanks for the feedback - we're learning a lot and all feedback and commentary is valuable and useful, so thanks for your comments! We have a team of editors and curators, but obviously we can't cover every place at launch, so we work hard to cover the long tail of destinations algorithmically. What city did you try to build? I will have out content team have a deeper look into it to fix it up.

Regarding attribution, we do use information from sites like Wikitravel and Wikipedia, and there's a References chapter in every book - you can find it, along with the URLs that we used to pull together your book in that section.

Your points are excellent ones, thanks for the feedback! This is just the initial release of the beta to the public, and getting feedback, criticism and suggestions like yours is VERY valuable. Thanks again!!!

Dave

Blog post announcing the public beta, along with a whole raft of informationa bout what it is all about is here:

http://www.sifry.com/alerts/archives/2008/11/offbeat_guides_...

The Team. The more time that I spend building companies (Securemote, Linuxcare, Sputnik, Technorati, and now Offbeat Guides), the more I realize that the single biggest risk is in picking a great team. Get a great team that works together, and you can resolve almost every other problem - competition, product, market, financing, etc.

Pick a poor team, and you can have all the advantages in the world - lots of money, little competition, a killer product, a huge market, and the company will find a way to screw it up.

This was probably the biggest eye-opener for me when I moved from CTO jobs to CEO. It's all about the people, and how everyone works together. Learning leadership skills was incredibly important for me to be able to build and inspire teams.

I've seen both sides of this at all the companies that I started. In my experience, it's far and away the most important factor in a company's success or failure.