simonreiff

I really don't want AI-generated copy to walk me through how to understand various famous paintings by answering 8 boilerplate questions about each of them. If the answers were written entirely by a human who was an art expert, though, I think I would feel completely differently. There's an idea here that seems appealing (look at a collection of famous paintings, and learn the most interesting things about each one, what to notice, etc.), but the AI copy is a complete turn-off for me.

I fully agree with everything in this essay. Make distillation fair use. And let us use Mythos/Fable and Sol and successor or future models for all cybersecurity purposes.

That sounds like the worst "exam nightmare" scenario imaginable, but did the student get the PhD in the end?

Being charitable, "more scientific" means more rigorous, reproducible, reliable based on the consensus of that scientific community (if any consensus exists, which it usually does in math and hard sciences), transparent in methodology, and candid about authorities cited and limitations to the experimental approach. Science is not a style guide; the purpose of a research publication is to impart a result to experts in the field and make claims that can be rigorously scrutinized. The best way to make a claim credibly is to demonstrate full fluency with the tools and techniques of the academic community in applying them thoughtfully to the chosen problem. But the result of doing that often looks downright impenetrable to the general public; see, e.g., Niven 1947 (1-page proof that pi is irrational). It's not the point of science to make it accessible to everyone. The point is to convince experts in the field of the correctness of the claim. The audiences are often totally different, and the tone and qualities of the writings likewise must vary.

I have to concur, unfortunately. This isn't reliable, reproducible, or interpretable.

Wow, congrats on this project! Really cool. I majored in piano performance many years ago and will definitely check this out.

Sorry to hear about the stress of being a founder; I also am a solo founder and feel the pressure every day too. For what it's worth, you've already achieved something very special if you have thousands of users. That already shows you are building something that others find genuinely useful, entertaining, or worthwhile. Also, not to minimize your situation, but your age and situation is probably an advantage here. If you pivot to a completely new venture or get a job, you have lots of time to build something else really successful.

I suggest re-engaging with your friends and family. It really will help you figure out what you want out of life and of this ongoing venture. Doing that will help you realize what really matters to you. Perhaps you'll find yourself reinvigorated and will dive back into the work even harder than before. Maybe you'll just have a clearer picture of what your exit strategies might be. Either way, you'll be glad you reconnected with the people who care about you. It's more important to do that than any startup ever could be.

Anyway, wishing you best of luck.

Question: Why does AWS need to roll back estimated bills to a "last known good" state? I get wanting to do that for ACTUAL billing mistakes, but for estimates, they're just that -- approximations. I guess it's fine for predictive purposes to store estimates so they can be compared to actual usage and optimized. But why would AWS bind the values of present estimates to the estimates made earlier in the month. The calculation should always be:

1. Current month's usage * applicable rates; + 2. Estimated future usage for the month * applicable rates.

And Item 1 obviously requires proper data persistence, but Item 2 is just a projection. If they don't have Item 1 correct, AWS's whole system is in question, but I don't think that's the issue. I'm going to guess now -- looking forward to reading the root cause analysis -- that the problem is that someone decided to get too fancy with the estimates, and built a latent requirement that all prior estimates for the month must be available to compute the current estimate. Without estimates working, no estimates are available, and some denominator in an averaging or smoothing or normalizing function goes to 0; then everyone's estimated bill explodes without bound (subject to floating-point arithmetic) resulting in trillion-dollar estimates.

Nice game -- a bit more of a challenge than the usual word games, so I appreciated it. I suggest including a little demo before the game starts to showcase how it works because it was slightly unclear how the game would work before the first turn. It also would be really nice to let users choose a difficulty level based on the length of the word. I might consider encapsulating all the numbers of the turns left, or even making it a flexible option that the user can lower in order to increase difficulty. The only other nit I noticed was that the dictionary seems to be returning the secondary meaning for the word today. Overall I really liked this game as it was genuinely different and the hi/lo nature added a very different dimension to the guesswork.

FYI just 502'd

lol fair and I appreciate the feedback. I'm overhauling tbe home page to include a demo and will definitely revisit the tagline as well. (Even if I still do believe it's true!)

The author pointed out that JSON-wrangling and regex issues are a pain in the ass. I found them to be a pain in the ass in my own project, too.

He also argued that his project implemented a kernel pattern that acted as a buffer between the LLM and the outside world. I too implemented a buffer pattern in my own project.

He built an AI harness, I think it's a nice project, and if it extends MCP compatibility, I do think HIC Mouse would be a nice integration with Ambiance.

Yes, I think Ambiance is a great project and I am wishing the author all the best luck and success in the future. Yes, I gave it a GitHub star. Sorry I didn't give fainter praise?

By the way, I wrote every line of my project myself; I wrote every word of my research myself; I wrote every word of the copy on my website, including all legal provisions, docs, and blog posts, myself; I write all my comments on HN myself. I'm proud of my work and stand by my project, which ironically is dedicated to reducing AI slop and boosting accuracy so that AI agents can perform surgical, precise code repairs without ever touching or copying any other part of the code base. Let me know what you're doing to reduce slop, other than accusing people falsely of generating content with AI.

I think tools have to be flexible enough to accommodate a range of expected inputs. Even assuming models are trained to supply a particular schema, they are stochastic and randomly output variants regularly. My experience has been that it's better to try to auto-normalize the range of anticipated outputs and make tools as forgiving as possible rather than force an overly strict schema that might not match training data on the model.

I call it tool-response engineering -- the tool-response JSON object itself and any content supplied, plus the available mechanisms after an initial tool call has been made.

I did indeed read every word. And read the code. Don't be rude.

I really wish this study had chosen to focus on more useful endpoints like revenue, profitability, customer retention, conversion rate, etc....at a minimum, don't look at PRs merged without also looking at bugs in production code, number of incident reports, features shipped, debt log canceled, etc. Even if you only want to consider merged PRs, you should weigh the productivity of the reviewer and whether they are also 24% boosted or else it's just an accounting trick.

Why don't you say how you really feel instead of being so wishy-washy?

That's a good question. My view is that AI-assisted research is an important and valid use, and getting human-written articles and papers is (I think) the whole point of this thread.

However, a lot of the academic or technical posts on this site have turned out to include AI hallucinations (a problem that is not just on HN, in fairness). If an article or paper contains nonexistent or obviously, blatantly wrong citations, then I feel very strongly that such content is disrespectful to the HN audience, certainly to me, because I've just wasted my time trying to take the author seriously only to discover that the argument was founded on a hallucination. In a sense, it doesn't matter to me whether the hallucination was due to AI or not -- if a person puts in bogus citations, AI-generated or otherwise, my view is that their article or paper fully deserves to be flagged so that we don't waste other people's time.

The recent rule addition to the Guidelines says this: "Don't post generated text or AI-edited text. HN is for conversation between humans." And I think that covers comments, but I'd be happy to see it also cover articles that are blatantly and primarily if not exclusively AI-generated. But how much AI is permitted? For instance: I'm writing a blog post now. It's all mine. If I include an AI-generated cartoon at the end, just to illustrate something, but not to be the whole or primary point of the article, is that AI-generated? Would the rule be conservative in nature to the extent that mostly human but clearly also AI-enhanced might get flagged but it's in the discretion of the moderators? How would you propose enforcing as to articles (versus comments which are usually quite obvious and thankfully have pretty much stopped being AI-generated since the rule was implemented, for the most part)?

Exactly, so [0]_3 = [3]_3 = [6]_3 = ... (and here these are indeed equalities inside Z/3Z because these are equalities of sets and not just equivalences). And for that reason, we take the "best" or canonical representative of the equivalence class to be [a]_n where 0 is less than or equal to `a`, which is always strictly less than n; hence, [0]_3 is canonical.

Actually, since the modulus is often fixed within a computation or expression, we often simply abuse notation by writing:

0 := [0]_n ("zero is defined to be the equivalence class of 0 mod n") 1 := [1]_n ...

I love this topic and look forward to reading the next articles, but I suggest not saying two numbers are "equal" mod N. I would say they are "equivalent" mod N and maybe point out the broader insight: Equality is often too rigid a constraint, and we usually want to consider equivalence relations instead. We know 3 and 6 and 9 are obviously not equal, but it's useful to notice the pattern that they are all divisible evenly by 3, i.e., they are all in the equivalence class 0 mod 3.

When I think about Langlands, I think it is the power of equivalence over equality that shockingly allows us to connect the discrete world of the natural numbers (or Q) with the world of the continuous (R or C), across disparate branches of mathematics. The Modularity Theorem (every elliptic curve over Q is modular) is the foundational idea and at every step along the way, we obtain evidence of more remarkable equivalences: The conductor N of an elliptic curve versus the level N of certain congruence groups; the point count deficiency (p'th Hecke eigenvalue) of a curve and the p'th coefficient of the Fourier q-expansion; Galois reciprocity showing an equivalence between the traces of Frobenius elements acting on a cohomology, and the eigenvalues of Hecke operators; Ribet's theorem about level lowering; etc. Time and again, the theme in Langlands is that equivalence relationships make it possible for us to reason why two intricate mathematical structures that seem completely foreign are actually "essentially the same" -- not equal, but equivalent.

I really recommend Professor Gilbert Strang's linear algebra course and also would check out any Michael Penn videos, both on YouTube, but for linear algebra, the Strang/MIT course is the best resource anywhere that I know. The Gilbert Strang video series on linear algebra includes the 18.06 course, as well as an 18.06B or something like that where he goes into detail about the SVD and ML algorithms like gradient descent.

Generally if you're struggling with a math paper on the first or second page, no point in fighting it; gotta come back after you have the prerequisites. Nobody is born knowing this stuff, and also, all branches of math contain endless piles of really easy-to-describe but hopelessly difficult problems so never feel bad if you don't know how to solve a problem or even understand what you are reading. Just take your time, learn what you need, come back, a bit more hopefully makes sense, learn still more, and over time more things will become familiar.

Why exactly will AI never be able to do my job?

Because AI cannot retain memories or gain experience or insight based on the transformer/attention mechanism powering all modern AI models, it follows that AI lacks judgment and can never be trusted to handle truly critical decision-making responsibilities. Furthermore, AI agents lack any notion of an identity, so certainly are not capable of attaining legal personhood or being sued or fired, or owning property. I think slop burnout, cybersecurity, loss of privacy, even environment issues are far more concerning and real issues arising from AI than alignment or the prospect of mass labor displacement due to AI.

What you want is to guard at the outset of each API call is the same thing -- whether the user is not suspended, active, any other number of things (including more things as you add more functionality), so you want to shift the entire validation logic to its own module.

We therefore want to encapsulate the logic of all users being "qualified". I think the best way to realize this is to try to say in as few words as possible what we want. We want the user.toBe.qualified, but we can write that even more efficiently, user.isQualified(), so we can ASK at the top of each API `if !user.isQualified()` and then fail loudly and quickly if so, and then go do something afterwards otherwise. We presumably expect multiple users that will have a property of being qualified, so let's use a class:

```js

class User { constructor(data) { this.isAuthenticated = data.isAuthenticated; this.hasActiveLicense = data.hasActiveLicense; \\ many more details... }

// Now encapsulate the boolean property of being qualified, for all Users, in one place

isQualified() { return (this.isAuthorized && this.hasActiveLicense && this.hasPaidInFull && this.hasAdminPermissions); } }

// Now, we can use our isQualified() property at each of our API guard clause by checking if the user is NOT qualified:

if (!user.isQualified()) { return res.status(403).json({ "error": "Unauthorized access requested."}); }

// Critically, the API guard clause remains identical even if we change the criteria for validation and what it means to be "qualified"

```

There are of course many other ways to solve this problem beyond this approach. For instance, you could export a function called isUserQualified(user) (or more likely userId) then call it somewhat similarly:

```js

if (!isUserQualified(user)) { return res.status(403).send("Error: Unauthorized access requested"); }

```

The other approach I like is to use a factory pattern to build a userSession with function arrow notation. That's really helpful when you are getting raw data back from a database call, say as a JSON object. That would look like this:

```js

const createUserSession = (userData) => { return { ...userData, // here we use the ...notation for convenience but don't trust this as secure) isQualified() { return ( this.isAuthorized && !this.isSuspended ); } }; };

// Then you instantiate a user session from the request like this:

const user = createUserSession(res.session.user); if (!user.isQualified()) { return res.status(403).send("Error: Unauthorized"); }

```

There are actually loads other approaches too, like using class inheritance (define a parent User class and child QualifiedUser class, for instance), or types. I would say that readability here is less a concern than the issue that you have multiple APIs and if you refactor or change the logic for qualified users, now you have to refactor your most sensitive attack surface at multiple points. It's just safer to have that rewrite only happening once, wherever you put it, in my view.

If you don't, be sure to enable the `tool_search_tools_regex` ... tool.

Hey, an article right up my alley! AI infrastructure/tools engineer here (hic-ai.com); my flagship product, HIC Mouse, is a precision-editing system for coding agents designed to work across a wide array of models and harnesses. Mouse provides 11 tools exposed via MCP for read-, find-, and edit-operations, using a coordinate-based schema (as well as exact and multiple string replacement), a Dialog Box inspect/refine/save/cancel changes functionality controlled by the agent to force staging and review of multi-operation or large edits before changes are written to disk, and extensive agent guidance mechanisms or guardrails to help the agent realize if it's about to do something potentially destructive or overly verbose.

I definitely think models may be trained to use particular popular harnesses or expect certain fields in the editing-tool or other tool schemas. Rather than trying to conform to (or force) one particular format, my approach instead is to design flexibly enough to handle a wide array of possible inputs and tool calls, but that also help the agent recover whenever its tool calls truly can't be salvaged and have to return etrors, and to auto-normalize results whenever reasonable to do so. It really does make a very dramatic difference (I wouldn't have bothered to launch if I thought it wasn't a meaningful advance) but anyway, just wanted to share my perspective given that I live and breathe this problem all day, every day.

So basically there are two plausible explanations:

1. Someone with early access to Mythos leaked it to the bad guys.

2. Cybercriminals are getting enough mileage out of alternatives to Mythos to create exploits far more quickly, even though they don't have access to Mythos.

My own guess is that it's a combination of #2 plus vibe-coding degrading software quality at multiple layers, open the door to sophisticated exploits, but I have no insider access to Mythos so am just guessing. Maybe someone with Mythos access might say why they think this vulnerability spike happened when it did.

I disagree that the title "hides" that the title was small and that it disappeared for two weeks. The surviving contingent on the E. americana strain was evaluated for 60 days, and the tumor doesn't look particularly small based on the picture on page 8 of the paper. I think the study size is small (n=5) so we'd like to see more large-scale studies next, but it's already a strong result to show 5/5 (100%) at p < 0.0001 for multiple primary endpoints and the absence of success from comparable bacteria is helpful to frame future research. The absence of long-term side effects and only transient weight-loss followed by 15-day weight gain is also intriguing. I'm not a doctor, oncologist, or cancer researcher, but the methodology looks sound and appropriate to me, as does the title, based on reading the paper.

I always felt a little duped whenever I tried coding in TypeScript. You get zero runtime type safety guarantees, plus it's often harder to tell in TypeScript whether the transpilation will result in an efficient and performant implementation. Maybe the worst thing is that if you have two objects, one called EmailAddress and one called UnrelatedThing, but both have a UUID as the first thing and a string as the second thing, and now you create an object at runtime that is called TotallyUnrelatedThing that has a UUID followed by a string, the runtime sees EmailAddress, UnrelatedThing, and TotallyUnrelatedThing as being structurally identical and in fact they are all "compatible" under TS at runtime, which is usually the exact opposite of what one would expect. Now in other languages you can get some additional guarantees like in C# at the cost of more ceremony and boilerplate to establish all your abstract primitives and layers.

My own approach is mostly to prefer JS and JSON objects with helper chains including validators and constructor/builder and parser utilities. Get the age from the user and get the domain from the email address and don't be surprised by the type, because everything is an object, and don't be surprised that you need to validate and parse, but expect to do so always. Do it in as modular and reusable a pattern as makes sense, which often isn't exactly the same for every scenario, but that's OK. Speaking of which, am I the only one who thinks it's usually more of a hassle than it's worth to define a universal EmailAddress for all times and places? Often the conflict happens because even if I try to do so, I usually am using one vendor as an IdP and a different vendor for transactional emails (even if I use the same cloud provider say for both). They each probably have different robust regex implementations to check whether something is truly an email address. I then still need authEmailAddrees and billingEmailAddress objects to pass to each, respectively, but there is no enforcement or requirement to instantiate an interface that contains an enforceable contract in TypeScript, so remind me why I am bothering to say these things are both email addresses? It just always feels like the worst of all worlds when I work in TypeScript, kind of a "rules for thee but not for me" situation. I have to follow typing, but TypeScript doesn't quite have to do so. In particular it always feels like I still have to enforce a lot more validation at the API layer than should be required, without any feeling that I can trust an EmailAddress to instantiate an IEmailAddress interface or that AuthEmailAddress and BillingEmailAddress inherit from the base EmailAddress or that those structures are guaranteed to persist at runtime and that a TotallyUnrelatedThing that just so happens to have a UUID plus a string but isn't strictly instantiating the email class will never accidentally end up populating an email field, which is kind of a concern. (By the way I think the hardcore email address validation really ought to be handled by the upstream provider anyway. I just do some minimal checks on length and presence of dots and at-symbols but don't bother trying to implement a full regex compendium of all email possibilities since these details frankly conflict frequently enough at the edges that I would rather let my IdP and email providers decide for themselves if they truly have an acceptable email input, and handle the failure loudly and up front, rather than try to do all the gatekeeping myself.)

ChatGPT is completely unplayable at chess on its own. It's unable to keep track of the state of the chess position and therefore will make an illegal move within about 10-12 moves. I would put GPT-5.5's rating at 400, since it can't even make legal moves reliably.

I've tried to pay chess with GPT-5.5, even played it again tonight, allowing it to use `python-chess` to keep track of the state of the position and to get a list of legal moves at each turn, so that it was fair. I also gave it blindfold odds, again to make it a fair fight, but it was not even close. GPT still isn't better than maybe 1000 Elo, maybe 1200 tops. Even with what amounts to being able to see the position and also being unable to make an illegal move, GPT-5.5 hangs material left and right, doesn't make a plan, and got smoked even when I gave it blindfold odds, to the point it's boring for me to play even under those conditions. I'm not sure it's better than whatever the GPT model was that was out about 8 months ago. I also thought it might be somewhat better than a beginner due to reading chess books, but no, it's complete garbage at playing chess, not even average-level skill.