dataplumb3r

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.

>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.

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.

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.

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

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

> The productivity cost of five minutes of downtime in your CI system is hard to quantify in dollars, but it is, by any measure, a humongous amount.

Not sure the last month GH had fewer than five minutes of downtime - but I think it's been a while

You do not have a ZDR with Anthropic.

For Mythos and even Fable they require prompt retention on their end.

edit: or more precisely if you want to access Mythos/Fable ZDR does not apply, and depending on config the exclusion can affect other models.

If you wrote an initial draft you should consider using a better model or just posting what you wrote.

The smaller models can be sufficient for coding but for document writing not highly specific I've yet to be satisfied with AI output. I certainly wouldn't expect gemma to produce good outputs.