"Current AI tools pretend writing software is like having a conversation. "
But that is true? Devs spend more time in meetings than writing code. Having conversations about the code they are going to write.
Chat is a bad UI pattern for development tools
141–150 of 432 posts
Re: Chat is a bad UI pattern for development tools
#142Narrative 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
Re: Chat is a bad UI pattern for development tools
#143I'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
Re: Chat is a bad UI pattern for development tools
#144English is a terrible programming language.
No it's not! :-) https://github.com/theletterf/english-lang
Re: Chat is a bad UI pattern for development tools
#145I'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 terribl…
Ok, but what is a good pattern to leverage AI tools for coding (assuming that they have some value there, which I think most people would agree with now)? I could see two distinct approaches: - "App builders" that use some combination of drag&drop UI builders, and design docs for architecture, workflows,... and let the UI guess what needs to be built "under the hood" (a little bit in the spirit of where UML class dia…
Disclaimer: Haven't used the tools a lot yet, just a bit. So if I say something that already exists, forgive me.
TLDR: Targeted edits and prompts / Heads Up Display
It should probably be more like an overlay (and hooked into context menus with suggestions, inline context bubbles when you want more context for a code block) and make use of an IDE problems view. The problems view would have to be enhanced to allow it to add problems that spanned multiple files, however.
Probably like the Rust compiler output style, but on steroids.
There would likely be some chatting required, but it should all be at a particular site in the code and then go into some history bank where you can view every topic you've discussed.
For authoring, I think an interactive drawing might be better, allowing you to click on specific areas and then use shorter phrasing to make an adjustment instead of having an argument in some chat to the left of your screen about specificity of your request.
Multi-point / click with minimal prompt. It should understand based on what I clicked what the context is without me having to explain it.
Re: Chat is a bad UI pattern for development tools
#146I'm intrigued by the conclusion. Docs-as-code, this time turning actual documentation and requirements into code? So, specifications? Back to OpenAPI?
Back to... programming languages? :)
Re: Chat is a bad UI pattern for development tools
#147I'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 terribl…
Email threads seem better for documenting and searching correspondence. The last counter argument I read got buried on Discord or Slack somewhere.
I find things get buried just as easily in email. People on my team are constantly resending each other emails, because they can’t find the thread.
This is why, if something is important, I take it out of email and put it into a document people can reference. The latest and correct information from all the decisions in the thread can also be collected in one place, so everyone reading doesn’t have to figure it out. Not to mention side conversations can influence the results, without being explicitly stated in the email thread.
Re: Chat is a bad UI pattern for development tools
#148I'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 terribl…
Ok, but what is a good pattern to leverage AI tools for coding (assuming that they have some value there, which I think most people would agree with now)? I could see two distinct approaches: - "App builders" that use some combination of drag&drop UI builders, and design docs for architecture, workflows,... and let the UI guess what needs to be built "under the hood" (a little bit in the spirit of where UML class dia…
Ok, but what is a good pattern to leverage AI tools for coding?
Re: Chat is a bad UI pattern for development tools
#149Re: Chat is a bad UI pattern for development tools
#150Yeah, I've landed on similar, although I wouldn't say it's bad for all dev scenarios. For small tweaks, or cases where I want a junior dev to do something I say explicitly ("add a bootstrap style input field for every property on #somemodel") chat works fine.
For higher-level AI assist, I do agree chat is not what makes sense. What I think would be cool is to work in markdown files, refining in precise plain english each feature. The AI then generates code from the .md files plus existing context. Then you have well-written documentation and consistent code. You can do this to a degree today by referencing a md file in chat, or by using some of the newer tools, but I haven't seen exactly what I want yet. (I guess I should build it?)