A chatbot using an LLM of course not, it suffers from hallucinations, it may do what you want but there is a change it won't and you have to fight it to get the desired result.

Chatbots are far WORSE than traditional UI for everything. If some product has a chatbot functions it's the first thing I disable, if it's not possible to disable it, I avoid the product.

And GUI applications are typically preferred, at least for the normal people and not us nerds, to CLI applications, since you know people like moving a mouse and clicking on buttons (or tapping them on a touchscreen) that learning commands: a chatbot doesn't make the CLI experience less awful for the average user, and for the nerd user, he prefers to use the CLI directly (replace asking the chatbot with man or --help and you don't need to emit tons of CO2 and transmit your personal data to a datacenter on the other side of the world to do stuff you did with MS-DOS)

Even though most of my projects have a UI, I build a CLI/API version so that the LLM can interact with it directly. I have been using this "CLI driven development" approach for more than a year now and have had fantastic results. The CLI arguments make it easy for LLM to interact with software it wrote.

I usually ask LLM to build a lib, then expose as a CLI and a RESTful API.

Words are a great UI. They can be easily converted into audio and haptics. We already have many systems in place that do exactly this with words.

Sure, pretty graphics are nice, but their sole intent should be to convey information. A User Interface that does not allow a person to easily have information conveyed to them is a bad interface.

The modern AI world isn’t perfect, but for a large portion of people who have accessibility needs, it’s absolutely a positive impact on their life in a way that no single technology has been until now.

A question becomes, how do you evolve a chat experience to task specific actions?

I’m building an app to explore scripture. Chat is an amazing starting point. But it’s terrible once you get into reading the actual scripture.

I think we will see more of this in the future. Here is how I’ve envisioned evolving an experience out of chat. Curious if others have their own ideas.

https://trysojourn.app

I’ve spent the last three years tweaking away at this algorithm. There are so many little details that have had to come together to make it an enjoyable experience. For example, take the one problem of balancing multiple language: What is the best way to balance multiple languages? How should you switch between them, and how often? What happens if you are over performing in one language and underperforming in another? What happens if you have more reviews in one language than another that isn’t in line with your priorities? How do you deal with competing learning speeds and language priorities? Spiky review burdens? What happens when you change your language priorities?

This is probably the most trivial part of the algorithm, and it took years of trial and error and dozens of iterations to get it to feel right. It requires knowing about SRS, the FSRS algorithm, language learning principles, and even then tons of experimentation, trial and error, and hundreds of days of daily usage.

I’ve asked LLMs every step of the way what to do. I’ve probably taken <1% of the advice I was given. Just asking an LLM “build an SRS app that balances multiple languages” would produce a result, but one that would definitely be terrible to use, and probably would end up slowing you down, not speeding you up. Explaining to it any of the issues that you would come across when using it will likely suggest to changes that will only make things worse, based on the thousands of terrible ideas I’ve seen confidently produced.

The hard part of a product is not the idea, but the experience of using it. The valueable work is normally not in the big feature specs, but the hundreds of little paper cuts that have all been smoothed over. The time saved is not because you don’t have to code it, but is from not having to become an expert in several different fields.

[1] https://phrasing.app

It's all opportunity cost.

Edit: throw in mandated security audits and maintenance for SOC2 compliance or whatever else you're on too, depending on the industry you're in.

Claude can 100% build you your own basecamp quickly, but there is a lot of good thinking that has gone into a product. Edge cases. Integrations. Clarity of thinking and ways to extend it. Agents love standing on the shoulders of good crystalized cognition (grep, curl etc), but I think that extends even beyond base CLI tools.

Which is not to say that "cheapest alternative" won't be much more important than it is now, but the tools that will succeed are the ones that solve clear problems with accessible CLI/tool-call like interfaces and take significant load off the agent running, while doing it efficiently and cost effectively so they are clearly better than building it yourself.

To be fair, there will be a ton of margin collapse and that will be unachievable by a lot of current orgs / structures.

Also: the coded apps that AIs build are unmaintainable without a tech background. They may work for exactly their proposed happy-path and that may be great. But over time I can’t see how it’s possible these apps get maintained.

Tomorrow's software will need to be _perfect_, or else it won't differentiate from "Claude, build a basecamp-style project management tool for my team".

there's an important caveat here - LLMs absolutely can write better code than me, but they can also write far worse code, and often don't seem to be able to tell the difference. I find myself spending a lot of time prompting the bots to refine their code in specific ways that I only know about because I read the generated output.

    but my anecdotal experience is that LLM written 
    software is very reliable and easy to extend and 
    develop.

Too much discourse creates a false dichotomy of "awesome, wonderful, hand-crafted code" vs "shitty AI slop."

A lot of hand-crafted code is pretty bad. This is true even with talented engineers: there are often edge cases they did not think of... and in many cases, could not have thought of.

And AI code is pretty good if it's steered and vetted by a knowledgeable engineer. It is clear to me, and has been clear for a long time, that "talented engineer plus AI" is the winning combination and will remain that way for at least the near future.

The actual code and architecture is where it still lacking IMHO. Especially in rails... Like it will just build the least scalable features if you let it do it's thing. Ten queries for what could be one. No separation of concerns. Huge files, lots of duplicated code and then tens of thousands of units tests that just grow like a fatberg.

If your app does anything serious, if you have serious traffic... you are going to need to review each session finely (and your DB schema with each deploy). It could be that this is maybe an indictment of rails more than LLMs, I guess maybe time will tell.

This is lacking a lot of nuance. There are many types of code. There are many situations where I'm analysing something one-off and if I get 33% success ratio, but can easily verify the result, I'm happy - still saved me time and money. They're are situations where I'm generating graphs from some dataset and I don't have to trust anything - I know what the result should look like, I just need the agent to drive matplotlib. There are low stakes dashboards which I'm happy to generate and develop entirely via agents - they'll embed the updated screenshots in PRs that I can yolo-merge - worst case is that someone complains about something not working next time they visit. Then there's lots of experimenting which was never stopped to hit production anyway.

Finally after all of that you get code that's actually part of deployable features. Of course the trust is nowhere near 100%, but if you have a healthy testing process (e2e, validating different browsers, or whatever is appropriate for your environment), then what's your trust in human developer+review? Because mine is nowhere near 100% either.

In practice there are places where I extremely don't care about the code and never wanted it anyway, places where I'll read the code to check the design or just in case, and places which agents are not allowed to touch (medical billing rules for example).

That is very not true for many cases. Agents generating code are usually painfully slow, finding workflows that replace that reasoning with running code usually speed things up in my experience.

My version of "code review" is "test failure investigation" and I have a hard rule in my repos that agents never modify existing tests while they're implementing features. This means that when I run the tests after they do a bunch of stuff, I see all the tests break. Mostly they're stale assertions and we patch them up. Sometimes they're regressions and we patch those up, and sometimes I notice something dumb and dive deep into a facet of the architecture that can be improved, spend some time exploring it then get the agent to implement.

I think it's a better approach than trying to read everything and catch bugs or improve quality because you wind up focusing the things that actually matter in the real world rather than the things you think might matter.

This is how I've always approached working with offshore devs too. Focus on testing for quality control, not "code quality". After all, you're going to look at the code you wrote 5 years ago and think it's shit anyway right? So all your code is shit.

Regarding "lack of understanding", here's a recent anecdote: I had a bug in a production (but relatively new) system. The customer was texting me saying that they couldn't scan a QR code because it kept "skipping and glitching". They sent me a short video. I described the problem to the agent and it figured out WAY faster than I would have been able to that the customer's clock was set incorrectly. They turned on network time and bingo bango, the thing worked straight away.

I don't thing "comprehension debt" matters at all, because if you want to know something about the code you ask the agent. I can't remember how anything works after 12 months anyway, so I would frequently have to spend ages grepping my own code when a customer came back and asked me to change something in a system we hadn't touched since last year. Asking an agent the same thing takes minutes and is way more accurate (and fun!)