I blocklist all of them.

I allowlist one going over our issue management system, and a few around internal processes I believe have value (basically very short pointers at OpenAPI specs for making HTTP reqs - could probably be in the repo AGENTS.md but w/e).

When opening a new repo I'll look if any skills look like they actually give helpful context and aren't Claude vomiting out a torrent of text (over)fitting some insanely specific use case and allowlist those.

Or give up after too much exposure to vile AI created text.

My only experience in >24h agents is with economically sane models (one of GLM5.2, 5.3-flash for orchestration, DSV4-flash for implementation, and glm5.3|sol|kimi3 agents + subagents reviewing at the end)

Over 24h my token spend is <30$. Excluding tokens for review it's <10$. With the absurdly gigantic subscription subsidies and a reasonable workflow I suspect one could run parallel agents.

I'm not sure what the point would be though unless working on some kind of optimization problem -- it takes me days to review <24h of the agent's output. It's almost always near enough to correct to be shippable; though I do give it feedback and iterate until it's better than the code I would have written.

It only really makes sense for problems that are complex and require iterations that don't themselves require much review. E.g. if you want find, PoC, and patch bugs, the output can be reviewed without reading all the traces. Or if you want to write a custom tool that does some job using local LLMs, assembling that pipeline, tuning the prompts, etc takes a long time but reading the final tests + eval data + code is enough to get a lot of confidence that it works right. Model checkers can help too, for example I wanted multi-sink Bluetooth audio support in Gnome for my kids so I hooked the hardware up and robo-coded the core logic specifically to be checkable with Kani.

>don't themselves require much review

I'm still wary of any unreviewed code - though my area of work is not tolerant of defects.

Agree on targets / verifiable indications of progress or success being a prerequisite for this being useful - although that covers quite a lot of SWE work.

This sounds like more work than just writing the code yourself. You'll say it isn't. I don't believe you.

That is an incorrect presumption - I think it's plausible this is more work; it's certainly far more taxing.

I'm at a point in my career where a small minority of my time is coding. The AIs can do in a day what would have taken me a week uninterrupted with acceptable (in some cases inferior prior to human feedback--but in some cases superior!) quality.

As I do not have 10 let alone 40 hours per week to devote to coding I think it increases the amount of high quality work product I can create with a given time investment. As I review it I merge small independent units and decompose the work.

All that is to say I don't really like it - but I suspect for most *well defined* coding tasks human produced code from highly experienced engineers will largely cease to exist in the next year -- getting cheap/relatively horrible models to produce good code is now straightforward.

OTOH I never use AI for any human facing communication outside of making my writing shorter. IMO AI slop "documents" are almost certainly a drag on organizational productivity.

You'd also likely spend far more in electricity than the API cost of processing the prompt(s)

yes, though for some uses, not sending data anywhere to third parties has its own value which is harder to measure.

TBF there are absolutely horrible platforms like Robinhood that aren't far off what the above poster alluded to. At one point payment for order flow was the majority of their revenue or near it!

The boring staid firms like Fidelity/Vanguard have vastly superior products not designed to incentivize gambling

> The more trades you make the more the odds stack against you, and you will loose everything.

In general this is true. Participation is not rigged with eg VTI/ITOT and VXUS/IXUS and a long enough time horizon.

There is no case where one cannot participate - doing nothing means inflation will eat away at assets.

I have a very brutish 50/50 international/US split (was 30% international before 2024 when Trump promised to destroy the US economy and started to act on that...). Each quarterly equity vest I put more in, and realize capital "losses" while buying the near equivalent security when there is an opportunity to do so.

> Single-thread performance is the only remaining measure where the M5 is king

This is admittedly the measure that most correlates with perceived responsiveness and quality of user experience

>All functionality is absorbed into a vibe coded, un-auditable black box.

As opposed to the famously stable and robust JS ecosystem.

Though it feels like the web tooling is thankfully moving away from JS/Node

EG webpack in js => rspack (rust) typescript in typescript => typescript in go (the loss of bootstrapping is a bit sad but worth it)

True but paid users are also impacted.

We're still staying on Github at work, but have had backup self hosted git repos as a break glass option when Github is completely broken and leveraged this several times now.

Some of these are situational, but many are expectations of a modern platform.

Take Python - the standard lib now has things like a toml parser, sqlite client.

And while I avoid the entire JS ecosystem as much as possible, a simple search to find a good Postgres client was not elucidating.

https://wiki.postgresql.org/wiki/List_of_drivers two options - with node-postgres / pg seeming to be the most supported or postgres.js which has more abstractions but is less active

Contrast that to the question for Java, where it's clear the official JDBC driver is the best option.

I would think so - outside this sentence the author indicates they're talking about consensus across all members.

IE - the interactive diagram and note about latency being bounded by the slowest replica

hmmm, I think they might be using a quorum-based 3PC variant. Reading <https://github.blog/engineering/infrastructure/building-resi...> does make it seem like they only need a majority to commit instead of all nodes.

Ah, and then it looks like the losing nodes get marked unhealthy:

> In essence, every write operation goes through a voting protocol, and any replicas on the losing side of the vote are marked as unhealthy—unavailable for reads or writes—until they can be repaired. Repairs are automatic and quick. Because a majority agreed either to accept or to roll back the update, there are still at least two replicas available to continue accepting both reads and writes while the unhealthy replica is repaired.

But not sure how unhealthy nodes are discovered. Maybe the coordinator marks them, and if the coordinator crashes it allows stale reads and detects invalid writes?