And it's the exact same stuff they said about factory automation.

And it's the exact same stuff they said about using machines in factories at all.

Yes, companies that offshored too much or stuff that was too important to the core of the company did screw themselves over. But most companies did not go that far and lose their best employees and know-how. That would have caused most companies to collapse.

And that's where we are now. Companies that use AI for too much or stuff that's too important will discover they've lost their core competency and knowledge. Companies that use it in more limited ways will have a competitive advantage over companies that don't use it at all. And even down at the bottom, engineers who figure out what it's good for will be more productive than ones who don't. Not 10 times as efficient, but 10% more efficient is still enough to matter.

I've been writing software for over 30 years. I used to spend 20% of my time writing and maintaining unit tests, one-off scripts, and stuff like that. I would not trust AI to touch my core code. But tests and one-off scripts? Stuff that fits easily in its context window? Sure.

No, it doesn't *always* work, but it *usually* does. And it doesn't take very much time to figure out when it's not working. And rather frighteningly, it does a *better* job on most of those one-off scripts than I would. (I'm not going to spend a bunch of time on error handling and comments for code I only need to run once. But the AI does.) Sure, I could have an intern or junior SWE write the same tests or scripts, but that'd take hours, vs. minutes.

If 80% of your engineers are able to leverage AI to do the same work in 80% of the time, it doesn't matter if the other 20% can't figure out how to make AI work. You just lay them off; the other 80% are efficient enough to compensate for the layoffs. And that's one of the big things causing stress right now. You either figure out how to use AI, or you'd better start learning plumbing or something.

It also sucks if you're a new-grad SWE. Because the AI is better and faster than you *are right now*, and a lot cheaper. If you had a couple years experience, you'd be in the first pile of engineers trying to be in the 80% who keep their jobs. But you aren't. And you can't get that experience, because nobody will hire you until you already have it. The best you can do is work on open source or personal projects to build experience in the evening, after you bag groceries during the day. And hope that you get better faster than AI does. (Seriously, that's what my son is doing.)

Unfortunately, I don't see a way off this unamusement park ride. Even at a 20% gain, any individual or company who doesn't use AI is going to lose out in speed or cost to someone who does.

(Actually amusingly, the companies that try to push *too much* AI won't end up any better than the ones who push *too little*. Those are the ones who will vibe code themselves into corners, or AI will break stuff in prod, and nobody will know how to fix it because they laid off too many people too quickly.)

And that is: The register must honor the lowest price displayed in the last 6 hours.

There's nothing wrong with a store dynamically lowering prices. We just don't want them to go up while we're shopping.

Virtually all shoppers are wandering around with smartphones with cameras, so it's easy to take photos of the tags. If you catch the register not following the rules, you get some payback. (What is an implementation detail. Double the difference? One item free? Depends on how frequently that store has a problem?)

I already take photos of every sale tag when I'm shopping, just so I can confirm I'm getting the sale price. It also saves a ton of time when an item fails to scan at all; rather than them sending a runner back, I just show them the photo of the shelf and they key in the price.

Between 2012-2021, San Francisco issued a total of 11 concealed carry permits. (source: https://calmatters.org/politic...)

In 2022 alone, San Francisco police seized over 1000 illegally-possessed guns. (source: https://sfbos.org/sites/defaul...)

Many people in SF are carrying. Few of them are doing so legally.

Why do you think there is any overlap between the SF Board of Supervisors' demands and reality?

This is the same city that keeps trying to ban corporate shuttles so that all the tech workers will have no choice but to ride public transit, and then will have no choice but to pay to fix the transit system for everyone else too.

Full scenario:
- SF Man attacks Waymo
- Passengers call 911
- Police never come
- Man finally breaks through window and attacks passengers
- Passengers open fire on the man in self-defense
- Police finally show up and arrest the passengers
- Man sues Waymo for medical expenses for his cut hand and gunshot wound
- Public blames Waymo for (1) inciting the incident and (2) not driving off to de-escalate
- SF Board of Supervisors demands Waymo change its terms of service to forbid armed passengers

Google includes actual headlines. News sites complain and demand payment.

Google stops linking to sites. News sites complain and demand payment.

Google links to sites using paraphrased headlines. News sites complain. (I'm sure the demand for payment will follow.)

I worked for many years at a Big Tech Company. SWEs and UX engineers were promoted for launching Shiny New Features, not for improving performance or fixing bugs in existing features.

Sure, every once in a while the company would announce some initiative to fix existing stuff. But it never helped anyone I knew get promoted.

I will believe this new initiative from MS when I hear from MS engineers that *they* are actually being rewarded for fixing this stuff.

See this slashdot article from a year ago: https://slashdot.org/story/25/...

If you configure the tool to minimize delusional thinking, it does.

Of course, if you configure the tool to maximize engagement, well...

It's easy, if you sort them first before compression. I have roughly 100 trillion of each number 0-9, and a single decimal point.

There's rarely a right way to write code, though there are definitely plenty of wrong ways. :)

Every SWE goes through phase 1, which is writing yourself into a corner by not thinking about maintainability and interfaces. And then phase 2, where you write such a complex interface that it collapses under its own weight. Only then do you get to the point where you're even aware of the need to balance interface complexity and upgradeability vs. code velocity.

Usually at that point you mock some stuff up quickly to see where the pain points are, and then go back and do a more maintainable design. And try to convince the manager that the mockup is *not* production-worthy code, because it's full of shortcuts and empty of tests and light on error handling.

Even if you're coding something the right way for the *current* requirements, it may not be the right way when requirements change. Which they do.

But if you're writing code for money, there are finite resources. So you never get to do everything the way you want. Sometimes you skimp on error handling. Sometimes you skimp on tests. Sometimes you tunnel holes in your API to get at that one state variable that just isn't cleanly exposed and yet absolutely critical to patching some other bug. All those things add risk. And at some point, you need to mitigate at least *some* of that risk, hopefully *before* it costs you downtime / money / customers.

It's always a hard sell to management.

And it's often a hard sell even to the engineers. If you want to get promoted, you're far better off writing a spiffy new feature rather than decreasing technical debt.

We've had decades to write poorly-tested poorly-reviewed code. But that's ok; as long as it kinda worked, we insisted on shipping it.

AI is now good enough to show what I told my managers for years: That technical debt builds up, and at some point the bill will come due.

The bill is now due.

Thanks to AI, it's now easy to find bugs. And relatively easy to confirm they're exploitable. But thanks to all the rest of the technical debt, much harder to fix the bugs. AI isn't good enough to fix the bugs yet, either, at least not without creating new ones just as fast. So it's a target-rich environment for hackers.

I'd say "I told you so", but I got out of that rat race a few years ago.

That's how the headline clipped on my feed.

Was unsure whether it would complete as "Children", since Chihuahuas don't get that big.

I guess Chinese Robots would be entertaining too. Do their heads fly off if their opponent lands a punch?

From https://www.masscec.com/massce..., they expect to draw 3kW - 10kW for 3 hours, for a total draw of 9 kWh - 30 kWh.

We have a Kona EV with a 65 kWh battery, which we limit to 80% charge to maximize battery life. Their expected draw is 14% - 46% of battery life. With our existing V2L adapter, the Kona can specify the minimum battery level where it will cut off. If we set it to cut off at 60%, then they could have 20% of the battery, but no more. 60% is enough for all our expected driving for a couple days, so I'd be comfortable with that. But also, odds are that the power drain event will be in the evening, and there'll be plenty of time overnight to recharge back to 80%.

Lithium batteries don't like being charged all the way to 100% or drained to 0%, but running them back and forth between 60-80% won't measurably damage them for thousands of cycles.

If the software were better, we'd be able to say, "We want to be back at 80% at 5AM. And in any case, we want to keep at least 60% of our battery for our own needs - driving, V2L for our own house in a power failure, etc. Within those constraints, you're welcome to the rest of the power, but we're selling it at $0.60/kWh. If you *really* want power, we'll go from 60% to 40%, but it'll cost you $1.00/kWh below 60%." And then the grid could decide whether it's willing to pay our price, and how much it wants.

See https://www.iea.org/reports/em...

"Today, oil and gas operations account for around 15% of total energy-related emissions globally, the equivalent of 5.1 billion tonnes of greenhouse gas emissions."

The 50% number is like claiming that Taco Bell is responsible for the water use of people flushing the toilet after eating a taco.