People seem to think that just because it produces a bunch of code you therefore don’t need to read it or be responsible for the output. Sure you can do that, but then you are also justifying throwing away all the process and thinking that has gone into productive and safe software engineering over the last 50 years.

Have tests, do code reviews, get better at spec’ing so the agent doesn’t wing it, verify the output, actively curate your guardrails. Do this and your leverage will multiply.

I can see a car company who doesn't care about design stumbling into this outcome, but Ferrari doesn't seem like that kind of company. So the choice must have been intentional.

There are any number of ways to foot gun yourself with programming languages. SQL injection attacks used to be a common gotcha, for example. But nowadays, you see it way less.

It’s similar here: there are ways to mitigate this and as we learn about other vectors we will learn how to patch them better as well. Before you know it, it will just become built into the models and libraries we use.

In the mean time, enjoy being the guinea pig.

First, the cost to transcribe audio is not free. It is computationally expensive. Any ad network or at scale service would not be able to afford it, especially in orgs where they are concerned about unit economics.

Secondly, the accuracy would be horrible. Most of the time, your phone is in your pocket and would pick up almost nothing. More over, it’s not like you are talking about anything of value to advertisers in most cases. Google is a money printing machine because people search with an intent to buy. The SNR of normal conversation is much much much lower. That makes the unit economics of doing this gets much worse.

Third, it would be pretty hard to not notice this was happening. Your phone would get hot, your battery would deplete very quickly, and you’d be using a lot of data. Moreover on iOS you could see the mic is being used and the OS would likely kill the app if it was using too many resources in the background.

So until we find an example of this actually happening, it’s not worth worrying about.

In an emergency, you want doctors who are used to making decisions under stress and who are aware of their impaired decision making abilities when tired. This is a rite of passage that means in a true emergency where they have to be making good decisions without adequate resources they can do so. You see a similar tactic when training military recruits.

But in terms of scrum and points here's my take:

I've seen points work on some teams and not work so well on other teams. It's imperfect, but if you just accept that, you can make it work quite well.

The reason it's helpful to estimate complexity as opposed to time is that people with different experience levels would give different estimates based on their abilities. Complexity allows you to rally around a common understanding of a solution regardless of how fast one team member might be able to complete it versus another.

Does complexity have some relationship to time? Absolutely. Everybody knows this. That doesn't mean that we should be using time instead.

So how can a team estimate accurately? You will hear from some people that their estimates were wildly off or that it's impossible to estimate a project or they felt pressure to under-estimate. If your estimate is too broad, you need to do the mental work of breaking it down into smaller chunks that are easier to estimate. If you feel under pressure to ship on an unrealistic schedule, that's not a points/scrum problem. But the "it's done when it's done" is also not realistic either.

The idea that the estimate has to be 100% spot on is also not true. Again, it's imperfect and that is ok. But you'll find that the better a team knows their codebase and knows the product, the better they'll get over time at estimating. But if the work is too vague, the team should push back until they have enough information to more accurately break things down. This process makes for better software, especially when the team does it together.

Another missing aspect I see a lot is having a feedback mechanism. If you as a team are discussing why a task took longer than the estimate, or track metrics over time, you can all get together and figure out where problems on the team are. For example: maybe there are too many bugs that are hindering product work? Why? Maybe you're moving too fast vis-a-vis the expected quality bar. Some sort of feedback mechanism (e.g. retros) is crucial - the team as a whole should aim to deliver what it says it would and understand why it couldn't.

The whole point of these things is that as a team you can deliver consistently not more speedily. Consistency comes before speed. The other important thing is having a way to continually improve. You want to use each sprint as a way to measure the team so it can get better.

When I've seen teams that did this well, they were dramatically more productive than the teams that didn't do it well.

Most companies would love this, especially startups. The problem is that desirable candidates do not love this arrangement - there's an opportunity cost and risk for the candidate here and if you're in demand you can get a solid offer from a company who isn't trying to hedge.

What does it mean to "last longer" when it comes to your own codebase? And why would web components help with that?

In terms of building a web app where you control the environment end-to-end, I don't think there's any inherent upside to using Web Components over React.

Big deployments generally need really good support and help to overcome scaling challenges. Who better than the library maintainers to offer that, and your customers have deep pockets.

Then on top of that, you run a business which basically creates proprietary Pro and Enterprise versions of a product which has tooling to operate the project at scale or in high uptime environments.

Then you offer your own cloud versions of the product as well (which I think Redis has been doing).

But in none of these cases are you creating a disincentive for anybody to use/adopt your product. You're simply creating value around the pain points.