Dev-first software
In the future, applications might assume that their end-users can code. Even if end-users don’t naturally know how to code, I suspect that they will be supported by LLMs that do.
How might this change the software we build? A few speculative predictions that I’ll explore in this post:
Dev tools (specifically, web-based coding environments) will become more accessible to non-engineers.
Apps meant for non-technical users will increasingly adopt developer features and concepts.
Dev-first may become a viable product strategy against incumbents that are slow to adopt the kind of programmability that end-users will eventually demand.
Coding environments will become more accessible to non-devs
If LLMs make it possible for non-technical users to write working code, coding tools will become accessible to a much broader audience.
As an example, Hex’s coding assistant lets users convert natural language instructions into python or SQL for data analysis.
In the past, Hex would have been useful only to users with competence in SQL or Python. But with Hex Magic, that is no longer the case. Hex is now accessible to a meaningfully larger population of users.
We will likely see this play out with other coding environments (e.g. val.town) as they incorporate LLM coding assistance.
Business apps incorporating dev concepts
Apps building developer-first features (APIs, in-app scripting) and incorporating developer concepts (variables, automations) is nothing new.
But as natural language becomes a viable programming interface, I expect this trend to accelerate. A few ideas on how features supportive of LLM-assisted programming might take shape:
Natural language functions and prompts.
I love Notion’s work on column auto-fills. Users define AI-generated fields which apply a prompt over the contents of a record. Or for convenience, users can also choose from suggested prompt-powered fields.
For now, these auto-fills are simple prompts that are fed into an LLM (e.g. “Summarize the meeting notes.”) and generate text-based output.
Soon enough, I expect we will see tools like Notion permitting natural language functions, where an LLM converts text into code, and then the application executes that code (in some sandboxed programming environment).
Prompt templating
Non-devs already use templating syntax for mail merge use cases, like replacing {{ first_name }} with the value of a variable called `first_name`.
With prompts, rendering templates can become much more powerful as we can templatize prompt expressions, not just variables to fill in.
For instance, you could imagine that in a call transcription tool, users could define prompt templates for custom call summaries. So when a call summary is generated, the user can see the information structured and analyzed in a way that best suits their workflow.
You might also use this style of prompt templating in workflow automation contexts like generating AI commentary for every article you add to your reading list.
Extensibility
I wrote earlier this year about platforms embracing extensibility as coding becomes easier.
My sense is that with LLM-assisted coding, end-users will be able to build custom workflows and UI in Salesforce without needing to consult Salesforce Admins or possessing any expertise in Apex code.
I can see this playing out similarly with all sorts of other extensible systems: think browser extensions, plugins for Google Docs or blocks in Notion etc…
I wonder if, as extensibility becomes easier, users reveal a preference for apps that are best suited for it. My sense is that they will and that a long term side effect is that developers treat extensibility as a priority.
Already, we’re seeing products executing on extensibility as a core value proposition. One example I’m excited by: Magik is very cleverly building an assistant for Salesforce administration so that end-users can customize their Salesforce instances without needing expertise in Apex.
While they’re not currently using LLMs in this way, Arc seems poised to incorporate LLM-coding assistance to make it easier for people to create their own browser extensions. I imagine I might be able to define powerful extensions trivially: new variants on stumbleupon like showing similar blog posts on pages that look like blog posts, or a sidebar that utilizes a prompt template to generate useful commentary for any Arxiv paper…
Notebooks
The magic of notebooks is that they combine low cognitive friction (rather than having to write a whole script, you can write a single line of code if you’d like) and fast feedback loops (each cell of code generates immediate feedback which makes it possible to rapidly iterate on your code). Notebooks are the easiest way to experiment with code. And with built-in code assistance or even support for natural language instructions, notebooks should become an even easier medium for working with code.
While notebook applications like Hex or Deepnote are destinations for this kind of analysis, I would bet on notebooks becoming embedded within business applications.
Dev-first counter-positioning
The possibility of end-user programming suggests a potential convergence: on one side, we have dev tools becoming accessible to non-devs; on the other side, we have business applications starting to treat their end-users like developers.
One way of approaching the impending convergence is to outpace incumbents adopting developer-oriented features. In other words, founders might build dev-first versions of existing software categories before incumbents support the kind of customizability that end-users will crave. A brief, non-exhaustive list of potential targets:
Spreadsheets: scripting for columns, formulas, automations, data pipelines, custom interfaces, support for external data sources etc…
CRMs: custom business systems with support for custom schema, workflow, automations, interfaces, and task management. There are also threads to pull here regarding unifying business objects and application data.
Customer Support: embedded internal tooling for in-context actions (rather than sending the CS agent to take actions in a Retool) etc…
EDIT (Nov 26 2023) Design: I wrote about design-to-code automation earlier this year. A dev-first design tool remains highly interesting to me even as Figma takes measures to become more dev-friendly.
The advantage of dev-first is that you can do things that in the short term will seem crazy for the incumbents to embrace (and which architecturally might be painful). The disadvantage is obvious: dev-first will only resonate among devs and therefore be DoA in categories where devs have little influence. The key to a winning dev-first strategy is likely finding a category where you can build up initial traction among a developer audience and then pounce by the time the market matures.
If you’re building dev-first applications, please get in touch with me at peter [at] upfront.com. I’m increasingly bullish on startups of this shape and would love to chat!