Made a couple of updates to my saas foundation template - inngest installed by default - all apps need background processing pretty much. especially with AI these days (everyone wants some kind of LLM based feature, and those are best kicked off to background jobs) - invitations can be shared via links, so email setup not required. I previously set it up so that you needed an email service setup to send out invitation links. But its painful to always need that, especially when getting started out, and sign ups for those start around 20 usd/month, so an unneccerary expense as well. Sharing an invite link with someone is just as good I think, and way smoother to get started with

I've been thinking about how to automate code reviews and deploys via agents. I think that in order to do that, you need to come with categorizations schemes that allow you to decide how to proceed with next step. Imagine we want to automate both "approval" of the pull request, as well as whether it can actually be "deployed without human review". Those are separate because even though a pull request might be considered ready, it might contain high risk updates, in which case you want a human reviewer in the loop. For first part, you want each issues that is raised in the code review to have a category assigned to it e.g Criticial/Major/Minor/Nit. And anything above certain category, e.g Major and above is Blocking, and the PR cannot be fixed till those are resolved. Because the agents always come up with issues, so you need a way to cut-off once a PR is "good enough", and so the categories can help with that. This also allows an agent reviewer and an agent coder, so they have an agreed on "spec" for how to get code over the line. If automating the coding part also, to stop an infinite review cycle, you could hand off to a human if the review cycles goes beyond say three loops. For the "Deployable" part, the review agent can also assign a "Required Human Approval" flag, based on adding categorizations around "Deployment Risk" of the feature, and "Blast Radius". It can score each of these based on a set of provided categories, and we can use its answers in the build pipeline to see whether we can get this pull request auto-merged or not. It can be done over time also. So we never auto-merge to start with, but give some time to review how the agent is categorizing pull requests, and maybe updating our review prompt as well. But we can image we will reach a time where we are start to feel confident enough in the agents scoring of the PRs, and at that point we can start letting code be deployed without human review. The main idea here is that our review agent needs to create categorizations against each issue, and on the PR as a whole, so we have something concrete to make decistions against at each round.

Designer I spoke is now responsible for creating the code for their own designs. They have been setup with the code base on local (docker, all that) Claude Code desktop to create their designs and components in the app Claude code to create the Pull Request Claude Code to resolve feedback on pull request from the devs. And that's it done None one line of code written by the designer. All over chat. I was saying earlier, code generation is going to start moving over to non dev roles - think designers, product managers, business analysts And top management are pushing for this heavily as they see this as a massive opportunity to reduce their cost base in terms of needing developers

Convex just raised 57M This great agentic app builder called Hercules use Convex in the backend Convex provides a full typescript serveless backend that provides a runtime for funtions, as well as a database. It also provides file storage and other services. So that's like a full backend setup, over one service. Its setup of using functions, queries and mutations means it scales well and builds clean apps even as they get bigger. The agents can understand it easier than maybe traditional systems, and so keep the whole setup looking better. I think these days the focus needs to be on how can we create environments that are easy for agents to build large, reliable and clean code bases in. Convex might be one of those setups. Worth looking into I would say.

People were liking this globe from @robj3d3 canivibecodeit stats page So I added one to Drift - the free and simple web analytics website I launched yesterday.

Just added Drift as a free analytics tool alternative to @canivibecodeit .com

Hi Guys. Im pre-launching here. Want to get a few users to try it out. Free and simple web traffic analytics for your sites. Who needs this? I know I did.

I'm not a testing maximalist my any means I don't write tests on side projects I'm working on I've worked on successful business applications that have done just fine without full test coverage Tests do have their place of course, depending on the size of the product, team and risk tolerance, tests can keep a good ship sailing What I find most interesting in this quote though is "My current strategy is not to read any of the code written by my agents. That's the only way I can take advantage of their productivity. What I do instead is surround the agents with extreme constraints" It's a an interesting angle. Our goal is not to write code, but do provide an environment that agents can write code in well. Tbf, this is just what dev team best practices have been about anyway. Good systems, designs, and tests to make the sure the team writes good code. The speed at which agents write code though has taken this to another level So giving agents that structured environment is now a much higher leverage activity, since their output is so high. Good code structure and design work just as well as "constraints" we can surround our agents with. These all act as the "harness" our agents operate within

Having mostly worked in full stack frameworks like Laravel and Rails, I used to wonder how come the default in javascript land seems to be to string together a group of your favorite packages, and use those instead. E.g in full stack frameworks like Laravel, you get ORMs, auth, validators all out of the box. Having recently put strung together a typescript stack of these packages, and taking the time to learn about each one, one of the benefits of this approach seem more clear now. Each package gets to focus on its own thing e.g -> orms -> prisma -> validation -> zod -> auth -> better auth And that lets them provide great to use libraries and developer experiences, some of my favorite so far tbh In a full stack framework, you get the cohesion of everything working well together, and being pre-selected for you, so you can just focus on the app But if you line up the features and developer experience of these packages against each other, I think the ones coming from the dedicated focus come out better

I got a hunch coding agents are subtly instructed to include tests to increase tokenmaxxing

If your building an app, I recommend using Better Auth v.s Clerk Clerk feels faster initially, but its React components were never that intuitive to me. And then you've got this massive dependency on an external service for loading your users. Better Auth has some really powerful plugins And getting setup with Google Login e.t.c is super easy And their schemas for saving users and auth related tables are really nice. So you might as well learn from that setup that's had a lot of thought go into it. Their base setup is super minimal, and everything gets extended via plugins. Takes a bit of time to understand it all, but well worth it, cause you can handle a lot of use cases after that

Dosn't it suck there are no nice and free tools for measuring web traffic for indie hackers? Even for low traffic sites you are locked in paying like $10/month usually to get the service