Xenoamorphous

I guess I am one of those "architects" that imagines they need an actual date/time storage class instead of some stringly-typed text column that I hope will contain a parsable ISO8601 datetime string when I try to read it back.

To be honest if you're using JSON at any point in your stack you have the same issue.

I’ve literally calluses on my wrists from those edges.

So sad. Jurassic Park had a tremendous impact on me as a dino obsessed teenager ( was 13 when it came out). RIP.

A butterfly flaps its wings in Tokyo and we lose a leap second.

A few years back I got a couple of Adidas running shorts. Instead of the typical drawstring they had some continuous string. To this day I've no idea how it was supposed to be used, I just cut it off and voila, a regular drawstring.

The current government has little chance to get re-elected, and the next one will revert most of these decisions.

To me the build step is a good thing. It's a simple script in npm, and it means I only keep what I need (the JSON Schema, which I don't need at dev time) in runtime and whatever package generates those schemas out of TS types can remain as a dev dependency.

zod can't be a dev only dependency, and you have to deal with breaking changes and maybe switching to a completely different library in a few years (joi, with a syntax very similar to zod's, was very popular a while ago too).

Obviously it's not ideal, but IMO it's the better option. Much better than `z.number().integer().min(0)` or whatever zod equivalent there is and then have to deal with the inferred types which among other things tend to suck for IntelliSense etc. Those annotations map directly to JSON Schema attributes.

I don't like zod. I want to define my types, not write schemas. And I don't like that then I have to use the types derived from those schemas rather than types I've defined myself directly.

So I just define my types and then use typescript-json-schema or similar to build a JSON Schema at build time (i.e. from an npm script) which then I use to validate input using ajv.

The only thing I do on top of that is to use annotations like "@minimum 0" (or, in the email example, "@format email") where the base types are not enough, but those simply go inside comments.

So the compiled package only has ajv as runtime dependency (which you're likely to have anyway, as it's everywhere), you're just defining regular types with some annotations on top and use a dev dependency to build you the JSON Schema. And as popular as zod is, I think JSON Schema is more of a standard and likely to stay with us longer.

I also reference those generated JSON Schemas from my OpenAPI definition, as a bonus.

Another strong possibility is that you might be working on something that’s not very prevanlent in the training set.

Even the choice of programming language matters, e.g. Java or Javascript vs some niche one.

Indeed. Most people have more arms than average, which must be 1.9 something.

It does.

Scientists are actually preoccupied with accomplishment. So they are focused on whether they can do something. They never stop to ask if they should do something.

From Crichton's book Jurassic Park, which like most of his books is about the perils of technological advancements.

They used the quote in the movie, slightly tweaked.

Even if agents failed at that I'd wager that's a very small percentage of software projects anyway.

Yeah, just read the first couple of paragraphs and then stopped because that’s not my experience at all with Claude Opus 4.6 and 4.7.

If you ask it with a prompt that leaves room for criticism it’ll definitely go for it when warranted.

Pelican in a white Testarossa.

If it’s a retry of the same request it should have the same key. If it’s not a retry, a different one. I don’t see the issue.

If the client sends the same key but a different payload that’s a 400 or 409 in my eyes.

Has SQL somehow become less relevant?

Receiving one of those sounds really scary.

Couple of people in my company have vibe coded some chat interface and they’re passing skills and MCPs that give the model access to all our internal data (multiple databases) and tools (Jira, Confluence etc).

I wonder if there’s something off the shelf that does this?

Grok.

I use both and don't feel they're mutually exclusive.

E.g. if I have some ElasticSearch cluster, I use a skill to describe the data, and if I ask the LLM to write code that queries ElasticSearch but to test it first it can use a combination of skill + MCP to actually run a query.

I think this model works nicely.

Scott Alexander are his first and middle names, and Siskind his last name, or that's what I've understood.

Oh, my beloved TNT2 Ultra.

One I’ve noticed is download/upload progress.

I like the approach of running everything locally. I'm strongly of the opinion that the privacy angle for local models is going to keep getting stronger and more relevant.

In HN circles perhaps. Average Joes don’t care.

Just think of 8 and 16 bit video console games. Those cartridges were expensive so just how sure they had to be they were bug free before making millions of them?

NGI - Natural General Ingelligence

Astrophagology?

Maybe look at MPE-DASH?