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.
570 karma · joined February 26, 2013
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.
> 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.
> 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.
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.
> 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?
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.
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.
> 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.
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.
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.
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.
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.
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.
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.
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.
Really appreciate the first sentence of the article having a pithy summary of what the whole thing is all about.
We use a minimal schema[1] to prompt the LLM under the hood. We were inspired by BAML [2]. Then the output is wrangled with a converter and ajv [3].
[1] https://github.com/inferablehq/l1m/blob/main/api/src/schema....
Or learn about user experience, design, how humans think and how to build good products.
Please don't get discouraged by the hype. The only people saying AI will replace developers are the people who have something to sell. Engineering is more than just writing code. If anything, AI will increase the level of complexity in the software today, so you'd need engineers to tame that increased complexity.
---
This is from a related thread I wrote in Reddit:
There has never been a more exciting time than now to be a software engineer.
In a nutshell: all the parts I enjoy about software engineering remains challenging, unchanged and open areas of research (distributed systems, algorithms etc). All the grunt work that I hated doing (CRUD work, remembering tailwind classes) have gotten automated very well.
I've played around with AI a lot. I mean A LOT. People who don't code fundamentally lack the insight that writing code is not the only thing that a software engineer does. The way software engineers are coding is changing - but it's changing it in a way that make good ones better, not necessarily bad ones any good.
- Stay away from all the newsletters who pump the latest news. There's a ton of them there. They just mostly use AI to summarise the arxiv papers and discord channels.
- Look for blogs from people building in AI, builders who are commenting on AI, but not "selling AI".
- If you need keep up with the latest, subscribe to the blogs / newsletters of the big companies. Not a lot of them there - Anthropic, OpenAI, Deepmind, Groq, Cerebrus etc.
In terms of a budget friendly alternatives, definitely look into fly.io. We have a AWS setup, but run some compute for ephemeral use cases in fly.io.
> Also, if anyone has experience with applying spaced repetition or other memorization techniques to chatbot interfaces and long-form text retention, I'd love to hear your thoughts.
Have some experience with conversational experiences and LLMs. It all depends on what the modality of the interaction is. Is it something that users can have a long chat conversation with? Or is it more like the anki experience where "flashcards" get presented to you?