the real risk with an ai built personal blog isn't getting hacked, it's what happens when something breaks and you have no mental model of the code to even know where to look

Lol fixing a bug in a simple personal blog is WAY above the paygrade of latest Claude/OAI models. It will literally one shot fix any bug that is ever found in such simple application.

This is not much different for hiring a contractor to build your personal blog. What happens when something breaks and you have no mental model of the code to know where to look? You call up the contractor to fix it. You have simply outsourced the problem.

The mistake in logic here the assumption that having AI build your personal blog means that you build the personal blog. You did not. There should be no more expectation of having a mental model than if you got another human to do it.

The agent is your mental model. As someone who held pride in his ability to dive into unknown codebases and quickly figure out how they tick, Agents just do it more efficiently. Even if I have to follow up on what the agent finds, it's so much faster and efficient to have an agent in the mix.

By construction, a personal blog is very likely to break unexpectedly compared to other types of vibecoded projects because a) the scope is very narrow and b) there is only one user.

No problem, just have the AI fix it, or build it again from scratch. If it's done it once it can do it again. Unless you lose access to the AI, which is what I worry about.

idk when most ppl's cars break down, they dont have the mental model to fix their cars either

we've been here / done this before, but in other journeys and with other "vehicles"

this is just another kind of vehicle, in a field where vehicles never existed

aka the purpose of 'Ask' mode. These new tools require one to 'Think Different'

the interesting part isn't whether this counts as hacking, it's that the agent had standing access to something nobody scoped down for it. same gap OneCLI and every credential-gateway launch this month is chasing.

the slop detector giving 86% confidence on a keysmash is the real finding here, not the leaderboard score. confident and wrong is worse than an LLM that just hedges.

the real win with jev isnt beating a trained classifier on accuracy, its that you can change what you're classifying by editing a prompt instead of retraining and redeploying a model.

this. system 1 thinking needs complementary really good system 2 thinking.

one thing nobody mentioned here, once the agent is looping against the same benchmark it will happily optimize for the benchmark itself and not the real workload. worth rerunning the win against a slightly different input shape after, just to check it did not memorize the harness instead of actually fixing anything.

Maybe LLM's should be integrated with the software, so they could optimize to the real hardware and workload ?

There is an entire paragraph about benchmaxxing and how to mitigate that.

I think the scary part is that someone gives gmail access to Claude.

Or access to a filesystem that contains things like an image of their signature.

Speed up CI and the next bottleneck just moves to deploy and rollback, which do not scale the same way.

> deploy and rollback, which do not scale the same way

Why not? A good chunk of software engineering problems can be solved if we re-structured our definitions. Even just a year ago, people did not believe that a good chunk of prod-running code would be completely AI generated. Now we're at the point where some companies try to split "what code has to be PR-reviewed, and what doesn't have to be" to remove that bottleneck and so on.

You are right, but one problem at a time :)