onion2k

Light pink I reckon.

Bad Management: 63%

I don't think you can really ask whether people have seen 'bad management' without explaining exactly what that means. People, including me when I was a developer, often see 'bad management' as 'I don't agree with what I'm being told to do'. That's not necessarily bad management; far more often it's poor communication of the facts (although you could argue that's the bad management bit I guess.)

The things I used to think were bad management included hard deadlines, short term benefit projects that took on tech debt, not 'motivating' people by giving better raises, refusing promotions even though I thought someone was great, prioritising things that I didn't see the value in, etc. Those things maybe weren't bad management at all. I just didn't have the full facts.

This is the problem with surveys like this. Someone didn't get the raise they wanted, so they check the 'bad management' box for that tiny cathartic dopamine hit. It doesn't necessarily mean they've been badly managed.

I don't think that's strictly true.

What you need is for your LLM to be able to understand enough context to be able to make a change with as few token as possible, so if your code isn't expressive enough or if it has a tendrils calling lots of different functions/methods all over the place, then you'll have to give it much more code (context) than if you've got nice encapsulated modules that don't depend on other parts.

The design of your architecture (probably?) has a greater impact on token use in a large app than the language it's written in. Although, obviously, languages lend themselves to particular architectures so it's correlated.

It makes a lot of sense architecturally. It's much simpler to update a webpage than force every user to update their app when something needs to change. Consequently a lot of apps, especially on mobile, use a system webview with a page loaded from a server and rendered to look like the app for anything that gets regular updates. The alternative is having lots of versions of the page and needing to manage all the different variations of payloads from them.

Backwards compatibility in an API isn't that hard, but when there's a simpler option (a webview) people will take it.

That said, if there's no native stuff in the app, it is a bit harder to justify.

You'd better be north of Leeds to be saying things like that. :) Cool app.

There's a cost either way (electricity or water), but electricity is much easier to get to your data centre so the capex cost at the start is lower, and municipalities have this annoying tendency to ban cooling towers because they're not pretty enough.

Newer data centres use closed loop electric (refrigeration) cooling instead of induced draft open loop evaporative cooling.

If you're only saying we need fewer data centres then your argument is against AI, and not in favor of sensible approach to the climate.

Even at night?

They're going to align to the regulator, not the customer. Right now that's Anthropic as they're saying they can self-regulate, and people are willing to let them try, but the landscape could easily move to be regulated by someone else. Moves like speaking to religious leaders is probably a bit of theatre to keep the government at bay.

I think the problem is that you have to ask, and to know the language to get the result you're after. If you just ask for a pretty website you're getting 800KB of React libraries to render something, and all in AI Beige with Inter as your font choice.

That's a checkbox decision for the customer. There needs to be the option of "This is important, never turn it off and I'll pay for any overages." versus "I want an entirely predictable bill up to $xxx, so stop my stuff as soon as possible over that."

It's not up to a cloud service to decide my website is more important than my money for me. That's my decision to make.

It's not about using cloud AI. It's using wifi to enable the local AI to do more stuff.

HN readers are probably much deeper down the AI rabbit hole than people who buy barcode software. The fact you see and judge an AI-created website poorly doesn't mean customers of the product will.

It's possible that you're in the middle of the Venn diagram of barcode software buyers and HN readers though. In that case your comment is very insightful.

We can think of questions we can't answer. It can answer them.

...but many orders of magnitude faster, and in a way that scales horizontally really well, which is quite useful even if the quality isn't quite what a the absolute best humans can do.

Impractical for an individual, definitely. For a large org, maybe, but if the payoff was big enough? For a nation state level actor intent on doing something, absolutely not.

The go-to example is Stuxnet. Some countries wanted to attack Iran's nuclear enrichment programme, so they spent 5 years developing a worm that used multiple zero day exploits to attack a specific controller in a specific model of gas centrifuge. Could Mythos write Stuxnet? Unlikely, but a knowledgable team with access to it could probably write it in a lot less than 5 years.

'impractical' has very different values for different groups.

Is that necessary? You could start Chromium with an open debug port and use Chrome Devtools Protocol to send commands.

That seems unlikely because they'd have been recruiting from the same pool of talent. They'd have been wondering where the best people from specializing in space tech, optics, etc went, and being leadership at NASA means you're probably not stupid, and you go to the same events as them. Also as NASA leadership, it would have been a pretty logical next step for your own career.

I don't doubt that people outside of the NRO had no idea what they do there, and that people lower down the hierarchy didn't know about it, but NASA leadership must have known there was a shadowy org working on cool satellites.

If OpenAI can show that a $6k tool nets $50k in productivity or quality or speed they have no problem selling it. Companies will take the easy-but-expensive option over a cheaper alternative. The problem is that's really hard to measure and seemingly they've put no effort into trying.

(I'm here all week. Try the lobster.)

HR was invented because workplaces didn't work well, and that was about 50 years before mixed workplaces were common. You're just projecting your biases and ignoring the facts.

Yes. E2E tests are there to give you confidence that future changes haven't broken things. They're not there to catch bugs before the feature goes to production. Unit and integration tests should do that though.

You shouldn't just eliminate PR reviews because "we communicate inside the team".

You should eliminate them as soon as they're not giving you any real value, but if you don't eliminate them before that team's will stop trying to get that value in a better way because they believe the PR process catches bugs. It doesn't though, so all it really achieves is stopping the team trying to improve.

I lead a group of teams that build frontend software, so not really. :)

The majority of bugs I see are business/domain logic bugs. It's akin to having misunderstood or missed some aspect of the question, not causing data loss.

Financial loss, reputational harm, degraded UX, etc. They're all significant problems. They're more recoverable than a data loss, but equally bad from an accepted low quality standpoint.

I'm also going to guess that you don't have BAs, PMs, or people responsible for the logic reviewing the code in a PR. Consequently you can't spot those problems in at the PR gate unless the issue is that the dev didn't understand the requirements and wrote code that didn't do what it's supposed to. In which case we're back to the quality and testing problem. By raising questions in standup ("Can I clarify that I understand the AC right?"), pair programming ("Let's check the code against the AC") and communicating properly ("Can you demo the feature to the BA so we can be sure it's correct") you move the problem to the people who can answer, and stop the devs needing to review that someone wrote working code.

I just don't believe PRs are the right point to be finding out that the requirements were wrong or that the dev didn't understand what to build. That needs to happen as early as possible. PR is as late as possible.

As for finding bugs, what happens if you miss them? Do they go out to production and potentially lose user data? Finding bugs in PR is a big problem. For a start it shows your automated tests aren't good enough, and secondly it shows the devs aren't checking their code works well enough.

If you do them at all, PRs should be a gate for checking whether the code meets the team's quality bar, not if it even works. The team should be able to deliver working code without them.