d_watt

I think one of the interesting things here is that AI doesn't need to be able build B2B SaaS to kill it. So much of the overhead of B2B SaaS companies is thinking about multitenancy, intergrating with many auth providers and mapping those concepts to the program's user system, juggling 100 features when any given customer only needs 10 of them, creating PLG upsell flows to optimize conversions, instrumenting A/B tests etc...

A given company or enterprise does not have to vibe code all this, they just need to make the 10 features with the SLA they actually care about, directly driven off the systems they care about integrating with. And that new, tight, piece of software ends up being much more fit for purpose with full control of new features given to company deploying it. While this was always the case (buy vs build), AI changes the CapEx/OpEX for the build case.

Regarding the meta experiment of using LLMs to transpile to a different language, how did you feel about the outcome / process, and would you do the same process again in the future?

I've had some moments recently for my own projects as I worked through some bottle necks where I took a whole section of a project and said "rewrite in rust" to Claude and had massive speedups with a 0 shot rewrite, most recently some video recovery programs, but I then had an output product I wouldn't feel comfortable vouching for outside of my homelab setup.

Once we had a slowdown in our application that went unadressed for a couple of months. Using git bisect to binary search across a bunch of different commits and run a perf test, every commit being a "good" historical commit allowed that to be much easier, and I found the offending commit fast.

Looks like after the AI automation rush last year, the leaderboard has been removed. Makes sense, a little sad that it was needed though.

I've released a templatized local development setup using devcontainers that I've crafted over the last year, that I use on all projects now. This post explains the why and links to the project.

It's potentially the opposite. If you instrument a codebase with documentation and configuration for AI agents to work well in it, then in a year, that agent will be able to do that same work just as well (or better with model progress) at adding new features.

This assumes your adding documentation, tests, instructions, and other scaffolding along the way, of course.

They're not directly solving the same problem. MCP is for exposing tools, such as reading files. a2a is for agents to talk to other agents to collaborate.

MCP servers can expose tools that are agents, but don't have to, and usually don't.

That being said, I can't say I've come across an actual implementation of a2a outside of press releases...

Perhaps naive to say, but I think there was the briefest moment where your status updates started with "is", feeds were chronological, and photos and links weren't pushed over text, that it was not an adversarial actor to one's wellbeing.

After converting many of my projects, and helping a couple startups tool their codebases and teams for using AI agents better, these 5 things are what I now do on every codebase I work on.

What do you think the "mistake" is here?

It seems like you're pointing out a consequence, not a counter argument.