It's the same with any open source project: it starts open, then it becomes clear that maintaining it is not cheap and takes up a lot of time. The developers create a hosted/paid version to pay for their time, and to create an incentive to use the hosted/paid version they start releasing closed source enhancements. After that the open source version becomes marketing where new projects use the OSS version and then upgrade once their needs become more sophisticated.

But this not true. It greatly depends on what type if lawyer it is. They can operate very differently.

When it comes to docs, lawyers try not to reinvent the wheel on every doc. It’s very risky. They want to use language that has stood up to the test of time. So they have templates and old contracts and they will piece together a contract from that - it takes no time at all. AI writing new stuff every time using new language doesn’t save much time and puts a client at risk because nobody knows how that language holds up in court.

Many attorneys have paralegals who do the actual work. Those paralegals are much cheaper. Efficiency arguments don’t often take them into account. Most legal tech companies don’t think about paralegals. But they are often the real workhorse in a legal firm. But automating them doesn’t really speed anything up: they do a lot of varied things and are not just mindlessly following some process like a factory worker.

So what do lawyers do? They advise clients, they project manage, they research, they talk with other lawyers, sometimes they go to court, they review work, they work on getting new clients, and yes sometimes they write legal docs. Then at the high end of things, they come up with legal strategies and solutions that AI has never seen before.

In corporate law, legal is often budgeted in. It’s expensive but it is often ROI positive. Legal mistakes are incredibly costly.

Having said this, are lawyers pretty slow to adopt new tech? 100%. Word processors replacing typewriters was seen with a lot of suspicion. Email too. The cloud too. I think AI will have a big impact on law - but it won’t be as simplistic as a little doc generator an engineer cooks up one night in his bedroom having never even met a lawyer. The law is quite gray and so even if you have found something impactful, attorneys manage risk by looking to see what others are doing. If there is social proof, they are more likely to accept it.

So they started to loosen things: you can follow others, posts can be public, your feed becomes a mix of posts in your network and friends posts, etc. Now it is resembling Reddit. Numbers go up!

That is to say: these pure friend social networks start off with the right intentions. But with a similar product and incentives, you’ll end up right around where Facebook is now. If you want a different outcome, you must start from a different place.

Tech in general has changed quite a bit though. I don't know how Steve Jobs would have reacted to AI, and I don't know where tech itself would be if Jobs were still around. But I do think the next evolution is due and yet to be seen. It's not clear that Tim Cook would be the one to effectively see that through. And so I think his timing is impeccable and probably aligned with what is best for Apple. I have a lot of respect here: time has shown that a lot of leaders don't let go until its too late.

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.