无代码的终结
The End of No Code

原始链接: https://blog.exe.dev/the-end-of-no-code

近期 Airtable 以 12.8 亿美元被收购,标志着“无代码”(No-Code)时代可能已经走向没落。尽管无代码平台曾弥补了电子表格与定制软件之间的空白,但如今它们却深受平台锁定以及扩展性和灵活性受限等问题的困扰。 大语言模型(LLM)的崛起从根本上改变了软件的构建方式。作者认为,与其依赖僵化且封闭的无代码界面,不如回归“枯燥”但强大的技术:基于 Linux 的技术栈。通过利用编码代理(coding agents)直接在 Linux 上进行开发,用户可以创建定制化且可移植的业务工具,摆脱传统平台的束缚。 作者的平台 **exe.dev** 正是通过提供易于部署的 Linux 虚拟机来推动这一转变,让 LLM 代理充当开发者。用户可以实时迭代应用程序,绕过繁琐的采购流程和无代码工具的局限性。这种方法提供了“低门槛、高上限”的体验,使用户能够构建安全、可扩展且完全自主的基础设施。归根结底,定制化业务软件的未来不在于限制性的低代码孤岛,而在于利用 LLM 发挥开源环境的通用灵活性。

这篇 Hacker News 的讨论探讨了人工智能时代下“无代码”(No Code)工具的格局演变。 评论者认为,依赖可视化、点击式界面的传统无代码平台正逐渐成为低效的瓶颈。一位用户指出,这些系统往往引入了不必要的复杂性和管理难题,最终反而不如传统编程实用。 展望未来,舆论共识指向一种新的范式:智能体 AI 与人工监督之间的平衡。人们预测,开发模式将从纯粹的可视化构建器转向特定领域的文本界面。这些系统经过优化,既能让 AI 智能体高效生成代码,又足够直观以便于人类进行审查和完善,从而避免完全自主智能体常产生的“垃圾代码”。
相关文章

原文

You may have heard the news: Bending Spoons acquired Airtable for $1.28 billion. Rome didn’t fall in a day, but this is as good a point as any to mark the moment No Code platforms jumped the shark. Full disclosure, I worked at Airtable for many years, love the product, and love the people I worked with there even more. It’s the technology, namely the unreasonable effectiveness of LLM loops with tool use, that’s changed.

Software at work is not valuable in and of itself. It’s built to serve some purpose. Mostly it’s used to keep track of something (schedules, parts, orders, people, you name it). Spreadsheets are the universal software here–and I love me a spreadsheet. But spreadsheets have a ceiling when it comes to sharing, programming, permissions, automations, and so on. Once you leave a spreadsheet, you upgrade to a database and some software on top of it: that’s what low or no code platforms like Airtable are. At their best, the person who brings Airtable to their team isn’t bringing Airtable: they’re bringing much-needed organization and process, and Airtable is merely the means.

One of the things that Airtable got right was their experience of creating the tables themselves. You just added a column (like in Excel), and chose a data type (string, number, date, and so on), and, voila, you’ve created a table. I used to joke that Airtable should show up to SIGMOD (the big database conference) and present a paper on the efficacy of not having ALTER TABLE widgets ADD COLUMN (color string) as the way people use your database. Fred Brooks wrote: “Show me your flowcharts and conceal your tables, and I shall continue to be mystified. Show me your tables, and I won’t usually need your flowcharts; they’ll be obvious.” Airtable understood this at its core: if the user can specify the business model, building the automations and features on top of it becomes possible. (This is nothing new! FileMaker launched in 1985; it was my introduction to databases when I helped run a conference for ~1,600 high school students. It turns out that a little bit of extra credit, some freshmen, and 3 AppleTalk-connected computers could handle the mailed-in registration forms!) 

Once upon a time (the 90s!), IT teams at companies existed to build software for said companies. Much software was bespoke. We can use Salesforce’s 2000 “Software is Dead” campaign as the mile marker for when SaaS started taking over. IT departments became all about procurement. And procurement means saying NO. Low code and No Code platforms (and Microsoft SharePoint and Excel and Google Sheets) picked up the slack. When you can’t buy the software, you make do with what you can get access to, and you smuggle in some Airtable, increase revenues/efficiency/trust/whatever, and nobody can get rid of it for bureaucratic reasons because it’s now load-bearing.

AWS launched EC2 in 2006. You could rent a VM. Getting it on the internet (so that you could share a thing with your co-workers) required learning about EC2 VPCs, IAM permissions, EBS, RDS, static IPs, DNS, and a handful of other Three Letter Acronyms (TLAs). Even within software companies, IT gatekept EC2. When I was at Google in 2007, the tool to search the company’s code base ran on a spare desktop under Jeff Dean’s desk. Getting a machine in Google’s datacenter to serve this (to me, critical) piece of infrastructure was too much of a hassle. (There were, at the time, funny “Is it web scale?” videos; e.g., https://www.youtube.com/watch?v=b2F-DItXtZs, amongst others.)

Fast forward to 2026. LLMs are king. The SaaSpocalypse is under way, and happening like bankruptcy–gradually first, then all at once. What is the right way to build and deploy business tools? What is the right platform? Can non-software-engineers be trusted to do it?

The right answer (it’s my turn to be wrong on the internet today, baby) is Linux. Yes, choose boring technology, and just use Linux. You can choose one of many stacks on top of Linux. Honestly, if you chose LAMP (Linux, Apache HTTPd, MySQL, PHP) you would be fine. My current preference is (sqlite, Go, Typescript, maybe Vue). If memory weren’t getting expensive, there’d be nothing wrong with (PostgreSQL, Node, TypeScript) but the memory crunch is real, and the advantages of using a single language for frontend and backend have disappeared since you’re not writing the code anyway.

Yes, that entire stack is Open Source. Yes, if you build on that stack, and you need to migrate to AWS or GCP or Render or Azure or Oracle Cloud Infrastructure or Railway or Hetzner or a miniPC, you will be able to rsync the data and code over, and you’ll be all set. The platform-level lock-in is weak compared to low code platforms. (That said, an agent will port your low code setup to Linux with a few prompts.)

Exe.dev sells this very stack. Your subscription lets you create Linux VMs. They’re on the internet in the way that matters: you can send links to your friends, and the links will work. They are secure by default, and you can make sites public using our auth system or your very own. They’re fast. They’re great for coding agents. The way to build your custom software is to build it right there in prod with the coding agent. Iterate until you get something usable. Iterate some more with feedback from your co-workers. Let your co-workers iterate on it too; let them sand down the edges. If you give the coding agent the data model for your business and the workflows, and a hint about the stack maybe, it will do ok. If your project is in the 1 percent of projects that need to graduate to “Business Critical Very Important Stuff,” sure, start a second VM and a dev environment, or maybe even graduate to the confusing trappings of modern software development (git). An LLM running on a Linux machine is the ultimate in “low floor, high ceiling”: just get started, and you’ll perhaps be able to leave your spreadsheet in the dust.

Moving on to some relevant FAQs.

Is my data secure?

Yes. Our defaults are secure. The mechanics are very similar to a Google Sheet: you can share a VM’s web port with just your team or individual people or the world.

I have a spreadsheet or a low code solution already; how do I port it?

If you’re comfortable doing so, start the VM, visit the agent (ours is called Shelley and it’s pre-installed by default), and give it an API key to your existing solution or upload your spreadsheet. Tell it to port it over into a web application on this machine. It will. Today, use Sol or Opus as the model. Tomorrow, ask us on Discord; the answer changes kinda frequently.

How do I do schedules? Automations?

Linux is a rich platform. You can ask the agent to run something on a timer, and it will. (It will usually choose systemd, but if you have a preference for cron, nudge it in that direction, and if you don’t know what either of those are, that’s ok!)

How do I build agents or bots?

The same way: ask the agent to write an “agentic loop using the exe.dev LLM integration” with tools to do this and that. So, perhaps it reads Slack threads in a certain channel and comments on that. The agent will one-shot it.

One of the best things about the exe.dev platform is our “Integrations” system. Hooking up your bot to Slack has never been easier.

Is Vibe Coding good enough?

In my experience, yes. The usual thing is to measure Risk and Reward. Every spreadsheet formula is fragile and untested and so on; and yet, spreadsheets work! Same applies here.

Shouldn’t I use the Flue agent framework? Or maybe some framework from Langchain? Can I really just yolo it?

Use whatever frameworks you like, but, ultimately, the agents are fine at choosing their own, or just doing it the boring way. There are millions of conflicting best practices the world over, “P & L FINAL FY2025 FINAL VERSION 3” is still the median solution, and you should figure out your workflow needs first. Have the agent set up a cron job to back up the database somewhere, too.

How does your pricing work?

The basic plan for $20/month gives you up to 50 VMs, but they are limited to 2 CPUs and 8GB of RAM. This is enough for quite a few small apps targeted toward your team. If you need more resources, you can upgrade or ask us; we are happy to get you machines as big as you need. Building your app may take more LLM tokens than we provide as part of your subscription. You can hook up a ChatGPT subscription, use other coding agents, or other model providers, or we’re happy to give you the LLM at API token costs through us.

What if the app is slow? How do I test it?

I’ve found that the agents are surprisingly good at both testing their end result and fixing performance issues. They use the same tools I use: profilers and so on. Shelley’s secret weapon is a good browser tool that it’s capable of using, profilers, screenshots, screencasts, and all.

联系我们 contact @ memedata.com