Agreed, this is totally solvable. You could even set up an email address for people to send pictures of their receipts to so they know who to investigate. Imagine if you could just screenshot a bill and send it to "[email protected]" and then they'd assign someone to look into it!
To me, the fraud is the issue. If the person actually has the knowledge to spec out the whole technique, then sure, they can ask for it. But if they just said "give me what you give Apple" or describes it in detail and the vendor says "no I only will give that when Apple says they're okay", I don't see anything wrong with that either.
The crucial part of why non-competes are gross is that they're trying to enforce what you do after someone stopped receiving anything from the past employer. If someone is helping competitors when still working somewhere, or actively taking stuff from their past employer after they've left, then yeah, of course that's dumb and should be punished. But there's no reason a non-compete clause is needed for that!
A corollary to this I've experienced (and observed in many others) is that maintainers of good tools will very often have a much more negative perception of how users collectively view their tool than how they view it in reality. It can be hard to tell the difference between "10 users complained to me today about bugs/missing features and 9990 used it without issue" and "10 users complained to me today about bugs/missing features and 90 used it without issue", despite there being a huge amount of effort needed to go from having 90% user satisfaction and 99.9%.
I have a strong suspicion that this is a major factor in why so many open source maintainers experience burnout; the unhappy users are going to be more visible than the happy ones, and the fraction unhappy new users needed to produce the same volume of bug reports/feature requests goes down with respect the to rate at which new people start using something. This essentially creates an illusion to the maintainer that no matter how much they work to improve things, nothing they do has made a difference in the overall quality of what people experience, and that saps the motivation to keep going.
I don't really have a good solution to this problem. The only obvious answer is to be more vocal with praise when something works well, but that's the type of collective action problem that tends to not really ever happen in reality. I've personally tried to go out of my way to give frequent and enthusiastic positive feedback when something works well for me, but unless everyone starts doing this, I'm not going to be able to make too much of a difference.
Yep, I think I agree with pretty much all of this. There are a lot of cases where clearer naming can avoid needing comments, but there are also some cases where the code itself won't be clear enough. My personal stance is that in a world where nobody is immune from accidentally making a mistake in logic and writing a bug, comments that clarify the intent of code that might otherwise look strange are valuable for future readers of the code (whether human or LLM); at worst, they can potentially help someone avoid wasting time going down a rabbit hole because Chesterton's fence didn't have a signpost on it, and at best they actually expose gaps in what's handled when someone is able to notice a discrepancy between what's documented and what's actually happening.
Clear code takes precedence over commented code if either of them could be used to solve the problem of communicating what's going on; comments are still useful in the cases where clear code isn't always enough. Of course, being able to discern whether there's a way to make the code cleaner to avoid needing a comment is an art rather than a science, and it's a skill that I think few people excel at (and judging by how so much LLM-generated code is littered with inane comments, one that's also pretty rare in agents)
I don't understand what anything you're saying has to do with what I said. My claim is that "groking the code" is not a binary, and you can balance between full vibe mode without ever reading it and requiring that you understand every single line, with the corollary that it's at least plausible that being on the far end of the spectrum where you never read it isn't safe to assume is the global optimum, and your rebuttal seems to be "well it's not the global minimum".
> I've found LLMs to be best with more constrained type systems: they are better at ocaml than they are at typescript.
When the potential set of behaviors you could write a program to have is infinite, but the actual behavior you want is singular, a programming language is more importantly defined by which ones it eliminates up front than which ones it lets you write (assuming it lets you write the one you want at all, but that's almost always going to be the case for most general purpose languages). Bugs are just false positives in this framing, where the program you wrote seems like the one you wanted, but there's some divergence between what you thought you were getting and what you actually got, and catching some of those up front is a huge part of why type systems are so useful.
How did you know you're not stuck at a local optimum where the AI could iterate even faster if you enforced higher quality on what it produced?
To make up some hypothetical numbers in order to illustrate with math: if you ship bugfixes 10x faster but then have 11x more bugs you need to fix, that's not a net improvement. Even if it's only 5x more bugs, maybe you could reduce that to 2x if you changed how you worked to only be 8x as fast in a way that produced higher quality code. Similarly, maybe you could cut the time it needed to produce a new feature by 50% if your code were higher quality by moving 20% slower.
My point in all of this isn't that you literally need to work the same way you did before you had these tools, but that framing it as either "move fast and ignore the code" and "use the same exact heuristics you would in the pre-LLM days for what code is acceptable" is a false dichotomy. If you aren't thinking about how effectively you're using these tools and whether there are changes you could make to move even faster because "AI go brrr", I think you've lost the plot in the same way you probably think that other people in this thread have.
Sure, but the proportion of code that drives homicidal behavior is heavily weighted towards non-comments. You're a lot more likely to piss off whoever inherits your code with the code that actually does something being bad or a lack of documentation than with comments.
I noticed this made it harder two, but thinking more about it I started to wonder if that would make it possibly to just spam it for the lower length words and make it easy to brute force within the 30 second timer. After that I started only looking at the letters as a reference occasionally and trying to think through combinations in my head while looking at some of the blank space, and I found it actually helped a lot! I wonder if staring at whatever layout the game gives actually ends up anchoring in a way that hinders.
I got to 12 on the puzzle yesterday I think and I figured " okay, I might as well finish one" and started going back day by day in the archive..it took me almost a full month's worth to get an 18/18, and I think with only one exception, every single one I lost on felt like I had tried every reasonable combination in the 30 seconds only for me to see the reveal that it was an extremely common word that I was shocked I couldn't come up with.
My theory is that if there's a small but non-trivial chance for our brains to for some reason fail to recognize a word, stringing together enough of them in a row will end up causing most people to suddenly have that moment out of nowhere. It kind of reminded me of that episode of Friends with the bit about writing down all 50 states in a certain amount of time; perfect consistency even for things we know well can sometimes be surprisingly hard!
NVMe SSD prices had being gone down in price for a while, and the spikes are actually a lot more recent than you might think. From double checking my Amazon history, I bought my wife a 2 TB NVMe SSD for $160 back in November; it's now listed at three times that. I imagine that a lot of people just have them already from the past few years.
I'd be interested in seeing this when you put it up! I've managed to get upwards of 300 tokens a second somewhat consistently on the desktop I already had gotten for gaming/personal project stuff several years ago (64 GB RAM, Ryzen 9 7900 X 12-core; I already had a fairly large m.2 SSD and a Radeon 6900 XT to plug into it), but only by severely compromising on the model (a custom quantized Qwen3.5-27B-Q2_K which someone published on huggingface) so that I can use a context size large enough that interfacing through opencode doesn't manage to run out of context while summarizing for compaction and then trigger a second "nested" compaction that instead just seems to cause it to lose all context and ask for a full new set of instructions from scratch. If yours ends up being anywhere as close to the one I've been using in quality, and it works on a 36 GB Mac, it sounds like it would be worth it for me to try out!
(For clarity, I have almost no idea what pretty much any of the terminology for models even means or how it translates to what the actual experience is. My strategy has mostly been using the free tier of OpenCode Zen to ask it stuff about what models and llama.cpp configurations to use in the hopes that I could maybe bootstrap something halfway decent to use locally, and so far what I've managed to get running is mediocre but at least passable)
Ah, I understand now. That said, I still think there's a pretty strong argument that this is a lot worse for Zig than a GC language, because they also give you safety for that overhead (and potentially ergonomics). When a language is trying to operate in the same niche as C with what seems to be an overt attempt to be less cumbersome than Rust even if it makes it less safe, it's a bit concerning to see that even without the safety it seems to have more overhead rather than less. Put another way: it sounds like it might as well just add a GC if it's not going to be competitive on performance.
> with knowledge specialization becoming unnecessary, and eventually unfeasible due to the triviality of AI making it not needed for a human being to study a hyper-niche subject for 4-8 years
Do you have any particular reason to believe that this is a likely outcome, other than assuming that you can tell the difference between an exponential curve and a logistical one before the inflection point? I've heard a lot of people make predictions like yours over the past year or so but I've yet to hear any basis for it that doesn't end up being essentially just a hunch that there can't possibly be any diminishing returns before then.
If I have to use a machine that isn't running Arch, I'm having a bad day
[ my public key: https://keybase.io/saghm; my proof: https://keybase.io/saghm/sigs/DPNipzU12DFt2TdiKBXbNoK5ONvpotGxHAeUPWZvCi8 ]