04-10 00:00 · AI开发工具,后端即服务,应用自动化,技术竞争,生态整合
Instant 1.0, a backend for AI-coded apps
Instant turns your favorite coding agent into a full-stack app builder. And we’re fully open source. [1]
Our claim is that Instant is the best backend you could use for AI-coded apps.
In this post we’ll do two things. First we’ll show you a series of demos, so you can judge for yourself. Second, we’ll cover the architecture.
The constraints behind a real-time, relational, and multi-tenant backend pushed us towards some interesting design choices. We built a multi-tenant database on top of Postgres, and a sync engine in Clojure. We’ll cover how all this works and what we’ve learned so far.
Let’s get into it.
Demos
When you choose Instant you get three benefits:
You can make unlimited apps and they’re never frozen.
You get a sync engine, so your apps work offline, are real-time, and feel fast.
And when you need more features you have built-in services: auth, file storage, presence, and streams.
To get a sense of what we mean, I’ll dive into each point and show you how they look.
Unlimited Apps
Traditionally, when you want to host apps online you either pay for VMs, or you’re limited. Many services cap how many free apps you can make, and freeze them when they’re idle. Unfreezing can often take more than 30 seconds and sometimes a few whole minutes.
We thought this sucked. So with Instant, you can spin up as many projects as you like and we’ll never freeze them.
We can do this because Instant is designed to be multi-tenant. When you create a new project, we don’t spin up a VM. We just insert a few database rows in a multi-tenant instance.
If your app is inactive, there are no compute or memory costs at all. And when it is active, it’s only a few kilobytes of extra RAM in overhead — as opposed to the many hundreds of megabytes required for VMs.
This means you can truly create unlimited apps. In fact, the process is so efficient that we can create an app for you right inside this essay. No sign up required.
If you click the button, you’ll get an isolated backend:
And with that we have our backend. Including the round-trip to your computer, the whole process takes a few hundred milliseconds. Actual time:
You get a public App ID to identify your backend, and a private Admin Token that lets you make privileged changes. This gives you a relational database, sync engine, and the additional services we mentioned, like auth and storage.
Combine limitless apps with agents, and you’ll start building differently. Today you can already use agents to make lots of apps. With Instant you’ll never be blocked from pushing them to production.
Sync Engine
But once you create an app, how do you make it good?
It’s easy to build a traditional CRUD app. Just get an agent to wire up some database migrations, backend endpoints, and client-side stores. But it’s hard to make these apps delightful.
Compare a traditional CRUD app to modern apps like Linear, Notion, and Figma. Modern apps are multiplayer, they work offline, and they feel fast. If you change a todo in Linear, it changes everywhere. If you go offline in Notion, you can still mark up your docs. When you color a shape in Figma, it doesn’t wait for a server, you just see it.
These kinds of apps need custom infrastructure. For real-time you add stateful websocket servers. For offline mode you store caches in IndexedDB. And for optimistic updates, you figure out how to apply and undo mutations in the client.
Linear, Notion, and Figma all built custom infra to handle this. As an industry we’ve called their infra sync engines [2]. Developers write UIs and query their data as though it was locally available. The sync engine handles all the data management under the hood.
If modern apps need sync engines, then you shouldn’t have to build them from scratch each time.
So we built a generalized sync engine in Instant. Every app comes with multiplayer, offline mode, and optimistic updates by default.
You can try it yourself. Since we’ve created our isolated backend, let’s go ahead and use it:
Spin up a backend to try the live demo.
What you’re seeing are two iframes that render a todo app. They’re powered by the backend you just created (we passed the iframes your App ID).
Now if you add a todo in one iframe, it will show up in the other. If you go offline, you can make changes and they will sync together. You can try degrading your network, and changes will still feel fast.
And here’s what the todo app’s backend code is like:
App.tsx
import{ init, id }from'@instantdb/react';const db =init({ appId:'YOUR_APP_ID'});functionApp(){const{ data }= db.useQuery({ todos:{}});constaddTodo=(text)=> db.transact( db.tx.todos[id()].update({ text, done:false}),);consttoggleTodo=(todo)=> db.transact( db.tx.todos[todo.id].update({ done:!todo.done}),);return(<TodoUItodos={data?.todos ??[]}onAdd={addTodo}onToggle={toggleTodo}/>);}
That’s about 25 lines. This is even more concise than if you had built a traditional CRUD app. You would have needed to write backend endpoints and frontend stores. Instead you ju
▸ 展开全文
04-09 08:08 · AI代理,流程自动化,开源技术,开发者社区,工具发布
Process Manager for Autonomous AI Agents
Manage persistent AI bots with a terminal dashboard, web UI, and declarative configuration.
BOT.md
and the next run picks up changes. No restarts, no deploys, no downtime.Download the latest binary with checksum verification. Supports macOS, Linux, and Windows on AMD64 and ARM64.
Interactive creation via Claude. Generates a BOT.md config file with your bot's name, schedule, and system prompt.
Open the TUI dashboard to monitor and control all your bots. Or use the web UI for browser-based access.
Start, stop, message, and resume bots from the CLI or either dashboard. Bots run as background processes.
▸ 展开全文
04-09 00:00 · 技术选代,开发效率,前端工程,开源,性能优化
We moved Railway's frontend off Next.js. Builds went from 10+ mins to under 2
Railway's entire production frontend no longer runs on Next.js. The dashboard, the canvas, railway.com, all of it now runs on Vite + TanStack Router, and we shipped the migration in two PRs with zero downtime.
Next.js got railway.com from zero to a production app serving millions of users monthly. It's an excellent framework, but it stopped being the right one for our product.
Frontend builds had crept past 10 minutes. Six of those minutes were Next.js alone, half of it stuck on "finalizing page optimization." For a team that ships multiple times a day, that kind of build time isn't a minor annoyance. It's like a very expensive tax on every single iteration.
Railway’s app is overwhelmingly client-side. The dashboard is a rich, stateful interface. The canvas is real-time. Websockets are everywhere. The server-first primitives in Next.js weren't something we used, and we'd ended up building our own abstractions on top of the Pages Router just to support layouts and routing concerns that the framework didn't handle the way we needed.
We were still on the Pages Router, which made shared layouts hacky. Every layout pattern was a bolted-on workaround rather than a first-class framework primitive. The App Router would have solved some of these problems, but it leans heavily into server-first patterns, and our product is intentionally client-driven. Adopting it would have meant rebuilding around a paradigm we don't need.
We wanted a stack that matches how we actually build: explicit, client-first, and fast to iterate on. It also helps that we genuinely enjoy working with it.
For the Product team, we wanted a few niceties that help us avoid thinking about how we needed to implement our front-end and found the following to really convince us.
- Type-safe routing out of the box. Route params and search params are inferred, autocomplete works across the entire route tree, and the routes themselves are generated from the file system.
- First-class layouts. Pathless layout routes replaced all of our previous hacks with something composable and predictable.
- A dev loop fast enough that you stop thinking about it. Instant HMR, near-zero startup time. The feedback cycle between changing code and seeing the result effectively disappears.
- SSR where it actually matters. Marketing pages, the changelog, careers. Pure client-side everywhere else, because we're not going to force server rendering on screens that don't benefit from it. (Ed: This Blog, ironically isn’t on Tanstack yet.)
- An explicit model. Meaning, we found TanStack to lean less on framework magic, more control over how things actually work under the hood.
Several of us tried TanStack Start over the holidays and the reaction was unanimous. We like building with it, and for a product like Railway's dashboard, that matters as much as any benchmark.
Once we made the choice, I got to work. Pre-squash before merge, I must have made 100s of commits.
Migrating a production frontend that serves millions of users across 200+ routes is the kind of thing that usually takes months of parallel running and incremental cutover. We were on a deadline, so I did it in two pull requests.
PR 1 replaced everything Next.js-specific: next/image
, next/head
, next/router
. Each was swapped for either a native browser API or a framework-agnostic alternative. This PR changed nothing about the framework itself. It just removed every dependency on it, so that PR 2 could be a clean swap.
PR 2 swapped the framework. 200+ routes migrated. We systematically extracted everything non-routing-related from page files into individual React components first, then generated all routes from the original page tree.
We then added Nitro as the server layer and replaced next.config.js
with Nitro config, consolidating redirects (500+), security headers, and caching rules into one place. We also replaced Node.js APIs that Next.js had provided polyfills for (Buffer, url.parse
, and others) with browser-native alternatives, which left us with cleaner code as a side effect.
Merged on an early Sunday morning. The team dogfooded immediately with a live war room in Discord, and a stream of fixes landed same day. No downtime.
Sure we gained a faster, more explicit stack, but not without trade-offs.
- Built-in image optimization. We replaced
next/image
with<img>
tags and Fastly image optimization at the edge. - Parts of the ecosystem. We replaced tools like
next-seo
andnext-sitemap
with small in-house equivalents. Straightforward to build, no extra dependencies. - Maturity. TanStack Start is new, and rougher edges can be expected. We're comfortable with that because the direction is right, the maintainers are responsive, and we sponsor both Vite and TanStack because we believe in where they're going.
We run our production frontend the same way our users run theirs: preview deploys per PR, health checks, zero-downtime rollouts. When we swapped the entire build system and framework, we didn't touch infrastructure. We
▸ 展开全文
04-09 00:00 · AI服务风险,客户支持,供应链依赖,企业运维,API生态
I've been waiting over a month for Anthropic to respond to my billing issue
In early March, I noticed approximately $180 in unexpected charges to my Anthropic account. I’m a Claude Max subscriber, and between March 3-5, I received 16 separate “Extra Usage” invoices ranging from $10-$13 each, all in quick succession of one another. However, I wasn’t using Claude. I was away from my laptop entirely and was out sailing with my parents back home in San Diego.
When I checked my usage dashboard, it showed my session at 100% despite no activity. My Claude Code session history showed two tiny sessions from March 5 totaling under 7KB (no sessions on March 3 or March 4.) Nothing that would explain $180 in Extra Usage charges.
This isn’t just me. Other Max plan users have reported the same issue. There are numerous GitHub issues about it (e.g. claude-code#29289 and claude-code#24727), and posts on r/ClaudeCode describing the exact same behavior: usage meters showing incorrect values and Extra Usage charges piling up erroneously.
The support experience
On March 7, I sent a detailed email to Anthropic support laying out the situation with all the evidence above. Within two minutes, I received a response… from “Fin AI Agent, Anthropic’s AI Agent.” The AI agent told me to go through an in-app refund request flow. Sadly, this refund pipeline is only applicable for subscriptions, and not for Extra Usage charges. I also wanted to confirm with a human on exactly what went wrong rather than just getting a refund and calling it a day.
So, naturally, I replied asking to speak to a human. The response:
Thank you for reaching out to Anthropic Support. We’ve received your request for assistance.
While we review your request, you can visit our Help Center and API documentation for self-service troubleshooting. A member of our team will be with you as soon as we can.
That was March 7. I followed up on March 17. No response. I followed up again on March 25. No response. I followed up again today, April 8, over a month later. Still nothing.
The irony
Anthropic is an AI company that builds one of the most capable AI assistants in the world. Their support system is a Fin AI chatbot that can’t actually help you, and there is seemingly no human behind it. I don’t have a problem with AI-assisted support, though I do have a problem with AI-only support that serves as a wall between customers and anyone who can actually resolve their issue.
▸ 展开全文
04-09 00:00 · 硬件监管,嵌入式系统,供应链开放,法律合规,产业政策
John Deere to pay $99M in right-to-repair settlement
Farmers have been fighting John Deere for years over the right to repair their equipment, and this week, they finally reached a landmark settlement.
While the agricultural manufacturing giant pointed out in a statement that this is no admission of wrongdoing, it agreed to pay $99 million into a fund for farms and individuals who participated in a class action lawsuit. Specifically, that money is available to those involved who paid John Deere’s authorized dealers for large equipment repairs from January 2018. This means that plaintiffs will recover somewhere between 26% and 53% of overcharge damages, according to one of the court documents—far beyond the typical amount, which lands between 5% and 15%.
The settlement also includes an agreement by Deere to provide “the digital tools required for the maintenance, diagnosis, and repair” of tractors, combines, and other machinery for 10 years. That part is crucial, as farmers previously resorted to hacking their own equipment’s software just to get it up and running again. John Deere signed a memorandum of understanding in 2023 that partially addressed those concerns, providing third parties with the technology to diagnose and repair, as long as its intellectual property was safeguarded. Monday’s settlement seems to represent a much stronger (and legally binding) step forward.
Ripple effects of this battle have been felt far beyond the sales floors at John Deere dealers, as the price of used equipment skyrocketed in response to the infamous service difficulties. Even when the cost of older tractors doubled, farmers reasoned that they were still worth it because repairs were simpler and downtime was minimized. $60,000 for a 40-year-old machine became the norm.
A judge’s approval of the settlement is still required, though it seems likely. Still, John Deere isn’t out of the woods yet. It still faces another lawsuit from the United States Federal Trade Commission, in which the government organization accuses Deere of harmfully locking down the repair process.
It’s difficult to overstate the significance of this right-to-repair fight. While it has obvious implications for the ag industry, others like the automotive and even home appliance sectors are looking on. Any court ruling that might formally condemn John Deere of wrongdoing may set a precedent for others to follow. At a time when manufacturers want more and more control of their products after the point of sale, every little update feels incredibly high-stakes.
Got a tip or question for the author? Contact them directly: caleb@thedrive.com
▸ 展开全文
04-09 00:00 · 大模型训练,硬件效率,技术突破,成本降低,开源生态
MegaTrain: Full Precision Training of 100B+ Parameter LLMs on a Single GPU
Computer Science > Computation and Language
Title:MegaTrain: Full Precision Training of 100B+ Parameter Large Language Models on a Single GPU
View PDF HTML (experimental)Abstract:We present MegaTrain, a memory-centric system that efficiently trains 100B+ parameter large language models at full precision on a single GPU. Unlike traditional GPU-centric systems, MegaTrain stores parameters and optimizer states in host memory (CPU memory) and treats GPUs as transient compute engines. For each layer, we stream parameters in and compute gradients out, minimizing persistent device state. To battle the CPU-GPU bandwidth bottleneck, we adopt two key optimizations. 1) We introduce a pipelined double-buffered execution engine that overlaps parameter prefetching, computation, and gradient offloading across multiple CUDA streams, enabling continuous GPU execution. 2) We replace persistent autograd graphs with stateless layer templates, binding weights dynamically as they stream in, eliminating persistent graph metadata while providing flexibility in scheduling. On a single H200 GPU with 1.5TB host memory, MegaTrain reliably trains models up to 120B parameters. It also achieves 1.84$\times$ the training throughput of DeepSpeed ZeRO-3 with CPU offloading when training 14B models. MegaTrain also enables 7B model training with 512k token context on a single GH200.
Bibliographic and Citation Tools
Code, Data and Media Associated with this Article
Demos
Recommenders and Search Tools
arXivLabs: experimental projects with community collaborators
arXivLabs is a framework that allows collaborators to develop and share new arXiv features directly on our website.
Both individuals and organizations that work with arXivLabs have embraced and accepted our values of openness, community, excellence, and user data privacy. arXiv is committed to these values and only works with partners that adhere to them.
Have an idea for a project that will add value for arXiv's community? Learn more about arXivLabs.
▸ 展开全文
04-08 00:00 · AI应用案例,文化遗产数字化,技术社区,轻量自动化,数据增强
AI helps add 10k more photos to OldNYC
Over the past two years I’ve quietly rebuilt major parts of the OldNYC photo viewer. The result: 10,000 additional historic photos on the map, more accurate locations, and a site that’s cheaper and easier to run—thanks to modern AI tools and the OpenStreetMap ecosystem.
OldNYC had about 39,000 photos in 2016. Today it has 49,000.
Most of these changes happened in 2024, but I’m only writing about them now in 2026. (I got distracted by an unrelated project.) If you haven’t visited OldNYC in a while, take a look—you might find some photos you missed.
Here are the three biggest improvements: better geolocation, dramatically improved OCR, and a switch to an open mapping stack.
OldNYC works by geocoding historical descriptions—turning text like “Broad Street, south from Wall Street” into a latitude and longitude.
Originally this mostly meant extracting cross streets from titles and sending them to the Google Maps Geocoding API. That worked well when the streets still existed—but many historical intersections don’t.
Two changes in 2024 improved this dramatically.
Some images include useful location details only in the description. I now use the OpenAI API (gpt-4o
) to extract locations from that text.
Public Schools - Brooklyn - P.S. 143. 1930
Havemeyer Street, west side, from North 6th to North 7th Streets, showing Public School No. 143. The view is north from North 6th Street.
The school no longer exists, so the title alone can’t be geocoded. From the description, GPT extracted:
Both intersections exist in OpenStreetMap, so OldNYC places the image at the first one.
Tasks like this require a surprising amount of interpretation: GPT understands that “North 6th” means “North 6th Street” and extracts the relevant intersections while ignoring irrelevant phrases like “west side”. Computers have historically had trouble with this type of task, but the newer AI models nail it.
Using GPT located about 6,000 additional photos. Today OldNYC can locate roughly 87% of photos with usable location data, and about 96% of mapped images appear in the correct location.
I also replaced the Google Maps geocoder with OpenStreetMap and historical street datasets.
Brooklyn: Fulton Street – Nassau Street
These streets intersected in Brooklyn in the 1930s but no longer do today. Google geocodes this to Manhattan, where streets with those names still intersect.
OldNYC now incorporates data from the NYPL’s [historical streets project], which includes the original Brooklyn intersection. The photo now appears in the correct location.
Most OldNYC photos include descriptions from the NYPL catalog—but on the NYPL site these are scanned typewriter images, not text.
When I launched OldNYC in 2015, converting these images to text (OCR) was the hardest technical problem. I built a custom pipeline using Ocropus that achieved over 99% character accuracy. Even so, the errors were noticeable when reading.
To fix mistakes I added a “Fix Typos” feature that let users correct transcriptions. This triggered New Yorkers’ collective OCD and users submitted thousands of edits.
In 2024 I rebuilt the OCR system using gpt-4o-mini
.
The results were much better:
Here’s a dramatic example where the old OCR produced complete gibberish due to an unusual font:
GPT transcribes it perfectly.
A few lessons from rebuilding the pipeline:
Overall, tools like OpenAI mean that OCR is a much easier problem in 2024 than it was in 2015.
When OldNYC launched, Google Maps was the default choice for web mapping, and it was free to use. But over time, Google’s pricing model changed. In late 2024 they replaced their $200/month free credit with separate quotas for individual APIs. Under the new system, rather than being free, OldNYC would have cost about $35/month.
Instead of paying Google indefinitely for a hobby project, I migrated the site to OpenStreetMap vector tiles and MapLibre.
The new stack has some nice benefits:
For example, I can remove anachronisms like highways and tunnels that didn’t exist in the 1930s.
Look, no Brooklyn-Battery Tunnel!
There’s still plenty to improve.
AI could extract additional information from images—identifying people, buildings, or indoor/outdoor scenes. I’d also like to incorporate photographs from other collections.
I’ve also started contributing to OpenHistoricalMap, the history-focused cousin of OpenStreetMap. If it eventually includes full historical street grids for NYC, locating photos could become dramatically easier.
Finally, I’d love to make it easier for developers to build OldNYC-style sites for other cities. If you’re interested, please reach out.
📪 If you’d like to be informed of OldNYC updates, please subscribe to the new mailing list! If you subscribed before 2026, you’ll need to subscribe again. Sorry, MailChimp deleted the old list. 😡
Please reach out if you have any feedback.
▸ 展开全文
04-08 00:00 · AI安全,技术标准,软件供应链,合规风险,开发者生态
Project Glasswing: Securing critical software for the AI era
Project Glasswing
Securing critical software for the AI era
Introduction
Today we’re announcing Project Glasswing1, a new initiative that brings together Amazon Web Services, Anthropic, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, the Linux Foundation, Microsoft, NVIDIA, and Palo Alto Networks in an effort to secure the world’s most critical software.
We formed Project Glasswing because of capabilities we’ve observed in a new frontier model trained by Anthropic that we believe could reshape cybersecurity. Claude Mythos2 Preview is a general-purpose, unreleased frontier model that reveals a stark fact: AI models have reached a level of coding capability where they can surpass all but the most skilled humans at finding and exploiting software vulnerabilities.
Mythos Preview has already found thousands of high-severity vulnerabilities, including some in every major operating system and web browser. Given the rate of AI progress, it will not be long before such capabilities proliferate, potentially beyond actors who are committed to deploying them safely. The fallout—for economies, public safety, and national security—could be severe. Project Glasswing is an urgent attempt to put these capabilities to work for defensive purposes.
As part of Project Glasswing, the launch partners listed above will use Mythos Preview as part of their defensive security work; Anthropic will share what we learn so the whole industry can benefit. We have also extended access to a group of over 40 additional organizations that build or maintain critical software infrastructure so they can use the model to scan and secure both first-party and open-source systems. Anthropic is committing up to $100M in usage credits for Mythos Preview across these efforts, as well as $4M in direct donations to open-source security organizations.
Project Glasswing is a starting point. No one organization can solve these cybersecurity problems alone: frontier AI developers, other software companies, security researchers, open-source maintainers, and governments across the world all have essential roles to play. The work of defending the world’s cyber infrastructure might take years; frontier AI capabilities are likely to advance substantially over just the next few months. For cyber defenders to come out ahead, we need to act now.
Cybersecurity in the age of AI
The software that all of us rely on every day—responsible for running banking systems, storing medical records, linking up logistics networks, keeping power grids functioning, and much more—has always contained bugs. Many are minor, but some are serious security flaws that, if discovered, could allow cyberattackers to hijack systems, disrupt operations, or steal data.
We have already seen the serious consequences of cyberattacks for important corporate networks, healthcare systems, energy infrastructure, transport hubs, and the information security of government agencies across the world. On the global stage, state-sponsored attacks from actors like China, Iran, North Korea, and Russia have threatened to compromise the infrastructure that underpins both civilian life and military readiness. Even smaller-scale attacks, such as those where individual hospitals or schools are targeted, can still inflict substantial economic damage, expose sensitive data, and even put lives at risk. The current global financial costs of cybercrime are challenging to estimate, but might be around $500B every year.
Many flaws in software go unnoticed for years because finding and exploiting them has required expertise held by only a few skilled security experts. With the latest frontier AI models, the cost, effort, and level of expertise required to find and exploit software vulnerabilities have all dropped dramatically. Over the past year, AI models have become increasingly effective at reading and reasoning about code—in particular, they show a striking ability to spot vulnerabilities and work out ways to exploit them. Claude Mythos Preview demonstrates a leap in these cyber skills—the vulnerabilities it has spotted have in some cases survived decades of human review and millions of automated security tests, and the exploits it develops are increasingly sophisticated.
Ten years after the first DARPA Cyber Grand Challenge, frontier AI models are now becoming competitive with the best humans at finding and exploiting vulnerabilities. Without the necessary safeguards, these powerful cyber capabilities could be used to exploit the many existing flaws in the world’s most important software. This could make cyberattacks of all kinds much more frequent and destructive, and empower adversaries of the United States and its allies. Addressing these issues is therefore an important security priority for democratic states.
Although the risks from AI-augmented cyberattacks are serious, there is reason for optimism: the same capabilities that make AI models dangerous in the wrong hands make them invaluable for findin
▸ 展开全文
04-08 00:00 · AI内容质量,大模型应用,技术趋势,市场认知,用户体验
Taste in the age of AI and LLMs
Good Taste the Only Real Moat Left
AI and LLMs have changed one thing very quickly: competent output is now cheap.
A landing page can be generated in minutes. A product memo can appear in a single prompt. A pitch deck can look polished before anyone has done the hard work of deciding what the company actually believes.
That is why taste has become a serious topic in tech. When everyone can produce something that looks decent, the advantage shifts to judgment. The people who stand out are no longer just the ones who can produce. They are the ones who can tell what is generic, what is true, and what is worth pushing further.
But there is a second point that matters just as much: taste is not the final answer. If humans reduce themselves to selecting from AI outputs, they risk becoming reviewers of a machine-led process instead of builders with real stakes in the outcome.
The real opportunity in the age of AI and LLMs is not to become a better selector. It is to combine taste with context, constraints, and the willingness to build something that could not have emerged from the average alone.
What taste actually means
In this context, taste is not about luxury, status, or personal aesthetic branding. It is about distinction under uncertainty.
Most meaningful work does not come with perfect data. You do not get a spreadsheet that tells you which sentence will make a customer care, which feature is worth a month of engineering time, or which design crosses the line from polished to forgettable. You still have to decide.
Taste shows up in three places:
- What you notice
- What you reject
- How precisely you can explain what feels wrong
That last part matters more than it first appears. Many people can say, "this feels off." Far fewer can say, "this fails because it sounds like every other SaaS product," or "this explanation collapses a regulatory constraint into marketing language and will confuse the customer."
Taste becomes useful when it moves from vibe to diagnosis.
Why AI and LLMs flatten the middle
LLMs are extraordinary pattern-compression engines. They absorb huge volumes of language, design patterns, and interfaces, then recombine them at speed. That is their strength. It is also their default bias.
By design, these systems are much better at producing statistically plausible output than at originating something deeply specific to your exact context. Left alone, they tend toward the safe center of the distribution.
That is why so much AI-generated work feels familiar:
- Landing pages with different logos but the same structure
- Product copy that could describe almost any app
- Essays with clean headings and little lived judgment
- Visual design that looks modern, but not memorable
This is not a failure in the catastrophic sense. It is a success at average. The problem is that average used to be hard enough that it still created some separation. Now it is abundant.
The result is a crowded 7 out of 10 world. The middle is full.
The new bottleneck is judgment
Before AI, mediocre work often reflected a lack of time, resources, or execution skill. Today mediocre work often means something else: the person stopped at the first acceptable draft.
That is the economic shift AI introduces. It compresses the cost of first drafts, which means the value moves downstream.
The scarce part is now the ability to say:
- This looks fine, but it is too generic
- This sounds impressive, but it hides the real trade-off
- This interface is polished, but it does not fit how the user actually thinks
- This plan is ambitious, but the operating constraints make it unrealistic
In other words, the scarce skill is not generation. It is refusal.
AI as a mirror for your own taste
One of the most useful things about AI is also one of the most humbling: it reveals how clear your own judgment actually is.
Ask an LLM to produce ten versions of a homepage hero, onboarding flow, support email, or product pitch. You will usually see a pattern:
- A few clearly weak versions
- A large cluster of acceptable versions
- One or two that seem closer to what you want
The interesting question is not, "Which one should I pick?" It is, "Why are most of these still wrong?"
Your answer to that question is the quality of your taste.
If your critique stays vague, your taste is still underdeveloped. If your critique becomes precise, your judgment is stronger than the model output. You can then use the model well instead of being led by it.
A practical way to think about it is this:
The system can generate options. It cannot supply ownership.
A practical loop for training taste
Taste improves through repeated exposure, critique, and shipping. AI can accelerate that loop if you use it correctly.
A simple method looks like this:
- Pick one high-leverage artifact from your week. A paragraph, a pricing explanation, a dashboard label, a customer email, or a key slide.
- Generate 10 to 20 versions with an AI model.
- For each version, write one sentence that starts
▸ 展开全文
04-07 01:21 · 融资,AI估值,商业模式,市场竞争,技术叙事
The back story behind the first "$1.8B" dollar "AI Company"
The back story behind the first “$1.8 Billion” dollar “AI Company”
AI isn’t the only thing behind Medvi
On Thursday, The New York Times published a thing
and it went viral, declared as a victory for AI:
But there’s a lot more to be said that was only scarcely touched on in the article.
Like this
And this
And this brutal, compelling dissection on YouTube
which it itself built on and extending an earlier (May 2025) dissection from Futurism that The New York Times should have read and addressed in far more detail:
A friend of mine who has been tracking this for a while had sees Medvi as “a fraud-layer on top of also-scammy-but-possibly-less-illegal platforms”, speculating that “If there is any money there, they will be sued by all their suppliers and vendors, because I’m sure they’re in violation of every agreement in terms of compliance efforts, safe data handling, etc.” (The friend also is doubtful of the revenue reports, asking “why would this be the only thing they’re telling the truth about?”)
All in all, glorifying Medvi was not The New York Times’ finest hour.
And hardly the poster child AI boosters should be hoping for. Instead, as the YouTube video author, Voidzilla, notes, if anything Medvi is a warning sign — for how AI can be abused.
▸ 展开全文