d_watt

It took 20 years for computers to "add" to the economy.

https://en.wikipedia.org/wiki/Productivity_paradox

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.

I’ve been using some time off to explore the space and related projects StereoCrafter and GeometryCrafter are fascinating. Applying this to video adds a temporal consistency angle that makes it way harder and compute intensive, but I’ve “spatialized” some old home videos from the Korean War and it works surprisingly well.

https://github.com/TencentARC/StereoCrafter https://github.com/TencentARC/GeometryCrafter

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.

I'd think this would work, as the 4 tools listed are about retrieving information to give agents more context of correct providers and modules. Given terragrunt works with terraform directly, I'd think that it would help with it as well, just add rules/prompts that are explicit about the code being generated being in terra grunt file structure / with terragrunt commands.

Aider is definitely in the same camp. Last time I checked, they weren't optimizing for the full "agent infinitely looping until completion" usecase, and didn't have MCP support.

But it's 100% the same class of tool and the awesome part of the unixy model is hopefully agents can be substituted in for each other in your pipeline for whichever one is better for the usecase, just like models are interoperable.

It totally is!

I bias a bit to wanting the agent to be a pluggable component into a flow I own, rather than a platform in a box.

It'll be interesting to see where the different value props/use cases of a Delvin/v0 vs a Codex Cloud vs Claude Code/Codex CLI vs Cursor land.

I personally find figuring out what the product should be is the fun part. There still a need for architecting a plan, but the actual act of writing code isn't what gives me personal joy, it's the building of something new.

I understand the craft of code itself is what some people love though!

Claude max plan has Claude code bundled into the price. $100/month isn't cheap, but the RoI is there for me personally.

The way Claude Code is going is exactly what I want out of a agentic coding tool with this "unix toolish" philosophy. I've been using Claude code since the initial public preview release, and have seen the direction over time.

The "golden" end state of coding agents is that you give it a Feature Request (EG Jira ticket), and it gives you a PR to review and give feedback on. Cursor, windsurf, etc, are dead ends in that sense as they are local editors, and can not be in CI.

If you are tooling your codebase for optimal AI usage (Rules, MCP, etc), you should target a technology that can bridge the gap to headless usage. The fact Claude Code can trivially be used as part of automation through the tools means it's now the default way I thinking about coding agents (Codex, the npm package, is the same).

Disclaimer, I focus on helping companies tool their codebases for optimal agent usage, so I might have a bias here to easily configurable tools.

That's the point of the experiment I'm doing, what it takes to get these things to be able to generate all the code, and I'm just directing.

I literally have not written a line of code. The AI agent configures the build systems. It executes the `go install` command. It configures the infrastructure via terraform.

It takes a lot of reading of the code that's generated to see what I agree with or not, and redirecting refactorings. Understanding how to describe problem statements that are translated into design docs that are translated into task lists. It's still a lot of knowledge work on how to build software. But now I can do the coding that might have taken a day from those plans in 20 minutes.

Regarding startups, there's nothing here I'm doing that isn't just learning the tools of agentic coding. The business here might be advising people on how to do it themselves.

I wonder how much it's self fulfilling, where the developers of the agents are tuning their prompts / tool calls to sonnet.

I'm about 50kloc into a project making a react native app / golang backend for recipes with grocery lists, collaborative editing, household sharing, so a complex data model and runtime. Purely from the experiment of "what's it like to build with AI, no lines of code directly written, just directing the AI."

As I go through features, I'm comparing a matrix of Cursor, Cline, and Roo, with the various models.

While I'm still working on the final product, there's no doubt to me that Sonnet is the only model that works with these tools well enough to be Agentic (rather than single file work).

I'm really excited to now compare this 3.7 release and how good it is at avoiding some of the traps 3.5 can fall into.

It's always been a thing with modes of encapsulating knowledge. The printing press caused the freezing of language, sometimes in a weird place*

Where great documentation was make or break for a open source project for the last 10 years, I think creating new projects with AI in mind will be required in the future. Maybe that means creating a large amount of examples, maybe it means providing fine tunes, maybe it means publishing a MCP server.

Maybe sad because it's another barrier to overcome, but the fact that AI coding is so powerful so quickly probably means it's worth the tradeoff, at least for now.

*https://www.dictionary.com/e/printing-press-frozen-spelling/

Looks super interesting. Any positioning thoughts on this vs https://jitsu.com ?

I mean, having a web, worker, cache, db, and search as separate things doesn't seem that crazy?

While of course you can often get away with just a web with sqlite, pretty much any company of scale I've been at maintain those all as separate things, with separate search as the most optional.

What do you feel about the setup described seems overly complicated?

I think this is mostly because that's out of scope of responsibility of docker, and docker compose (for the most part) is only a local dev tool without prod concerns.

For deploying docker containers to production, and how to manage secrets, you'd need to look to that container orchestrator's recommendations. EG K8S secrets. It doesn't make too much sense to put an example of how to use production secrets in a docker guide, because those belong in a K8S/GKS/EKS/DO etc tutorial.

Docker's "interface" is how to accept env variables, it's other parts of the system that need to set those variables.

I don't think I agree with this. Docker is an amazing tool, I've used it for everything I've done in the last 7 years, but this is not how I'd approach it.

1. I think the idea of local-equal-to-prod is noble, and getting them as close as possible should be the goal, but is not possible. In the example, they're using a dockerized postgres, prod is probably a managed DB service. They're using docker compose, prod is likely ECS/K8S/DO/some other service that uses the image (with more complicated service definitions). Local is probably some VM linux kernel, prod is some other kernel. Your local dev is using mounted code, prod is probably baked in code. Maybe local is ARM64, and prod is AMD64.

I say this not because I want to take away from the idea of matching dev and prod as much as possible, but to highlight they're inherently going to be very different. So deploying your code with linters, or in debug mode, and getting slower container start times at best, worse production performance at worse - just to pretend envs which are wildly different aren't different seems silly. Moreover if you test in CI, you're much more likely to get to a prod-like infra than a laptop.

2. Cost will also prohibit this. Do you have your APM service running on every dev node, are you paying for that for all the developer machines for no benefit so things are the same. If you're integrating with salesforce, do you pay for a sandbox for every dev so things are the same. Again, keeping things as similar as possible should be a critical goal, but their are cost realities that again make that impossible to be perfect.

3. In my experience if you actually want to achieve this, you need a remote dev setup. Have your code deployed in K8S / ECS / whatever with remote dev tooling in place. That way your DNS discovery is the same, kernels are the same, etc. Sometimes this is worth it, sometimes it isn't.

I don't want to be negative, but if one of my engineers came to me saying they wanted to deploy images built from their machine, with all the dev niceties enabled, to go to prod, rather than proper CI/CD of prod optimized images, I'd have a hard time being sold on that.

Some of the metaphors for interacting with the models, and visualizing as threads are interesting. Definitely does a good combination of ease of prompting + interogatability of the generated code.

I quickly ran into a wall trying to do interesting things like "forecast a dataset using ARIMA." On the surface it just does a linear prediction, seeming to ignore me, but under the hood you can see the model tried importing a library not actually in my environment, failed, and fell back to linear.

Given that you're approaching this in a pythonic way, not sql, my default way of working with it is to think about what python stuff I'd want to do. How do you see handling these things in the future. Go the route of assuming anaconda, and prompt the model with a well known set of libraries to expect? Or maybe prompt the user to install libraries that are missing?

Interesting project, I could see a use case for emerging markets where people don't have laptops. Maybe also include a local PG like https://supabase.com/blog/postgres-wasm for being able to play around with PG educationally with no required remote server?

For professional use cases, maybe if you're on call and need to access the DB over your phone (though I hope I'm never in that spot). Having documentation around network model - do you relay queries through your own backend - and the security model for data and credentials. Do you support any secure connection methods, like SSH tunnel, or does the PG need to be facing the public internet?

I see the issue with these more as if you are paying for it, one of the decision factors to buy it might have been that you have the opportunity to go to an open source version if the relationship gets bad.

Sole source vendors are really risky, so open source gives a little control back to the buyer that the vendor won't lock them in then screw them later (oracle).

So now if you're paying for Cockroach, you're effectively on proprietary technology with no negotiating levers.

I would think a key difference is once this was found out, Dan Rather was fired.

There will always be failures of integrity. Our expectation can't be infallible people, but rather the rigor of an organization to care about the failures.