Either engines should put some limit (e.g. VARCHAR(2000) to enforce length to be limited to 2000, but there are some other engines supporting unlimited BLOBs), or decoder should give a hint what is the maximum length it will yield. Unfortunately current research level project does not have such considerations implemented yet...

D[A,B] := number of ways to navigate from grid sized AxB = D[A-1,B]+D[A,B-1]

and the aha moment is realising this is just a binomial coefficient.

Having progressive tax rate might be a better way to discuss, instead of blaming whole points.

e.g. Without proper regulations, your maintenance can become nearly impossible.

If it manages to solve the working solutions - then it's great! why would you waste your time on it?

It it fails - then it's great! you find your value by solving the ticket, which can be a great example where human can still prevail to the AI (joke: AI companies might be interested to buy such examples)

(All assuming that your time cost is pricier than token spending. Totally different story if your wage is less than token cost)

It's 2x efficiency. Then I'd take 50% less power instead of ridiculous 99% less power.

1. Keep things small and review everything AI written, or 2. Keep things bloated and let AI do whatever it wants within the designated interface.

Initially I drew this line for API service / UI components, but it later expanded to other domains. e.g. For my hobby rust project I try to keep "trait"s to be single responsible, never overlap, easy to understand etc etc. but I never look at AI generated "impl"s as long as it passes some sensible tests and conforming the traits.

Surely the reality might be much more complex (like... the yield/quality drop by time function?)

edit: Microsoft or other companies have no financial benefit on that fight. Even Deno itself has no financial benefit as well. This fight is for goodwill but not justifiable for financial terms (unless you can be the next owner of JavaScript trademark)