English is The New No-Code
Brainstorming through the impact of AI Code generation on No-Code tools.
No-code tools have been around since the dawn of computers (Excel is probably the great-grandfather) and have been solving important but difficult problems by creating no-code abstractions for things that “are code.” Given that a one-to-one abstraction is not really possible, these tools have encountered various challenges and use cases where the abstraction no longer works, forcing users to fallback to “code.” In this short blog, I’ll walk through two popular segments of no-code tools and run a thought experiment on how these tools could potentially evolve with the advancement of large language models (LLMs) that are very good at generating code. We are still in the early days, so it’s pretty hard to predict with so many moving pieces, but it’s fun to try!
Integration Platforms
"Integration Platforms" is quite a broad term and can include several types of tools. You can think of automation tools like Zapier, Workato, Torq, and Tines, as well as data tools like Boomi and Fivetran. Both categories share similar technical challenges and business economics.
Challenges
Limited Capabilities of No-Code Abstractions: If a user has a more complex automation requirement, it becomes very hard or expensive to modify it, or the user has to fallback to code (e.g., for loops, complex conditional logic).
10%/90% Rule: 10% of integrations bring in 90% of the revenue, leaving the other 90% of the market underserved because it becomes uneconomical for the vendor to create more integrations.
Website Builders
Website builders like Webflow and Wix represent another interesting no-code category. These tools face similar challenges and drawbacks that resonate with integration platforms and no-code tools.
Challenges
Limited Capabilities of No-Code Abstractions: Once users require more custom features, customization becomes hard and expensive. Eventually, it becomes easier to hire a React/Next.js/JavaScript developer than a Webflow/Wix developer.
10%/90% Rule: Website builders are essentially abstractions of JavaScript and web frameworks. Typically, 10% of the features generate 90% of the revenue and use cases for users who need a no-code website builder. Beyond that, there is a long tail of features that bloat the no-code framework, making it hard to develop and maintain.
What’s Next for No-Code Tools
Looking at the two segments and some of the challenges from both the user and vendor perspectives, I see a number of interesting developments with the advancement of LLMs for code generation:
Integrated AI: Current no-code tools can integrate LLMs into their frameworks to make it easier for users to create new integrations without hiring an expensive engineer who is a pro at the specific no-code product. We have some early signs of this already, such as Zapier AI.
New No-Code Tools with a Code-First Approach: This could be an interesting middle ground and an opportunity for new tools (aka AI Native 😆). Original no-code tools break down when customization or code is required. If tools can be built around code-first frameworks and give users the ability to always modify the underlying code, that could be a sweet middle ground. This is, of course, the holy grail and still poses many questions about feasibility, as some guardrails will need to be in place. The best example I found is the very early version of Vercel’s v0.dev. Vercel is a hosting company and by integrating a code generation LLM into their UI, it allows users to generate websites and deploy them immediately—all without coding.
Direct LLM Usage in Development Environments (GitHub Copilot, Claude.ai): More and more users can now code basic stuff whether it’s a small automation or a small website from scratch. This trend makes coding cheaper and lowers the barrier to entry for simple application development and maintenance , even for end users.
Personally, I'm most excited about options two and three as I think no-code UI abstractions are expensive to maintain and have too many limitations. I'm also a big believer that the “the best component is no component“, so if we can achieve the same business/user goals without having yet another component or abstraction this might be the best way to go.
There are probably more interesting segments with similar challenges and limitations in the current landscape, so it will be fascinating to watch how the use of LLMs in different stacks affects both enterprise and consumer products.