@Felix - How are you thinking about observability? Anthropic is very clear that evals are critical for agentic processes (your engineering blog just covered this last week). For my whole company to roll out access to agents for all staff, I'd need some way for staff (or IT) to be able to know (a) how reliable the systems are (i.e., evals), (b) how safe the systems are (could be audit trails), and (c) how often the access being given to agents is the right amount of access.
This has been one of the biggest bottlenecks for our company: not the capability of the agents themselves -- the tools needed to roll them out responsibly.
As an alum, you may have much more influence than you might expect. President Cauce (who's contact information is prominently displayed on the UW website) may be unaware that alumni are not pleased with this.
> 100% not at fault
When something significant goes wrong, it’s almost never due to a single cause; multiple factors and confounding elements are usually at play. We build better-performing systems when we examine various contributing factors and proximal causes.
The OP's argument is that the interface does not "clearly" indicate that one engine input is higher than the other. After reading the article and reviewing the interfaces, I have to say: the OP’s argument is quite compelling. While training is undoubtedly important and should be included in the safety recommendations, the OP makes a strong case that design improvements should also be considered as part of the safety recommendations.
I have kids who will soon be teens. They don't have phones yet, but I can see the decision looming: my ability to communicate / coordinate with them plus the fact that a huge portion of their social life will migrate online on one hand vs. all of the dangers on the other.
This is why a lot of parents start with smart watches or restricted phones. They try to get the communication / coordination benefits without the online social risks. But that only lasts so long.
I'm not sure how I'll navigate it. Probably not by saying "no to that stuff until 18".
I am not going to address the broad set of questions here but I want to point out that two items exist:
1) No-data SIM cards ... they call and text only ...
2) imessage only access point - fairly trivial to set up.
So ... a child can be given a phone - even a smartphone - and it can't be used as a social media device when the family wifi turns off. Further, you can heavily restrict family wifi without curtailing normal phone talking if you have an imessage/facetime only access point.
Again, no magic bullets here but some tools that you might find useful.
I put off letting my kids have a phone until 14. They had tablets before that. If I could have done it all over again, they wouldn't have gotten any kind of device until at least 16. At best they would have gotten a flip phone.
One of the interesting ironies of philanthropy (of which there are many) is that people who have less money tend to be more generous philanthropically (as a % of adjusted gross income) than people who have more money. And because of the way the numbers work out, they give out a lot. If Upsolve can help a very very very large number of people get through bankruptcy, they might be able to amass a very strong "Pay it forward" revenue stream. Not sure if enough to fund the entire org, but enough to help out.
@rpavuluri: If at any point you were to move forward with white labeling and selling that, I would recommend you consult a lawyer about whether the IRS would consider this unrelated business taxable income (UBTI). Too much UBTI can put your 501c3 status at risk. IANAL / IANYL / YMMV / etc.
I think generally UBTI refers to income that is actually unrelated to the good the nonprofit purports to do.
For example, Princeton a nonprofit can totally charge tuition and use it as a base of funding, and not pay taxes on that. They can even sell their students food in cafeteria and not pay income tax. [1] But they can't start a food franchise and not pay tax.
This software seems clearly within their registration statement. Now if they started selling software consulting as their major source of funding...
In any case, I agree checking with your accountant is the best.
I challenge you to consider whether your perspective applies to the 99% of people who use Slack that are not developers writing software. For those people, email is often not a place where well-argued discussions happen. It's usually a place where chat-like communication happens, slowly, and in an ill-fitting interface. For non-developers, let's take a operations associate for example or a logistics manager, or someone else whose job is to coordinate and communicate frequently, Slack plays a very different role than it does for devs.
Unfortunately for you, and others like you who don't like Slack, if 99% of your company wants to use it, you'll almost certainly get pulled in. Unless your department or team explicitly opts-out, you'll get pulled into the same platform the rest of the company is using.
This isn't to say you're wrong -- just to say that we must not judge the hype around Slack, or it's clear successes, as a fad if we're only judging it based on the experiences of the kinds of people who frequent HN.
From my experience, in most office jobs, email is primarily used for serious and well-argued discussions concerning projects, business goals, technical details, etc. Software developers really don't use email any differently from IT support, accountants, HR managers, or salespeople. Non-developers generally reserve chit-chat for chat software, just like developers do.
Not sure what it is about HN assuming software devs are somehow intellectually and professionally superior to others.
> Not sure what it is about HN assuming software devs are somehow intellectually and professionally superior to others.
Dunno but this thread is full of a bunch folks rather arrogantly assuming their way is the One True Way.
Slack (and hipchat) didn't get big for no reason. It's because it fulfills a pretty big need. Tons of people in my company use & love Slack... Last company was a big hipchat company...
I agree that the "software dev" distinction here is not relevant.
However, it's definitely true that email is typically used both for "serious and well-argued discussions" and for chatty threads along the lines of
Thanks.
BTW How are we looking for this month's revenue target?
>No idea, maybe the data load didn't run last night,
>I'll look into it.
>
>>This report looks broken, the opportunity I closed
>>yesterday isn't in there, what's up?
Make sure you are only including positions that help you. Common mistake I see is including tiny 2-3 month long positions, without considering whether including them is additive or not. It's often not.
I'd rather see "waiting tables" rather than nothing
But why? Maybe the person used that time to study technologies, to update her skill set. Maybe she used that time to relax and get a long deserved vacation. (Or a myriad other possibilities.) What is wrong with that?
If somebody set aside 3 months to study something they should write that. Otherwise it loos like they've been unemployed, in jail or something they rather don't want to talk about.
Also I read it as multiple 3 months gaps. I might have misread though.
short sighted, but that's sometimes the right way to prioritize. sounds like kenning is in prototyping mode, and could be intentionally prioritizing time to first test, acknowledging that s/he might have to rebuild things later. in the early stages of a startup, speed to insight can easily be more important than long term coding efficiency. so short sighted thinking can make sense.
I don't agree with this at all. Code review is obviously a huge benefit once you have enough money to pay more than one engineer per gigantic slice of the codebase.
I'd say code review is also great if everyone is working on the same thing, such as a library. In that case I'd do code review if there were only two people working on the project. But when one guy is basically just doing react boilerplate and implementing designs, it's not worth the time to check every commit they make.
This has been one of the biggest bottlenecks for our company: not the capability of the agents themselves -- the tools needed to roll them out responsibly.
reply