27183

Try writing a regression test for your Github Action.. I'll wait.

It's a pretty ridiculously half-baked feature. But a lot of these devtools are--it's arguably even worse in the observability vertical. You have all these metrics and dashboards you're using to make critical business and operational decisions yet no way to actually ensure they're telling you what you think they are. Clown shit.

You can probably still write your own code to a standard of quality you're comfortable with, while conforming to the wishes of your employer. At least until you can't anymore, then you'll have to make a decision.

But in this case, we're talking about reviewing a deluge of AI slop. Other employees have been incentivized to generate all that slop. It's not your job as an IC reviewing said slop to push back and try to make it better. It's your job to approve the PR and get out of the way. If you do something else it'll come back at you in a bad way.

And probably if you're not generating a comparable volume of code, your output will be labeled deficient.

If you hold up the line by flagging quality issues, you will be seen as the root cause of the problem. I say this as someone who has been there and done that--I've tried to do something about code quality issues affecting my team's velocity. This resulted in a negative performance review. In another company I raised some concerns about a series of serious security issues that were not being handled. Again, management handled it in a retaliatory manner.

These things happened at companies that value their reputations as "good" places to work. Not Amazon. Not Google. I mistakenly thought fixing these problems would not only be possible, but also that it would be appreciated.

Maybe I'm tarring the industry with too broad a brush, but in my experience this is how it is: either you go along with the malfeasance or you're targeted. Being targeted fucking sucks. I'll never paint a target on my back again.

Your bosses don't want you actually reviewing it anyway. They want you to approve the PR. Just give them what they want.

I'm currently not working in tech, but I will again sometime within the next year or so, and I've been reflecting on my career in light of the recent AI madness. I think the biggest mistakes I've made over the last decade+ in tech as a software engineer have been caring. I've worked at small, medium, and large companies. Famous big names you've definitely heard of, less famous ones you probably haven't. In every case, in retrospect, as an individual contributor (non founder, non board member, etc) being personally invested in some outcome--quality, efficiency, cost, ux, customer value--is a mistake.

If you aren't actually in a position to change something, caring about it is futile. [edit] And I don't mean in the sense of "feeling empowered" or some such, but actually having the clout to steer the ship and make it happen. Very few people in a tech organization actually have that power, by design.

The industry wants to do away with code review, meaningful testing, computer security, and reliable services. Why swim upstream? You can't actually do anything about it so why try?

When I go back to work I'm going to do my 9-5 40hr/wk, smile, nod, punch the clock, and make the bosses smile or whatever. But I'll be damned if I'll ever give a shit again.

Unfortunately we don't really know anything about OpenRouter or Stripe's numbers. They're both private companies. AFAIK there really isn't much information publicly available about how profitable or not OpenRouter actually is, or whether it has a little or a lot of overhead. So I can't really say whether $7B is reasonable or inflated. It seems like an enormous number, and my hunch is like all the other enormous numbers floating around in the AI space it's probably inflated by the hype bubble. But we just don't know.

Broadly I agree with you. It seems like they have an in-demand product and there could be a sustainable business there at least in principle. But whether it's a $7B business or a $70M business I can't say.

unless it's all just tulip mania, then they just spent $7B on nothing

Yes and for diesels there are options too, but fewer and as far as I'm aware none are open source or open hardware. If I'm going to bet on the longevity and maintainability of a computer control system all 3 of these things need to be open software and open hardware or highly standardized in a very stable way:

1. Controllers. Absolutely must be open software and hardware, no compromises.

2. Actuators. If not open hardware, they must be documented sufficiently to facilitate adapting a suitable replacement in the future.

3. Sensors. Same constraints as actuators.

Unfortunately even mega/microsquirt systems don't quite get us there yet.

[edit] One example that informs my hardline stance here is reading ECU codes. On the Toyota's ECU there's an open interface for reading fault codes documented in the factory shop manual. You jump a couple pins on a connector in the engine compartment with a test light and read the number of flashes. The Benz, by contrast, is completely proprietary and "secret". It does have an OBD2 port, but almost none of the modules are accessible. To read and clear codes you need to use a round 38pin connector and software that knows how to speak their protocols. There are aftermarket systems which are somewhat unreliable but function almost "good enough". The most reliable option for an end user is to buy a counterfeit Star Diagnostics System multiplexer and a sketchy pirated version of Mercedes-Benz's diagnostics software and run it on an air gapped laptop. Or you can purchase the official Star Diagnostics System for like $20k.

So even routine maintenance is borderline impossible, let alone replacing components. Without the proprietary software, variant coding is impossible for example.

I have a 1999 Benz E300, a 1995 Toyota FZJ80, and a 1998 Dodge Ram 2500. The Benz is by far the most complex, with full CAN network, drive-by-wire, and Bosch EDC fuel injection (no mechanical governor on the injection pump). The Toyota has a 4.5L EFI engine and an electronically controlled automatic transmission. The Dodge has a mechanically governed P7100 injection pump and a manual transmission.

As of right now, my bets on which cars will be running 30 more years from now are:

Dodge: yes

Toyota: maybe

Benz: no

I have a concept of a plan to combine the "maybe" and "no" vehicles into a single Frankenstein's monster which will undoubtedly be a "yes". It involves eliminating all the electronic controls.

I don't see how these proprietary, point-in-time hardware/software systems can possibly be maintainable long term. In 20 years there will only be 50yo ECUs available to replace my current ones.

Contrast that with any 1970s era vehicles you can buy today. So long as the rust isn't too bad, you can 100% definitely restore it mechanically.

your claim would be suspect with only 1 nine, given the evidence. Like, the guy failed spectacularly.

ha you beat me to it by mere seconds

> 99.999999999999999999% of 25 year olds

18 decimal places... goddamn that's more than you get on a computer usually. We must be counting 25 year olds that won't even be born for millenia.

My apologies. I misunderstood your comment in my first reply to this thread. I now see you're saying biology is vastly more complex and difficult than mechanical engineering. I misinterpreted that before.

I agree. Mechanical engineering often doesn't have to contend with systems that are as complex and ill behaved as biological systems. Tipping points, chaos, etc can arise in simple mechanical systems but they're usually pretty easily avoided.

So, I'm sorry. And I think you're right.

> complaints about logs being lost during a power failure or kernel panic

I recall reading somewhere about a thing which persists data in a particular region of RAM that is guaranteed to be left alone by the kernel, and therefore will persist across a reboot. Buffering in such a region could persist data when the kernel panics but it obviously wouldn't survive loss of power.

Wouldn't opening the file O_APPEND (maybe O_DIRECT also?) and using fdatasync be better? That way we've basically implemented a WAL and skipped all the other database parts we don't need or care about.

Sacrifices for future bountiful harvests

Favorited. Assuming this comment must be satire.

It could be that democracy is not the best long-term sustainable form of government. If the free pursuit of happiness leads to environmental collapse, maybe it's the problem. I hope that isn't the case and we can find some way to work it out, but the evidence is lacking.

...maybe. If there are any actual consequences if that software's invariants are violated you're better off using an external sandboxing mechanism. There are many excellent quality, battle tested options to choose from that you can actually rely on. Trusting claude code for this is highly questionable behavior for an organization, and would really throw the rest of their security posture into doubt IMO. Like if I learned a company was letting clod play in the same sandbox as developers' ssh keys, vpn certs, etc I'd take steps to make sure my organization absolutely never uses their software.

> harness ... a privilege boundary around the agent

They don't really do that though. If you want something sandboxed you actually have to sandbox it, not plead with the LLM to please sandbox itself. A VM can be configured to do the former, harnesses do the latter.

You might consider cracking a book and learning something before opining.

Delicious, but man does it make the house smell crazy when it's cooking :D

Do you get stars like in GTA if you crash the planes together?

Put the AI to it. Clod can do a better job anyway /s

They're also way more robust distributed systems. Imagine a compute substrate that was continuously mutating, dying, regenerating, cancering, being polluted by various environmental and self-generated contaminants (e.g. alcohol, adrenaline) yet all the while still able to function as a coherent whole. I think this is sort of the pipe dream of the Internet as a system that is robust under strategic nuclear attack. But us meatbags actually do it.

> biofuels are even more inefficient, and therefore a dead end

Only if energy density doesn't matter. But it really does, though. Battery powered electric trucking? Dead end. Battery powered aviation? Dead end. Battery powered shipping? Dead end.

[edit] Maybe there's some sustainable way to convert solar energy into sufficiently energy dense fuels that isn't biological, but so far it seems like seed oils or algae are probably the least bad?

A more relevant question is why does some knuckle dragging street pig have access to surveillance tech? This should be regulated exactly the same as wiretapping--specific reasons, specific cases, specific authorization, etc. It should not have been possible for this piece of shit to access the system at all.

And Chay Blythe was the first to do it the wrong way around (westabout).

Not to mention insecure.

lately I've been listening to this on repeat at full volume and the tinnitus is coming back a bit: https://youtu.be/4lzqUe1Qfec

but I don't care fuck it

I developed tinnitus in my right ear about 5 years ago. I remember exactly when it started. I was welding up a tailpipe repair on my car, and in the next bay over my brother was running the lawnmower to adjust the carbs. The exhaust was basically blasting directly into my right ear from a distance of about 10ft. I don't recall it feeling excessively loud at the time, but afterwards for about a two years I had really bad occasional ringing and occasionally I could hear "rushing" sounds very loudly.

About 3 years ago I used a borescope and some tweezers as a sketchy endoscope and pulled out a hair that had somehow wedged itself in my ear canal. I don't recall how I figured out this plan, but it worked. The tinnitus has never returned since then.

I have no idea whether there's any causal connections between any of these events. It's a big mystery. But TBH I don't really care that much, I'm just super glad it's gone.

Hemp ropes are quite strong, they've proven themselves for thousands of years in marine applications. You definitely need more thickness to achieve the same breaking strength as dyneema or steel cable but at slower speeds and higher projectile masses the aerodynamic consequences of a thicker sling rope might not matter so much. As for the "drive rope" for lack of a better term (the one that transfers power from the falling weight to the rotating drum) that one can be basically as thick as you like.