I read your statement and my reaction is what you describe is less regulated than sports betting. For example, in sports betting there are laws by major leagues that players can not bet on games they are in. On prediction markets, if someone has insider knowledge, or can control whatever verification source is set for a bet, they can win (I believe there was an article posted earlier about some journalist reporting on a bomb that fell on an area and was pressured to change the wording to say it fell or was bombed). Additionally, as some of the prediction market wagers have weird grey areas, there are predictions that have additional sub text added after a market has been open/wages have been made which completely change the bet - that is just fast and loose and less regulation IMO
My main proposition was that prediction markets include sports betting as well as a bunch of other things, and they are therefore more regulated.
Did some research, and Kalshi (US based) is regulated by the CFTC, so they are already regulated by the same stuff that regulates securities, including price manipulation.
The subject of insider information is different because these are not public securities, there's no fiduciary responsibility. But it's not that there are no regulations, it's just that that specific regulation that we associate with the 2008 crisis just doesn't apply. But that doesn't mean there's no regulation, there's heaps, feel free to check out the CFTC website.
Ticketmaster does something very similar to this with their "demand weighted pricing" and it is just so sad that their solution to "scalping" is "let's bring that profit into our platform."
I dont know what I was expecting on the roadmap page after you said it was not a roadmap, but I did not expect to see a whale jumping over a human as part of the "roadmap"
To share something different, it is less about what I have built, and more about what I have seen my friends (non-technical and technical) build. In a one month span I have seen a lawyer make a personal red line tool, a sales guy make a custom website for a golf trip, another friend make a 3d printing grid-finity project, a friend make a stl file to print a jig for his table saw, and another friend make a full mobile game. It is just really cool to see these micro-projects be created and shared, not only for the utility, but just to see my friends' childlike excitement showing off their project.
- It can make kids "overconfident when they see material they think they already know, so they end up not engaging."
- Some programs, particularly RSM, are criticized for valuing speed over depth. Current culture for K-8 math teachers is the opposite, they value depth over speed.
Left unsaid:
- It can make the teacher's job harder when the class has a wide span of abilities.
- Current teaching culture is skeptical of accelerating and/or skipping grades in math.
Notably, we've never heard English teachers be upset about a kid reading a book outside of school that's above grade level, or using advanced vocabulary in an essay. They tend to praise it.
Got it, thanks for the response - I think my honest reaction is shocked by reading this. I was always good at math and it was such a source of pride and sense of accomplishment. In english I struggled, vowel sounds, grammar, it just didn't come naturally to me. I'm a little disheartened by this slide (for lack of a better word) of public school education, especially STEM.
Maybe part of it is that math is objective and writing is subjective? A math teacher could be called out by a 13 yo for “being wrong” but for an English teacher, what is “wrong”?
Not the OP. I assume the public school teachers don't want to answer when the student says "my Russian math teacher said to do this" instead of the common core math that is being taught.
Our high school computer science team did a StarCraft LAN party on a flight coming back from a coding competition. We felt like the coolest kids in the world when we did that.
I don't like outsourcing learning and prefer to do the actual learning. Just like taking notes via recorder vs writing them down during a lecture causes you to not remember the information as well. Allowing something else to create your code tends to mean you're not going to remember/know the how/why it works and you just accept it works and moves on. Eventually you don't know how any of it works and you're totally dead in the water without the LLM. My understanding of the code I write is much more valuable than some arbitrary deadline that means nothing
Do you also inspect and study what assembly code your program was compiled to?
// Obviously LLMs are non-determenistic etc and it depends on your domain, but your VP's point 100% makes sense if you folks are trying to cook up another demo-CRUD apps to convince investors for another funding round
I keep hearing this argument on HN. Yes, if performance is something you care about you totally look at the disassembly. You don’t even need to write assembly, just be able to read it. By now I assume that programmers who argue they don’t need to understand and review what the LLM generates for them are simply not that skilled and don’t realize that skilled programmers do this.
If you're just building a non-security-sensitive frontend to validate market traction, it makes total sense to go full AI. The commenter working at a 10-person company getting flamed for not using AI to iterate aggresively against competitors has a super valid point.
Validation methods will evolve to accommodate human laziness. Insisting on doing it the hard way is no different than the old-timers who used to claim engineers 'weren't skilled' if they didn't know how to use punch cards.
Ad hominem. Skilled programmers != old-timers calling others unskilled. Who does fuzz testing, automated integration tests, etc already, that LLMs need as a test harness? It’s not the vibe coders saying “nobody reads assembly anyway” as an argument.
I'd definitely say IntelliJ improved my productivity. No one cared. If anything, management viewed it as a nuisance as they had to deal with the license.
Now there is demands to justify not using AI like this, but people don't care about details. Which AI tool I use apparently doesn't matter at all, even if there are presumably productivity differences between them.
Seems like you should have a justification for introducing a new tool instead, no? There are thousands of other tools they're also not using, but we're not asking about those.
I'm not the same person, but I don't really use it. I write better code than an LLM, and I do it faster than the time it takes to review and correct the LLM's bad code. The tool has no value to offer me.
100% - I think that is also part of the divide you see online. Devs who work on massive codebases w/ 100s of engineers and see the bugs the LLMs create vs devs who work on smaller codebase w/ small <5 person team.
Small teams building continuously get to write features that are 90% correct in a tenth of the time.
Big enterprises get to write features that are 90% correct barely twice as fast, because all of the bottleneck lies elsewhere. They also spend more on AI per user because of the internal dynamics pushing people to adopt AI irresponsibly. They can correct the 10% of errors slower than small teams because of bureaucracy, increasing the cost of errors that show up in the product. Furthermore, they have less to gain from a given amount of speedup because they had plenty of engineering velocity anyway compared to small teams.
I don't think big enterprises will start winning from AI technology until AI truly can automate almost everything in a company and let said company outproduce competitors by burning tokens alone. That's nowhere near possible right now.
I don't think "90% correct in a tenth the time" is really the tradeoff. For a well-specified task, it's closer to 100% correct in 1/100th the time. But that undersells the time required to generate a good spec.
For under-specified tasks, it's not really accurate to talk about "correctness," because the machine isn't psychic. I would suggest that given a high-level feature request like "add streaming support" it's more about acceptance probability. In a well-structured and well-documented codebase, and a reasonably sized feature request, there might be an 80% chance it will generate something which is 100% acceptable. But there's about a 99% chance it will generate something which is acceptable after 1-2 revisions.
What an egregious mistake. "exhibits a pattern consistent with an individual operator using the repository as a working scratchpad or synchronization mechanism rather than a curated project repository" - isn't is git 101 to not put creds in git? What pattern do they think this is consistent with?
They're not defending it as an established workflow pattern or some kind of best practice.
The usage of "exhibit a pattern consistent with..." is just describing what it looks like the repository was used for. i.e. it's not a set of government sourcecode for an internal project, it's not something indicative of intentionally leaking large amounts of data, etc.
If I had a dollar for the amount of secrets committed to public repositories I could probably retire. No, that isn’t an excuse. Pretending the US govt isn’t made up of people just like you or I is quite silly.
Your general point here is reasonable. But to provide some domain knowledge context: secrets are leaked _very_ often!
In public data (source code on GitHub, etc.) you can expect a prevalence somewhere in the range of 0.5-2.5 live secrets per gigabyte of content. Now yes, there are more than 8 billion people on earth now and the murder prevalence is a lot higher than 0.5-2.5 per billion. But there are _far_ more bytes of public content than there are people on earth, so in absolute terms, there are far more leaked secrets than murders.
If you look at other types of data (like internal Git forges), the prevalence is much higher.
I think you could indeed retire with $1 per leaked secret!
“Experts who reviewed the exposed secrets said the commit logs for the code repository showed the CISA contractor disabled GitHub’s built-in protection against publishing sensitive credentials in public repos.”
This makes it seem more intentional to me. Regardless of what the ultimate purpose were use of the repository was it says to me, the person knew what they were doing and it wasn’t just an innocent oversight like anybody could’ve made.
If I had a dollar for each secret I’ve committed to a public repo, I could probably buy a couple of sandwiches. I’m not smarter and my opsec probably isn’t any better than most old devs, but I also don’t have a treasure trove of government secrets on disk and—crucially!—_I would make different decisions if did_.
The nuance here: when I’ve slipped and committed secrets, it’s typically a relative nothing burger: most common case is API keys to some third-party service. I’ve worked across a bunch of regulated industries and, within those, not caused a breach—because being in that space you know to be more careful, and because the companies in those spaces (wisely!) tend to support good security practices, more so than the industry average.
reply