Yeah, I've worked in the industry for a long time. I think good regulation would prevent per punter limits. I don't really see why doing this would make the industry unprofitable, the odds have a margin baked in, exactly the same as a 0 (and in the US the 00) in roulette. Worst case they would have to increase the margin, which maybe isn't so good for casual players but at least it's a level playing field.
I also find the common implementation of in-play delay poor. The way it generally works is a delay is applied before confirming the bet, anything which changes (including pricing) causes the bet to be rejected. The main reason for this is that the traders sometimes only have access to something like sky sports so their feed is quite far behind someone at the stadium. I feel like in reality it should be based on official timings.
The problem with this is liquidity, particularly well before an event. It's why the original exchange (or at least the first one I'm aware of) also now offer a normal sportsbook.
Academia isn't my thing but I also wonder if there isn't an aspect of putting a stake in the ground? So that if someone beats you to publishing you at least have some record of being on that track.
That is definitely a big motivator for publishing preprints. Journal submissions can take up to a year. Comference submissions take months. If the field is moving fast, claiming a finding early can become an important career move.
In older days, academics would just share notes on their work and word wouldn't usually spread widely before publication.
Preprints may be the better model. But public visibility means that non-experts now get to see the good and the bad research equally, but they won't have the domain knowledge and skill to distinguish one from the other with confidence.
I think robotics AI revolution will come just a few years after the knowledge work AI revolution. We already have very promising robotics systems in active development.
I'm not sure how you take that from the original article. My 4 year old would drive that course in an automatic car, if only he could reach the pedals. Heck, he's done harder things at Lego land.
I wouldn't let him loose on the road though.
I think, at the very least, the guardrails would have to deterministic, ideally with super human senses, for people to accept self driving cars on the road.
Almost certainly, there are 4 year olds who ride small motorbikes etc. I think the main problem is that they can't really be held accountable if they have an accident.
Nope, no "deterministic guardrails" for you. The domain is simply far too broad and unstructured to allow for that.
Unless you mean "a typical AI with all the computation constrained sufficiently to always unfold the same exact way, given the same input". In practice, that just kicks the can to "given the same input" street.
The noise in the system is going to come from the input plane. Which is, I remind you, facing the real world. It's full of noise.
Even looking for companies which supply services is now far better on AI chats than Google. For me being visible in AI training is going to be more important than search in the next year or two.
If I was a big AI company I'd certainly be tempted to make sure that anyone who excluded themselves from "AI training" also got themselves excluded from AI results.
I think the main problem in England is that there is just too much traffic for too little road. I don't think there is a simple infrastructure solution to that problem.
For example I was going to point out that roundabout completely fail when one direction becomes nose to tail congested but when I thought about local examples, I'd rather take that over a set of traffic lights where it becomes near impossible to get out from one direction if the traffic keeps backing up onto the junction.
> I think the main problem in England is that there is just too much traffic for too little road.
I think Jevons paradox basically guarantees this in both countries. The difference between the two countries (in my theory) is how much responsibility they're willing to place on the drivers. The UK requires much more driver effort for good reasons I suggest in another thread.
In the 90s aircraft manufacturers basically stopped whole segments of the market (anything smaller than a piston twin) due to litigation. I wouldn't be horribly surprised to find we spend the next 10 years fighting about this stuff in court.
I'm fully aware of lots of times powerful companies have used the courts to protect their business. My point is basically all of the powerful companies are elbow deep in LLMs to the extent of some sort of mutually assured destruction if they were to start court cases like this.
LLMs have been firing out a lot of code for a year or 2 now at least, so I would have thought we'd start seeing some court cases by now?
It's purely conjecture at this point but my gut feeling is most companies are in high spirits about the costs they can save and the benefits it can bring to their own business. I don't think enough time has passed to see really high profile losers. What happens when Infosys starts losing money or Free CAD becomes the next SolidWorks due to LLM driven improvements?
The lack of modern small airplane designs, especially engines, is the extensive and thus expensive certification process. Most of what is a "new" airplane usually is derived from a very old, grandfathered design.
The only real innovation for small planes is in the electric flight area - when you gotta do a full certification anyway as you're piloting an entirely new drivetrain, you can financially afford to be much more innovative on other parts of the design.
I personally would never dump a claude code response into a PR body an ask someone to address it. I can't believe any developer would find this to be appropriate or fulfilling the duty of reviewing code.
I think it's pretty clear that what you should do instead is go over the result and communicate to the PR author anything you think should be addressed. You don't just say "here are 8 things you might want to address but I cant actually speak to any of them."
To add to this, the fact that Claude so often tries to deviate from defined architecture can be really frustrating if you're working in a mature codebase.
That scenario would be annoying but it's not what we have. The agent joins the PR leaves a few comments and responds (with mixed success) to comments. Personally I'd go back to 2020 and never see an LLM again quite happily but that genie is out of the bottle.
Unfortunately, the results speak for themselves and I could probably find dozens of edge cases which the AI code review caught which would have otherwise been missed, probably until production.
I think there is a subtle difference between you-or-I dumping a chat paste into the PR, versus an automated agent directly commenting in a PR. The former carries a human social implication, the latter does not. The weight of them is different.
If you are talking about AI's opening PR's then maybe you have a point. But a person opening a PR should not be met with unvetted feedback.
To be absolutely clear, AI should be used for PR review. It should be used many times. By the PR author and by all the reviewers. It should not just be piped directly from the agent to the author inside the PR. That causes the author to triage every comment.
That sounds good. But it doesn't work in practice from my experience.
The exact same skill in the hands of one person will have vastly different outcomes in the hands of a different person. The review skill I built myself has been shared with folks. They (say they) use it before they put up a PR. I still catch things with the same skill. That is evolving as I catch the model(s) at BSing. Even if I would re-share it all the time, when I catch it, these other people using the same skill wouldn't catch it.
And that is exactly why building a general purpose review agent (or skill) is harder than me having my own evolving skill. If I have to "properly" release a skill/some automation, I will likely err on the side of not having too many false positives. That is harder than still relying on a human to review the AI reviewer. The same people that were really good actual human reviewers of a PR are probably the ones that are good doing the same thing while AI assisted. And the ones that really needed these other human reviewers and processes to help them be productive are probably going to produce a vibe coded mess if left to their own devices with nothing but some AI.
Have you tried running the same review skill back to back in fresh sessions? My experience has been: 1) build complicated thing with LLM, 2) run code review, 3) it finds like 8 things, 4) fix them, 5) run another code review, 6) it finds another new 8 things, rinse and repeat.
I'd guess people truly are finding things pre-review. It's just that LLM review seems to have a limit to the number of problems it can or will find. While at the same time, LLM-written code can be an almost limitless source of bugs and errors.
It has no sense of when an architecture is doomed and needs fundamental changes. Instead, it will happily continue to chase individual bugs nearly to infinity.
But, maybe your review skill is better than the ones I've tried.
With the way memory systems work, I can see the value in having a different person's AI conduct the review as that AI's 'memory' is going to have a slightly different perspective aligned with the developer piloting it
I also find the common implementation of in-play delay poor. The way it generally works is a delay is applied before confirming the bet, anything which changes (including pricing) causes the bet to be rejected. The main reason for this is that the traders sometimes only have access to something like sky sports so their feed is quite far behind someone at the stadium. I feel like in reality it should be based on official timings.
reply