I'm going to take a contrarian view and say it's actually a good UI, but it's all about how you approach it.

I just finished a small project where I used o3-mini and o3-mini-high to generate most of the code. I averaged around 200 lines of code an hour, including the business logic and unit tests. Total was around 2200 lines. So, not a big project, but not a throw away script. The code was perfectly fine for what we needed. This is the third time I've done this, and each time I get faster and better at it.

1. I find a "pair programming" mentality is key. I focus on the high-level code, and let the model focus on the lower level code. I code review all the code, and provide feedback. Blindly accepting the code is a terrible approach.

2. Generating unit tests is critical. After I like the gist of some code, I ask for some smoke tests. Again, peer review the code and adjust as needed.

3. Be liberal with starting a new chat: the models can get easily confused with longer context windows. If you start to see things go sideways, start over.

4. Give it code examples. Don't prompt with English only.

FWIW, o3-mini was the best model I've seen so far; Sonnet 3.5 New is a close second.

I'm growing to the idea that chat is a bad UI pattern, period. It is a great record of correspondence, I think. But it is a terrible UI for doing anything.

In large, I assert this is because the best way to do something is to do that thing. There can be correspondence around the thing, but the artifacts that you are building are separate things.

You could probably take this further and say that narrative is a terrible way to build things. It can be a great way to communicate them, but being a separate entity, it is not necessarily good at making any artifacts.

I'm surprised that the article (and comments) haven't mentioned Cursor.

Agreed that copy pasting context in and out of ChatGPT isn't the fastest workflow. But Cursor has been a major speed up in the way I write code. And it's primarily through a chat interface, but with a few QOL hacks that make it way faster:

1. Output gets applied to your file in a git-diff style. So you can approve/deny changes.

2. It (kinda) has context of your codebase so you don't have to specify as much. Though it works best when you explicitly tag files ("Use the utils from @src/utils/currency.ts")

3. Directly inserting terminal logs or type errors into the chat interface is incredibly convenient. Just hover over the error and click the "add to chat"

Natural language isn’t made to be precise that’s why we use a subset in programming languages.

So you either need lots of extra text to remove the ambiguity of natural language if you use AI or you need a special precise subset to communicate with AI and that’s just programming with extra steps.

Yep. 100% agree. The whole “chat as UX” metaphor is a cul-de-sac that I’m sure we’ll back out of sooner or later.

I think about this like SQL in the late 80s. At the time, SQL was the “next big thing” that was going to mean we didn’t need programmers, and that management could “write code”. It didn’t quite work out that way, of course, as we all know.

I see chat-based interfaces to LLMs going exactly the same way. The LLM will move down the stack (rather than up) and much more appropriate task-based UX/UI will be put on top of the LLM, coordinated thru a UX/UI layer that is much sympathetic to the way users actually want to interact with a machine.

In the same way that no end-users ever touch SQL these days (mostly), we won’t expose the chat-based UX of an LLM to users either.

There will be a place for an ad-hoc natural language interface to a machine, but I suspect it’ll be the exception rather than the rule.

I really don’t think there are too many end users who want to be forced to seduce a mercurial LLM using natural language to do their day-to-day tech tasks.

I don't think Daniel's point is that Chat is generically a clunky UI and therefore Cursor cannot possibly exist. I think he's saying that to fully specify what a given computer program should do, you have to provide all kinds of details, and human language is too compressed and too sloppy to always include those details. For example, you might say "make a logon screen" but there are an infinite number of ways this could be done and until you answer a lot of questions you may not get what you want.

If you asked me two or three years ago I would have strongly agreed with this theory. I used to point out that every line of code was a decision made by a programmer and that programming languages were just better ways to convey all those decisions than human language because they eliminated ambiguity and were much terser.

I changed my mind when I saw how LLMs work. They tend to fill in the ambiguity with good defaults that are somewhere between "how everybody does it" and "how a reasonably bright junior programmer would do it".

So you say "give me a log on screen" and you get something pretty normal with Username and Password and a decent UI and some decent color choices and it works fine.

If you wanted to provide more details, you could tell it to use the background color #f9f9f9, but a part of what surprised my and caused me to change my mind on this matter was that you could also leave that out and you wouldn't get an error; you wouldn't get white text on white background; you would get a decent color that might be #f9f9f9 or might be #a1a1a1 but you saved a lot of time by not thinking about that level of detail and you got a good result.

I agree with the premise but not with the conclusion. When you're building visual things, you communicate visually: rough sketches, whiteboard diagrams, mockups, notes scrawled in the margins.

Something like tldraw's "make real" [1] is a much better bet, imo (not that it's mutually exclusive). Draw a rough mockup of what you want, let AI fill in the details, then draw and write on it to communicate your changes.

We think multi-modally; why should we limit the creative process to just text?

[1] https://tldraw.substack.com/p/make-real-the-story-so-far

This is about relying on requirements type documents to drive AI based software development, I believe this will be ultimately integrated into all the AI-dev tools, if not so already. It is really just additional context.

Here is an example of our approach:

https://blog.codesolvent.com/2024/11/building-youtube-video-...

We are also using the requirements to build a checklist, the AI generates the checklist from the requirements document, which then serves as context that can be used for further instructions.

Here's a demo:

https://youtu.be/NjYbhZjj7o8?si=XPhivIZz3fgKFK8B

I agree with this and disagree at the same time. It depends what the goal is. If the goal is to have AI write the entire codebase for you, yes chat and human language is quite bad. That's part of the reason formal languages exist. But then only experts can use it. Requirement docs are a decent middle ground. However, I'm not sure it's a good goal for AI to generate the code base.

The mode that I've found most fruitful when using Cursor is treating it almost exactly as I would a pair programming partner. When I start on a new piece of functionality I describe the problem and give it what my thoughts are on a potential solution and invite feedback. Sometimes my solution is the best. Sometimes the LLM had a better idea and frequently we take a modified version of what one of us suggested. Just as you would with a human partner. The result of the discussion is better than what either of us would have done on their own.

I also will do classical ping-pong style tdd with it one we agreed on an approach. I'll write a test; llm makes it pass and write the next test which I'll make pass and so on.

As with a real pair, it's important to notice when they are struggling and help them or take over. You can only do this if you stay fully engaged and understand every line. Just like when pairing. I've found llms get frequently in a loop where something doesn't work and they keep applying the same changes they've tried before and it never works. Understand what they are trying to do and help them out. Don't be a shitty pair for your llm!

I can't wait for someone to invent a new language, maybe a subset of English, that is structured enough to half-well describe computer programs. Then train a model with RLHF to generate source code based on prompts in this new language.

It will slowly grow in complexity, strictness, and features, until it becomes a brand-new programming language, just with a language model and a SaaS sitting in the middle of it.

A startup will come and disrupt the whole thing by simply writing code in a regular programming language.

I'd say this criticism is well-addressed in aider. Steering the LLM via code comments is the first UX I've seen that works.

https://aider.chat/docs/usage/watch.html

How jarring it is & how much it takes you out of your own flow state is very much dependent on the model output quality and latency still, but at times it works rather nicely.

Narrative text is a worse UI pattern. It's impractical to read. Also how exactly do you merge narrative changes if you need to write several transformations as updates? Are you expected to update the original text? How does this affect diffs in version control?

I think it's more ideal to have the LLM map text to some declarative pseudocode that's easy to read which is then translated to code.

The example given by Daniel might map to something like this:

  define sign-in-screen:
    panel background "#f9f9f9":
      input email required: true, validate-on-blur: true
      input password required: true
      button "Sign in" gradient: ("#EEE" "#DDD")
      connect-to-database

What makes it bad currently is the slow output.

The example shows "Sign-in screen" with 4 (possibly more) instructions. This could equivalently have been entered one at a time into 'chat'. If the response for each was graphic and instantaneous, chat would be no worse than non-chat.

What makes non-chat better is that the user puts more thought into what they write. I do agree for producing code Claude with up-front instructions beats ChatGPT handily.

If OTOH AI's actually got as good or better than humans, chat would be fine. It would be like a discussion in Slack or PR review comments.

Just two tips/thoughts:

1) The first thing to improve chats as a genre of interface, is that they should all always be a tree/hierarchy (just like Hacker News is), so that you can go back to ANY precise prior point during a discussion/chat and branch off in a different direction, and the only context the AI sees during the conversation is the "Current Node" (your last post), and all "Parent Nodes" going back to the beginning. So that at any time, it's not even aware of all the prior "bad branches" you decided to abandon.

2) My second tip for designs of Coding Agents is do what mine does. I invented a 'block_begin/block_end' syntax which looks like this, and can be in any source file:

// block_begin MyAddNumbers

var = add(a, b)

return a + b

// block_end

With this syntax you can use English language to explain and reason about extremely specific parts of your code with out expecting the LLM to "just understand". You can also direct the LLM to only edit/update specific "Named Blocks", as I call them.

So a trivial example of a prompt expression related to the above might be "Always put number adding stuff in the MyAddNumbers Block".

To explain entire architectural aspects to the LLM, these code block names are extremely useful.

> This is the core problem. You can’t build real software without being precise about what you want.

I've tested a few integrated AI dev tools and it works like a charm. I don't type all my instructions at once. I do it the same way as I do it with code. Iteratively:

1) Create a layout

2) Fill left side

3) Fill right side

4) Connect components

5) Populate with dummy data

> The first company to get this will own the next phase of AI development tools.

There's more than 25 working on this problem and they are already in production and some are really good.

You may have challenges using chat for development (Specifically, I mean text prompting, not necessary using a langchain session with a LLM, although that is my most common mode), but I do not. I have found chat to be, by far, the most productive interface with LLMs for coding.

Everything else, is just putting layers, that are not nearly as capable at an LLM, between me and the raw power of the LLM.

The core realization I made to truly unlock LLM code assistance as a 10x + productivity gain, is that I am not writing code anymore, I am writing requirements. It means being less an engineer, and more a manager, or perhaps an architect. It's not your job to write tax code anymore, it's your job to describe what the tax code needs to accomplish and how it's success can be defined and validated.

Also, it's never even close to true that nobody uses LLMs for production software, here's a write-up by Google talking about using LLMs to drastically accelerate the migration of complex enterprise production systems: https://arxiv.org/pdf/2501.06972

My nuclear fire hot take is that the chat pattern is actively hampering AI tools because we have to square peg -> round hole things either into the chat UI (because that's what people expect), or that as developers you have to square peg -> round hole into the chat API patterns.

Last night I wrote an implementation of an AI paper and it was so much easier to just discard the automatic chat formatting and do it "by hand": https://github.com/Xe/structured-reasoning/blob/main/index.j...

I wonder if foundation models are an untapped goldmine in terms of the things they can do, but we can't surface them to developers because everyone's stuck in the chat pattern.

AI "Agents" that can do tasks outside of the confines of just a chat window are probably the next stage of utility.

The company I work for integrated AI into some of our native content authoring front-end components and people loved it. Our system took a lot of annotating to be able to accurately translate the natural language to the patterns of our system but users so far have found it WAYYY more useful than chat bc it's deeply integrated into the tasks they do anyway.

Figma had a similar success at last year's CONFIG when they revealed AI was renaming default layers names (Layer 1, 2, etc)... something they didn't want to do anyway. I dare say nobody gave a flying f about their "template" AI generation whereas layer renaming got audible cheers. Workflow integration is how you show people AI isn't just replacing their job like some bad sci-fi script.

Workflow integration is going to be big. I think chat will have its place tho; just kind of as an aside in many cases.

I took the position of not liking to much the AI coding early on. This was specially when it was starting. People writing long description to generate an app, I quickly noticed that doesn't work because it's all in the details.

Then having ai generate code for my project didn't feel good either, I didn't really understand what it was doing so I would have to read it to understand, then what is the purpose, I might as well write it.

I then started playing, and out came a new type of programming language called plang (as in pseudo language). It allows you to write the details without all the boiler code.

I'm think I've stumbled on to something, and just starting to get noticed :) https://www.infoworld.com/article/3635189/11-cutting-edge-pr...

A chat room is an activity stream and so is a commit log of a version control system. A lot of the bad UI is waiting a fixed amount of time that had a minimum that was too high, and for some communicating by typing. Many will prefer chatting by voice. When responses are faster it will be easier to hide the history pane and ask if you need to be reminded of anything in the history pane and use the artifact pane. However not all responses from an LLM need be fast, it is a huge advancement that LLMs will think for minutes at a time. I agree about the usefulness of prose as an artifact while coding. Markdown can be edited in IDEs using LLMs and then referenced in prompts.

I'll preface this by saying I also dislike using chat as a pattern for AI tools. However, in theory, the idea has merit. Just as having 100% of the specifications and design guidance for a product is valuable before development, complete requirements would seem ideal. In reality, though, many requirements and specifications are living documents. Should we expect to rebuild the entire application every time a document changes? For example, if I decide to reduce a header's height, there's a significant chance the application could end up looking or feeling entirely different.

In a real-world scenario, we begin with detailed specifications and requirements, develop a product, and then iterate on it. Chat-based interactions might be better suited to this iterative phase. Although I'm not particularly fond of the approach, it does resemble receiving a coworker's feedback, making a small, targeted change, and then getting feedback again.

Even if the system were designed to focus solely on the differences in the requirements—thus making the build process more iterative—we still encounter an issue: it tends to devolve into a chat format. You might have a set of well-crafted requirements, only for the final instruction to be, "The header should be 2px smaller."

Nonetheless, using AI in an iterative process (focusing on requirement diffs, for example) is an intriguing concept that I believe warrants further exploration.

> AI was supposed to change everything. Finally, plain English could be a programming language—one everyone already knows. No syntax. No rules. Just say what you want

That’s the thing about language, you CAN’T program in human language for this exact reason, whereas programming languages are mechanical but precise, human languages flow better but they leave wiggle room. Computers can’t do jack shit with wiggle room, they’re not humans. That’ll always remain, until there’s an AI people like enough to have it’s own flair on things.

I don't want to become a lawyer to talk to my compiler; thank you.

It makes me think of the promises and perils of Jupyter notebooks.

So far as this article is concerned (not the many commenters who are talking past it), "chat" is like interacting with a shell or a REPL. How different is the discussion that Winograd has with SHRDLU

https://en.wikipedia.org/wiki/SHRDLU

with the conversation that you have with a database with the SQL monitor really?

There's a lot to say for trying to turn that kind of conversation into a more durable artifact. I'd argue that writing unit tests in Java I'm doing exploratory work like I'd do in a Python REPL except my results aren't scrolling away but are built into something I can check into version control.

On the other hand, workspace-oriented programming environments are notorious for turning into a sloppy mess, for instance people really can't make up their mind if they want to store the results of their computations (God help you if you have more than one person working on it, never mind if you want to use version control -- yet, isn't that a nice way to publish a data analysis?) or if they want to be a program that multiple people can work, can produce reproducible results, etc.

See also the struggles of "Literate Programming"

Not to say there isn't an answer to all this but boy is it a fraught area.

I'm predicting that Test-Driven Development may be having a comeback

English behaviour descriptions -> generated tests

Use both behaviour descriptions and feedback from test results to iterate on app development

This kind of reminds me of back when the hype cycle was focused on Messenger apps and the idea of most online behavior being replaced with a chatbot. God I hated the smug certainty of (some, definitely not all!) UX designers at the time proclaiming that chat was the ultimate interface.

Absolutely insane that all the doors unlocked by being able to interact with a computer graphically, and yet these people have visions of the future stuck in the 60s.

In cursor I keep a specification document in .cursorrules and I have instructions that cursor should update the document whenever I add new specifications in chat.

Chat is a great UX _around_ development tools. Imagine having a pair programmer and never being allowed to speak to them. You could only communicate by taking over the keyboard and editing the code. You'd never get anything done.

Chat is an awesome powerup for any serious tool you already have, so long as the entity on the other side of the chat has the agency to actually manipulate the tool alongside you as well.

This puts me in mind of something I read years ago and am having trouble finding that basically had the same premise but went about proving it a different way. The idea was that natural language programming is always going to mean dealing with a certain background level of ambiguity, and the article cited contracts and contract law as proof. Basically, a contract is an agreement to define a system with a series of states and a response for each state defined, and the vast and difficult-to-navigate body of contract law is proof that even when purposefully being as unambiguous as possible with two entities that fully grasp the intricacies of the language being used there is so much ambiguity that there has to be an entire separate group of people (the civil court system) whose only job it is to mediate and interpret that ambiguity. You might point to bad-faith actors but a contract where every possible state and the appropriate response are defined without ambiguity would be proof against both misinterpretations and bad faith actors.

I agree, and I think this means there is a lot of space for trying new things. I think cursor was a small glimpse in trying to fix the split between purely GitHub copilot line revision (this interrupts my thoughts too much) and calling in for help via a chat window that you're copying and pasting from.

I think this post shows there could be a couple levels of indirection, some kind of combination of the "overarching design doc" that is injected into every prompt, and a more tactical level syntax/code/process that we have with something like a chat window that is code aware. I've definitely done some crazy stuff by just asking something really stupid like "Is there any way to speed this up?" and Claude giving me some esoteric pandas optimization that gave me a 100x speedup.

I think overall the tools have crazy variance in quality of output, but I think with some "multifacet prompting", ie, code styling, design doc, architect docs, constraints, etc you might end up with something that is much more useful.

Every time there is a chat interface for something I try to use it, then after 1-2 prompts I give up.

So I completely agree with this. Chat is not a good UI

I call it 'structured prompting' [think pseudo-code]. It strikes a nice balance between human-readable logic and structured programming, allowing the LLM to focus on generating accurate code based on clear steps. It’s especially useful when you want to specify the what (the logic) without worrying too much about the how (syntax and language-specific details). If you can create an effective system that supports this kind of input, it would likely be a big step forward in making code generation more intuitive and efficient. Good old UML could also be used.

Example of a Structured Pseudo-Code Prompt:

Let’s say you want to generate code for a function that handles object detection:

'''Function: object_detection Input: image Output: list of detected objects

Steps: 1. Initialize model (load pretrained object detection model)

2. Preprocess the image (resize, normalize, etc.)

3. Run the image through the model

4. Extract bounding boxes and confidence scores from the model's output

5. Return objects with confidence greater than 0.5 as a list of tuples (object_name, bounding_box)

Language: Python'''

I've been experimenting with "paged chats" UX and find myself using it fairly fluidly https://xenodium.com/llm-iterate-and-insert

Been experimenting with the same approach but for "paged shells" (sorry for the term override) and this seems to be a best of both worlds kinda thing for shells. https://xenodium.com/an-experimental-e-shell-pager That is, the shell is editable when you need it to be (during submission), and automatically read-only after submission. This has the benefit of providing single-character shortcuts to navigate content. n/p (next/previous) or tab/backtab.

The navigation is particularly handy in LLM chats, so you can quickly jump to code snippets and either copy or direct output elsewhere.

The first wave was not chat, it was completion. Instead of saying "suggest some names for an ice cream shop", the first wave was "Here are some great names for ice cream shops: 1. Nice Cream 2." Chat was a lot more intuitive and low effort than this.

Chat is also iterative. You can go back there and fix things that were misinterpreted. If the misinterpretation happens often, you can add on another instruction on top of that. I strongly disagree that they'd be fixed documents. Documents are a way to talk to yourself and get your rules right before you commit to them. But it costs almost nothing to do this with AI vs setting up brainstorming sessions with another human.

However, the rational models (o1, r1 and such) are good at iterating with themselves, and work better when you give them documents and have them figure out the best way to implement something.

Reminds of Karpathy's pinned tweet since a long time: "The hottest new programming language is English." https://x.com/karpathy/status/1617979122625712128

I've mainly used gptel in Emacs (primarily with Claude), and I kind of already use the chat buffer like a document. You can freely edit the history, and I make very generous use of that, to steer where the model is going.

It has features to add context from your current project pretty easily, but personally I prefer to constantly edit the chat buffer to put in just the relevant stuff. If I add too much, Claude seems to get confused and chases down irrelevant stuff.

Fully controlling the context like that seems pretty powerful compared to other approaches I've tried. I also fully control what goes into the project - for the most part I don't copy paste anything, but rather type a version of the suggestion out quickly.

If you're fast at typing and use an editor with powerful text wrangling capabilities, this is feasible. And to me, it seems relatively optimal.

This is exactly why we're developing our AI developer workflow product "Brilliant" to steer users away from conversations altogether.

Many developers don't realize this but as you go back and forth with models, you are actively polluting their context with junk and irrelevant old data that distracts and confuses it from what you're actually trying to do right now. When using sleeker products like Cursor, it's easy to forget just how much junk context the model is constantly getting fed (from implicit RAG/context gathering and hidden intermediate steps). In my experience LLM performance falls off a cliff somewhere around 4 decent-sized messages, even without including superfluous context.

We're further separating the concept of "workflow" from "conversation" and prompts, basically actively and aggressively pruning context and conversation history as our agents do their thing (and only including context that is defined explicitly and transparently), and it's allowing us to tackle much more complex tasks than most other AI developer tools. And we are a lot happier working with models - when things don't work we're not forced to grovel for a followup fix, we simply launch a new action to make the targeted change we want with a couple clicks.

It is in a weird way kind of degrading to have to politely ask a model to change a color after it messed up, and it's also just not an efficient way to work with LLMs - people just default to that style because it's how you'd interact with a human you are delegating tasks to. Developers still need to truly internalize the facts that LLMs are purely completion machines, that your conversation history lives entirely client side outside of active inference, and that you can literally set your conversation input to be whatever you want (even if the model never said that) - after that realizing you're on the path towards using LLMs like "what words do I need to put it in to get it to do what I want" rather than working "with" them.

I agree with what is discussed in this post a lot. Chat is indeed a lossy and at best q/a style system. Yes, of course it can be tweaked and hacked but it's ultimately the wrong UI if you want to leverage the most of AI for code.

However, even with a "docs as spec" pattern, how can you control the actual quality of the code written? How maintainable will it be? If the spec changes (read: it _will_ change constantly), is it easy enough to refactor? What about tests? I also shrink in fear at the complexity of docs that could be _exactly_ captured as code... "well we almost always do it this way, but this one time we do it this way..."

Has anyone invited an LLM inside their lisp process that can be accessed from the repl? Being able to empower an LLM to be able to affect the running lisp image (compile functions etc), and having changes reflected back to the source on disk would be interesting.

Seems like this is a common complaint from folks trying to write code purely with ChatGPT / Deepseek by communicating in complete sentences. You can only get so far using these tools before you need a proper understanding of whats happening with the code.

I find web chat interfaces very useful for programming, but it also feels like early days. Speedups will smooth out a lot of pain points. But other UI changes, some even quite small, could enhance use a lot. A few of various size top of mind with regard to Claude web chat UI specifically:

- intellisense in the inputbox based on words in this or all previous chats and a user customizable word list

- user customizable buttons and keyboard shortcuts for common quick replies, like "explain more".

- when claude replies with a numbered list of alternatives let me ctrl+click a number to fork the chat with continued focus on that alternative in a new tab.

- a custom right click menu with action for selection (or if no selection claude can guess the context e.g. the clicked paragraph) such as "new chat with selection", "explain" and some user customizable quick replies

- make the default download filenames follow a predicable pattern, claude currently varies it too much e.g. "cloud-script.py" jumps to "cloud-script-errorcheck.py". I've tried prompting a format but claude seems to forget that.

- the stop button should always instantly stop claude in its tracks. Currently it sometimes takes time to get claude to stop thinking.

- when a claude reply first generates code in the right sidebar followed by detailed explanation text in the chat, let some keyboard shortcut instantly stop the explanation in its tracks. Let the same shortcut preempt that explanation while the sidebar code is still generating.

- chat history search is very basic. Add andvanced search features, like filter by date first/last message and OR search operator

- batch jobs and tagging for chat history. E.g. batch apply a prompt to generate a summary in each selected chat and then add the tag "summary" to them. Let us then browse by tag(s).

- tools to delete parts of a chat history thread, that in hindsight were detours

- more generally, maybe a "chat history chat" to have Claude apply changes to the chat histories

See my article from January 2023, "Natural language is the lazy user interface".

https://austinhenley.com/blog/naturallanguageui.html

My approach for AI generated code with more complexity was always this:

1. Ask AI to generate a spec of what we're planning to do. 2. Refine it until it's kind of resembling what I want to do 3. Ask AI to implement some aspects from the spec

Chat in English? Sure. But there is a better way. Make it a game to see how little you can specify to get what you want.

I used this single line to generate a 5 line Java unit test a while back.

test: grip o -> assert state.grip o

LLMs have wide "understanding" of various syntaxes and associated semantics. Most LLMs have instruct tuning that helps. Simplifications that are close to code work.

Re precision, yes, we need precision but if you work in small steps, the precision comes in the review.

Make your own private pidgin language in conversation.

It's interesting we view Email and Chat so differently. Some companies run on chat (e.g. Slack), while most companies run on email.

Emails are so similar to Chat, except we're used to writing in long-form, and we're not expecting sub-minute replies.

Maybe emails are going to be the new chat?

I've been experimenting with "email-like" interfaces (that encourage you to write more / specify more), take longer to get back to you, and go out to LLMs. I think this works well for tools like Deep Research where you expect them to take minutes to hours.

This has been the thesis behind our product since the beginning (~3 years), before a lot of the current hype took hold. I'm excited to see it gain more recognition.

Chat is single threaded and ephemeral. Documents are versioned, multi-threaded, and a source of truth. Although chat is not appropriate as the source of truth, it's very effective for single-threaded discussions about documents. This is how people use requirements documents today. Each comment on a doc is a localized chat. It's an excellent interface when targeted.

After using Cursor and Copilot for some time, I long for a tool that works like a "real" collaborator. We share a spec and make comments, resolve them. We file issues and pull requests and approve them. We use tests and specs to lock down our decisions. We keep a backlog up to date, maintain our user docs, discuss what assumptions we have to validate still, and write down our decisions.

Like with any coworker - when ideas get real, get out of chat and start using our tools and process to get stuff done.

For me: Chat is like writing comments, but not a the right place in the source code.

Perhaps I should comment all todos and then write "finish todos" as the always-same text prompt.

The workflow of starting with and iterating on a PRD is already taking off: https://x.com/daniel_mac8/status/1871372159748079893 https://skylarbpayne.com/posts/cursed-cursor

That's also why AGI as defined today is an interface problem. Imagine we've actually achieved it, and the interface is a chat prompt. It will be really hard to differentiate it with the current tools we have.

For writing, the canvas interface is much more effective because you rely less on copy and paste. For code, even with the ctrl+i method, it works but it's a pain to have to load all other files as reference every single time.

This current post is a good rebuttal to the killed post this morning: https://news.ycombinator.com/item?id=42933031 "Programmers are modern-day computers", https://jtlicardo.com/writing/modern-day-computers