lunarcave

I can't remember where I heard this, but the moment it flipped for me is when someone phrased this as - "be a heat shield".

A heat shield has some leakage of heat that the people inside know that there's heat, but enough cover that the team is shielded somewhat.

From the article:

> The Bay Area continues to lose jobs across high-income sectors (-0.4% YOY), driving modest overall employment declines. These job losses have slowed compared to a year ago but remain negative YOY. Despite generating substantial spending and wealth, the AI-driven tech boom hasn’t added meaningful employment to the region.

Some of his poetry makes sense if you know what his personal life was like: https://en.wikipedia.org/wiki/Pablo_Picasso#Personal_life

In the "choose a default search engine" page, it has a slightly amusing summary for each.

> Google

> Your personal data fuels its monopoly. Market-dominant due to anti-competitive and anti-consumer practices.

> Qwant

> Based in Europe. Uses Bing results. Sends tracking data to Microsoft.

> DuckDuckGo

> Privacy-focused. Relies on Bing results but never tracks or profiles you.

> Ecosia

> May plant trees for clicking ads. Relies on Bing and Google. Sends tracking data to Microsoft and Google.

> Microsoft Bing

> Collects extensive personal data. Privacy controls are buried and limited. Subjectively overwhelming UI.

> Kagi

> Privacy-focused. Customizable results without ads or tracking. Requires a paid account.

> Our role is shifting from writing implementation details to defining and verifying behavior.

I could argue that our main job was always that - defining and verifying behavior. As in, it was a large part of the job. Time spent on writing implementation details have always been on a downward trend via higher level languages, compilers and other abstractions.

It's a nice write up.

> Build it and they will come is a fallacy.

This is true. But is this the alternative?

No trying to minimize the efforts of people who do this as real jobs or influencing - you do you. However, generating fake message screenshot, sending unsolicited messages etc? And the winner is the one who gets the biggest rise from the consumer, authentic or not.

Distribution is hard, I get it. But isn't this the equivalent of everyone just rocking up to the village square in the most outrageous costumes and screaming into the megaphone?

I think this + node:test makes Node.js a pretty compelling sensible default for most things now. Running things with `tsx` was such a QoL improvement when it happened, but it didn't solve everything.

Runtime type assertion at the edges is mostly solved through `zod` and tools like `ts-rest` and `trpc` makes it so much easier to do full-stack Typescript these days.

We're fast approaching the point where vibeX is becoming derogatory.

I've had a notion that LLMs can read Typescript types much better, than JSON schema types.

So, I've been tinkering around with a library that can generate schemas for structured JSON outputs, according to a Typescript-like custom schema definition: https://github.com/nadeesha/structlm

So far, I've been seeing promising results with accuracy on-par or better, but using 20-40% less tokens than JSON schemas.

Zod doesn't give you the ability to serialize or de-serialize schemas, unless you convert to JSON schema, which is verbose. See: https://github.com/colinhacks/zod/discussions/2030

I don't know how I feel about this one, honestly.

> Build a site like a site. Use HTML. Use navigation. Use the platform.

Sure, but what about all the other problems that aren't solved by View Transitions? There's some truth to the fact that frameworks like Next.js has jumped the shark. But they're not solving the problems of _just_ the SPA.

> Despite the large interest in agents that can code alone, right now you can maximize your impact as a software developer by using LLMs in an explicit way, staying in the loop.

I think this is key here. Whoever has the best UX for this (right now, it's Cursor IMO) will get the bulk of the market share. But the switching costs are so low for this set of tooling that we'll see a rapid improvement in the products available, and possibly some new entrants.

> including physical activity, smoking, alcohol, diet, sleep duration, socioeconomic status, and polygenic risk

Wondering how much of this is due to geography and air quality. City centers have relatively bad air quality and a high amount of ambient lighting at night, compared to non urbanized areas.

The cardiovascular effects of poor air quality is arguably well understood.

Strictly speaking about large, complex, sprawling codebases, I don't think you can beat the experience that an IDE + coding agent brings with a terminal-based coding agent.

Auto-regressive nature of these things mean that errors accumulate, and IDEs are well placed to give that observability to the human, than a coding agent. I can course correct more easily in an IDE with clear diffs, coding navigation, than following a terminal timeline.

Agents easily spend >90% of their time waiting for LLMs to reply and optionally executing API calls in other services (HTTP APIs and DBs).

In my experience the performance of the language runtime rarely matters.

If there ever was a language feature that matters for agent performance and scale, it's actually the performance of JSON serialization and deserialization.

Personal opinion.

I swore away from it for 10 years, but came back recently. And I'm pleasantly surprised with the developer experience of MongoDB Atlas (the cloud version).

You just have to keep in mind the common sense best practices about developing with kv stores, and you'll be mostly alright.

ParseLM: https://github.com/parselm/parselm

It's a Typescript library that allows you to wrangle structured outputs from LLMs and pipe them to programmatically useful control flow or structured data.

The things that's most often missed in these discussions that "writing code" is the end artefact. It doesn't take into account the endless tradeoffs made in producing the said artefact - the journey to get there.

Just try implementing a feature with a junior, in a mildly complex codebase and you'd catch all the unconscious tradeoffs that you're making as an experienced developer. AI has some concept of what these tradeoffs are, but that's mostly by observation.

AI _does_ help with writing code. Keyword there being - "help".

But thinking is the human's job. LLMs can't/don't "think". Thinking how to get the AI to produce the output you want is also your job. You'd think less and less if models get better.