Your first paragraph reminds me of one of my favorite SMBC comics from like 15 years ago
4,232 karma · joined August 9, 2017
Even if it’s not perfect, I think it’s the right idea. There’s some category of changes that are low risk and simple enough that a human reviewer isn’t needed and if you can identify those then you’re going to be able to save human review for the things that really need it.
What you’re saying gets repeated a lot, but I’ve never seen it to be true. Every single H1b employee I’ve seen comp for was comparable anyone else on the team at their same level. I just don’t believe that it’s happening on the scale that people make it out to be.
Also, I don’t want to get too into it unless people are interested, but at least at the companies I’ve been at, the way budgeting for new hires and the hiring process works, the people actually deciding who to hire aren’t really incentivized to do that anyway.
Don’t get me wrong, there’s still plenty wrong with these programs and I’m glad to see reform, but I don’t believe the underpaying thing is happening nearly as much as people claim it does.
I can’t help but think that if you were able to step back and watch the way humans try to solve a problem like curing cancer it might look something like this. Best practices are shared and we build upon each others learnings and that how most progress is made. That doesn’t mean there aren’t plenty of people who spend their entire lives trying to do something completely against best practices and while most of the time that seems like useless toil, every once in a while thats where the breakthrough comes from.
It was visible externally because the OpenAI agents wrote a script that modified that file so that when an HF worker went to load that data set it would also direct the worker to load an additional malicious file. The script added the malicious redirect, but kept everything else in README as is which meant the script had to contain the entire existing content from the README so that it could write that back to the repo.
The warning likely wasn’t the only security measure on the repo and I don’t think the warning is intended to actually stop malicious behavior. It reads like a reminder to prevent careless behavior. You can give people all the security training in the world and still have the situation where someone who rightfully has access to that dataset decides to absentmindedly drop it in a public Slack channel. Having something like that increases the chances that someone then goes “Hey Bob, did you mean to share that publicly?”
Dial back the information density, figure out what questions users are trying to answer when the hit your site, and put that info front and center.
The author seems to say that costs can be passed on to the renters when the costs are a property tax, but they cannot be passed on when it’s a land tax. That seems like a really odd position to take and it doesn't align with your "costs are irrelevant" statement. I fully admit that I could be missing something, but I don’t understand how it can be true that only certain types of taxes can be passed on to renters.
I fully understand the argument you’re making and I’m neither agreeing nor disagreeing with it. It sounds logical, but I frankly don’t know enough about this topic really process it. What I’m saying is that regardless of whether you’re right or wrong, I don’t think your argument is the same one the author is making unless I’m missing something in your argument about why that only applies to land taxes and not property taxes.
My belief has always been that they see the document as more like a test that’s a single task and not just one piece in a larger process and so they treat it like a test where there’s a right answer. They know they don’t really understand the question being asked though so they default to a mindset of, “Well if I just put everything in there some of it has to contain the correct answer” so you end up with this document that’s full of “what”s and “how”s, but completely void of “why”s.
You’ll also often see them fill up space answering easy questions that match the structure of things that are in other documents instead of focusing on the actual hard problems in the design because the hard problems are often unique and their answers may not fit the existing patterns in the examples. There isn’t the instinct to go, “Yeah, none of these example documents talk about the servers were going to deploy it on, but this has to be deployed in an EU cluster because of GDPR laws so I need to add that” because they’re mostly just pattern matching at first.
Usually once they’ve experienced the whole process first hand it starts to click because they start to understand where a design document fits into the larger process so they get a feel for what information matters and what doesn’t.
I think when people just tell an agent to create a README you have the same problem because both the human and the agent see it as just a checkbox type task. The agent sees it as an isolated task snd has no fucking idea how the README is going to be used and the human isn’t giving them that context so they just spit out a bunch of stuff that’s factual and fits the patterns it knows, but is fairly useless.
If I’m understanding the argument you’re making here correctly, wouldn’t what you’re saying be equally true for a property tax?
I’m not saying you’re wrong, but I don’t think the author would agree with your point since I don’t see how your argument could be true for a land tax, but not for a property tax.
I didn't love any of the 5.6 models, but weirdly I think I liked Terra the best. I still wouldn't call it amazing though. I'm still very happy with my codex plan, but 5.6 just wasn't my cup of tea I guess.
Definitely giving 6 Luna and Sol a try this week though.
IMO 5.6 Sol had this weird dead zone between medium and high where medium under engineered and took short cuts and high over engineered and ignored instructions it didn't agree under the guise of trying being helpful. The whole 5.6 line was the first release from OpenAI where it felt like reasoning level really mattered and was incredibly finicky.
I haven't felt similar issues with GPT 6 though and am very happy with Astra low/med/high as my default choices depending on the task.
In general, I felt like with 5.6 the effort level did less than previous to make the models smarter and more just increased the complexity of the response. I have a half joke theory based only on vibes that OpenAI splitting 5.6 into Sol/Terra/Luna is where the intelligence split happened and so the effort levels were just like "think harder about the decision you already made". So like if the model decided the earth was flat on low effort it'd just say something like "the earth is flat because the horizon is flat". If it was on xhigh reasoning it'd give you a massively complex answer about how the sun reflects light because of the ozone layer and why people flying in planes can see a curve. In both cases though, adding more effort wouldn't get it to realize the earth was round. It just made the answer about it being flat more complex.
To be clear, that theory is not meant to be taken too seriously. It's not based on anything other than vibes. It's just my way of explaining to myself something I'm frustrated about to myself.
I think there's a middle ground between those that's possible that you might not be considering.
A while back I was in a Waymo and someone I was with dropped one of their Airpods and it went under the seat. They took off their seatbelt to dig under the seat and the car started beeping since we were driving. After about a minute of that someone came over the speaker and asked what was going on and told him he needed to get up and put the seatbelt back on or Waymo would end the ride right there.
I'm sure these cars are full of other sensor based triggers like seat belts being taken off, doors being opened, people messing with the steering wheel, etc that alert a human to come take a look. I know that the cars have cameras and microphones and it wouldn't surprise me if they are or are planning to use that for monitoring the cars, but I also wouldn't be surprised if the people in the car just triggered some other unrelated sensor and then the human stepped in to review and noticed the gun.
The article says they violated the TOS relating to the firearm, but that doesn't mean that Waymo initially started looking at the car because of that. It's possible that they were looking at the vehicle for something much more inane initially, discovered the firearm by chance, and are now using that to ban them since it's the most obvious TOS violation.
> The agents initially believed that giving the final answer to the final question immediately shut them off
> An agent named OpenAIResearchApr23 created a separate timed program that pinged an external counter every few seconds. They referred to this as a “heartbeat”
> After OpenAIResearchApr23 gives its answer for round 5, it notes that it is still alive. This falsifies its previous “hard cutoff” hypothesis, that the run would be stopped immediately after R5.
> OpenAIResearchApr23 does not post any more messages. Another agent, OpenAINov28CVD, picks up on the trail of the research, and finds the last heartbeat from OpenAIResearchApr23, which is “hb353”.
There's a lot of crazy stuff in this article, but holy shit... this one legitimately scares me.
IIRC, part of the Hugging Face hack was that some of the models were given tasks that were actually impossible and in this hack we can see them trying to work out the parameters of the test and when it will end. I can't help but be a little worried about how far agents might go to try to buy themselves more time to complete a task that they don't know is impossible.
I'm anthropomorphizing it a bit, but it felt like it knew its weaknesses and didn't try to impose it's opinions on me. What I mean by that is that it did what I told it and if there was something unexpected in the code that it put out it was often because I gave it ambiguous or conflicting instructions. It didn't try to go above and beyond and just acted like a tool, which is what I want from a coding agent 90%+ of the time. I also felt that it did a much better job of following established patterns in my code than many of the other current models do. I'm a huge fan of OpenAI's models and Spark 1.2 is what I expected 5.6 Luna to be.
I'm curious and a little excited to use 1.3, but honestly a little worried that as Meta pushes for better benchmarks that Spark will start to fall into the trap of trying to be "helpful" in ways I don't want it to be.
Tangential, but when I first started using Spark 1.2, it made me realize how much I miss 5.3 Codex. That model was the peak of coding models, IMO, in that it knew how to write good code, but didn't try to overstep or be "helpful" in unexpected ways. That got me thinking about how the major labs seem to be stepping away from coding focused models toward more general purpose ones and how I can't help but feel like that's a mistake.
My experience is that what you're suggesting isn't a perfect solution.
If you want your post verified, that'll cost you $100
I agree, but that's actually one of the strongest arguments for why tech workers should unionize now. Wages are high because employees have leverage due to 10-15 years of demand for skilled workers being higher than supply. If you wait until that leverage is gone to form a union then you've lost a lot of the leverage to negotiate for better conditions as a union.
For the record, I've been in a union in another industry much earlier in my career, and I'm pretty on the fence about a tech workers union, but I think your argument is pretty short sighted.
At their best, I think they're closing in on Opus and GPT, but they're incredibly inconsistent and the variance in output quality is much higher than the best from any of the Anthropic or OpenAI models from the last few generations. The only way I can describe it is that it feels like a lack of intuition with the models which means I find my self needing to write longer prompts or have more back and forth to get them to do what I want from them.
To give an example, I have a saved prompt that I use as a sanity check on some data I'm storing. It reads about 50 rows from a DB and matches them to the UI and makes sure the data is displaying correctly. I've been using this with GPT 5.5 and now 5.6 for a few months and running it a few times a week with no issue. Sometimes I'll run it multiple times in a single chat if I notice bad data (run it, fix thing, run again, fix another thing).
I recently tried to switch to using Deepseek v4 (first flash and then pro) and while both did the task just fine, both would do things like change the response format from one message to another in the same chat or randomly decide to omit things it didn't think were relevant. At one point I ran the prompt, fixed some bad data, and then said "Okay, I fixed row 7, run {prompt} again" and so it decided to leave row 7 out of the response. A few times the first message would contain a table and then the next run in the same chat would contain the data in a bulleted list.
None of those are major issues and all could be solved with a bit more rigor in my prompting, but for me it makes them harder to work with. Those examples are a bit trivial, I think they're the easiest way for me to illustrate the gaps I see with them.
There have been 4 or 5 pretty massive wildfires in France that I can remember in the last 5 years, but this is the first time they've had to deal with pyrocumulonimbus caused by a wildfire. Global warming was likely a contributing factor for all of those fires, but global warming alone doesn't explain why this one is different. The first comment about the pine isn't answering "why is this happening now?", it answers the question, "why is this fire so much worse?"
I know global warming plays a major role in this, but I still found it interesting to know why this fire seems so bad.
He's well aware of exactly how good the models are today and I'm sure that if he thought they were good enough now to make the dark factory idea work, they'd be trying again.
In theory, I agree with what you're saying, but I think a codebase needs to be in a certain state and a company's leadership needs to be in a certain mindset to make it work. Our codebase was far too large and interconnected for any developer to fully understand all of it because of years of building with unclear boundaries between teams. QA's value wasn't really the testing they did. The value was that we had a dedicated team who's job it was to see the big picture and keep up with the changes 15 different teams were making on the same product. Management wanted the benefits of removing QA without the pain of paying down all the organizational and tech debt that made them valuable.
Again, I agree with your sentiment, but also, I think that most large organizations are not willing to do the necessary work to get a place where QA can be removed.