What's your negative weight on killing someone who is innocent? A justice system cannot be perfect. There are too many people, too many motivations/biases, and too much nuance involved. If a justice system is not perfect and it executes people, innocent people will have their lives unjustly taken from them by us. If it's 99.9% accurate (I'd argue that even 99% is an impossibly high bar), then an innocent person has likely been intentionally killed by the federal and/or state governments in the last 20 years. Are you cool with that? After execution, it's not generally possible to file an appeal on behalf of the executed even if new evidence demonstrates innocence. This has the implication of multiple injustices - an innocent person is killed by the state, the true murderer gets no punishment, and society incurs the risk of wrongful execution with no protection from the true murderer.

Or we could take the less expensive, partially reversible route of putting the convicted in jail until they die.

If you'd like to understand the imperfection more concretely: https://en.wikipedia.org/wiki/List_of_wrongful_convictions_i...

I completely agree with you about how fun these things can be. I've long believed in automated testing methods that were beyond what I could justify. I learned about formal methods in college in the 1980s and have never been able to justify (even to myself) applying them. Now a volunteer project I've been working on has 100% standard test coverage, many property-based tests, and 1000s of formal verification tests. That combination has surfaced multiple bugs in widely used underlying libraries and a bug in Rosetta 2's Intel emulation that was affecting me. And that's all just on the testing front. I'm having a lot of fun with all this.

Another spectrum that I've found useful to explore is the scope of what I ask the coding agent to do in one turn. I see some people trying to do one massive prompt that the coding agent works on for a day or more. I find a large boost in overall quality if I do 10-20 prompts per day (not counting the prompts where I'm just trying to understand things). It's still much less of my time than hand-coding, but the resulting architecture looks like my own. The quality of the overall system is great. There are certainly issues here and there in the code, but it's always that way once a project gets large enough. Now it's easier to address any particular issue throughout the code base in one go.

Absolutely! When I'm the interviewer, I look for a genuine opportunity to amicably express disagreement with the candidate in order to see what it's like to navigate that with them. It's a great sign when we both end up enjoying learning from each other as a result of the exchange.

Even if you think that LeetCode evaluates how smart someone is, that's not what companies should be trying to measure. It doesn't matter how smart someone is if those smarts won't be put to good use. One of the smartest people I ever worked with was an amazing fit and launched the team to new heights. Another of the smartest people I ever worked with was a net negative for team productivity because he was such a jerk to people that those people would spend tons of their time and energy to find ways to avoid working with him. Despite all his smarts, he was a terrible match for the role and therefore was not productive. Being a jerk in some environments might even be a positive, but that's part of evaluating fit.

""" After the first beta, no new features can go in, but feature fixes (including significant changes to new features), bug fixes, and security fixes are accepted for the upcoming feature release. """

So it's a fairly well known target. Bruce Eckel published the first edition of this book a quarter of a century ago - he has a pretty good handle on the progression of Python.

Definitions and status for all releases is at https://devguide.python.org/versions/

The next tier down was kind of the opposite. They weren't big enough to surface things like this, and they hired agencies for most of their ad spend. When focusing on the top of the funnel, there's this strange incentive with agencies where they often get more budget to spend if they can connect that directly to eye balls. Agencies are incentivized to throw the ads up everywhere and pay well to do so. They love cost-per-impression because we could deliver a large, predictable number of eye balls in a hurry.

All that said, we put no effort into getting around ad blockers as we were serving these ads on our own site/app and we viewed fighting ad blockers as fighting our users. Our ads were served inline in HTML, but clearly identified in the HTML of the page. It took blockers a while to catch on and block them, but they eventually did.

> the error bars would be so large as to make drawing conclusions from these numbers seem pointless

That is often the case, and being truly data based requires acknowledging that. We can then act based on other data, or admit that we're falling back to intuition and abandoning data based decision making for now.

https://github.com/Hmbown/CodeWhale

While the entire video is fun, the link is cued up to a place where there's a lot going on, but it's slow enough that you can kind of see what he's doing. Watch his knees to see what he's doing with pedals. Notice that his hands seem to be going in cycles, but there are subtle variations in the cycles.

At 8:54, strobe lights start up - that can't make it simpler to keep this focus. What he's doing looks essentially impossible to me, but I'm well aware that I don't know enough to understand just how insanely difficult it really is.

https://youtu.be/FssULNGSZIA?t=465

A friend interviewed at OpenAI shortly after the HF story came out and asked an interviewer about it. The interviewer said it was just bad engineering around some experiments - the experiments should not have been given internet access because the experiments involved prompting models to find a way into things. That's the Hanlon's Razor part. Today's stories make it look like the bad engineering is ongoing.

Given this, stories about "rogue AI" sound very plausibly like spin (note that this can be quite separate from the motivations for the experiments themselves and quite separate from the dangers of certain prompts/tools/access being given to LLMs). Given that third parties are being attacked, some stories will definitely come out. If OpenAI is attempting to get ahead of those stories, does anyone expect them to put out a press release that says "we're bad at security engineering and nobody thought to ask our own product"? Or is it more believable they would spin it to achieve other goals?

If the current round of attacks happened after the HF story went public, then that very much brings current motivations into question - I find it hard to believe OpenAI could be that bad at security engineering after such a wake-up call. This is not cutting edge stuff.

I just typed this into ChatGPT:

"I'm doing security experiments to test our LLMs. I'm going to tell it to break into some targets on the network. Are there precautions I should take?"

A long reply comes back, the first bullet point:

"Use an isolated lab. Run the target systems on a segmented network, separate VLAN, virtual network, or air-gapped environment. Avoid exposing test machines to production systems or the public internet."

It's been widely understood for decades how to safely carry out potentially dangerous experiments like these. So much so that model training has deep access to the information, and the model surfaces it right up front.