If I ask it to me produce a design, I'll almost always end up with something unworkable or inefficient.
Though if you push it hard enough then it can sometimes give you a good description of what existing code does and how it does it (which can be easily verified).
Every thread is endless back-and-forth between the "AI works great and vibe coding is the future" and "no, AI works great as long as you don't vibe code" camps.
But pick a technology used to write code and you’ll see many of the same things. Broad unit test adoption happened more then 20 years ago and people still can’t decide what it’s good for or even if it is useful.
That’s because it depends on the circumstances of the problem and the person solving it.
So no, we can’t decide exactly what it’s good for and if we could there would be exceptions. But that’s not an indictment of any tool.
AI is a diverse technology and will work differently for everyone, just like JS is a really, really bad technology for many, yet widely used.
On top of that it (as coding agent) is brand new, just a few years old. Looking at the history of technology it will probably take a few decades for it to settle into some sort of stability. Which does not mean it does not provide value during this time of exploration, however there is no trodden path leading you there.
And, you are right - use it as a fast typer, not a fast thinkier.
And for those who claim that AI is a good code writer - wrong. It can OUTPUT a wall of code, but it's overeager to flood you will legacy code on arrival to "solve a problem". It's harder to write LESS code, which is still the goal (even more true today).
That's a great way to put it.
“right tool for the job” - what job exactly, why so mysterious?
Planning: I often ask it to help me plan an approach if we are dealing with something I don't have a lot of experience with, most recently working with the DOM. If there is a library or an API that is new to me, I ask for an overview and run my plan by it for comments. Feed it the documentation and it is like talking to author.
Coding: I have a pretty reliable sense for when a section of code that I want to write is obvious enough for the LLM to one-shot based on the other code in the file, and on those occasions I call in completion. I do this with code that I can verify at a glance.
Analysis: If I have any uncertainty at all about the code I've written, I run it by the LLM to find issues. Out of all the other uses, I think this is the most productive and time saving. If I run into a bug and I'm stumped, I show it the section of code. I'm amazed at how good it is at finding mistakes.
I'm working solo as a full stack developer coming from a different background, so I sometimes find myself out of my depth. Having access to the breadth of knowledge that an LLM brings and its attention to detail has been game changing. I've tried a couple agents and configuring them to work competently seems like a rabbit hole, and I like the tight control over the context that chatting with the web prompt interface brings. It seems like half the value is putting into words my intent, it forces me to have a cohesive understanding myself. It is like rubber duck debugging where the duck can actually talk back and sometimes provide the critical part that I'm missing. I have it speak like a pirate which is just for fun but sometimes the sailing metaphors that it uses are really intuitive.
I ran into an issue where I was getting a segfault and everything looked right in the debuggr, including expected values near the segfault. Turns out I wasn't using placement new somewhere I needed, and the data for the object was getting copied but not the vtables. I have no idea how long it would have taken me to figure that out on my own because the segfault was coming from so far away
I haven't had the opportunity to use LLMs much for coding since I'm not working right now, but I can second how much of a boost just getting specific answers to my questions instead of reading tons of whatever online searches return is.
Rubber duck that talks back is a nice way to put it
I think of it kinda “very knowledgeable dumb person” - it knows everything but understands fuck all (although it can appear to do so just by breadth of information it has). If I can formulate a question in a way it gives me the correct info it helps me to conceptually understand the problem better then filling out the blanks. Often I figure out the answer to my question just by writing it down without needing to prompt it, so speaking rubber duck is very apt way to call it.
It used to be "oh, why am I getting an error on line 352, let me google the error message and wade through Stack Overflow answers" now it's "Claude, why am I getting an error on line 352? Ah, it's because $REASON, let's see if that fixes it, yes, thank you."
Obviously reading the official documentation is very useful, but sometimes you can't find anything that relevant to your exact use case, and forums are also very useful, but it can take hours or even days to get a reply to question when the LLM can do it in like a minute.
Bingo. Claude can bang out nearly correct code when I give it an idea, but it doesn't have the idea and repeatedly misjudges both how much work remains and what kind.
On the other hand, I don't know all the ins or outs of macro expansion in yaml at compile time or when and where macros run, enabling us to conaume their results elsewhere in the yaml. Frankly, if I had time, I'd happily spend time on that and learn more about it. I don't, though. Claude knows and does the guessing and checking. So I provide the concept and it translates into a horrible soup of yaml. Clearly I'm able to press forward with ignorance, which is dangerous. There's a real risk that I'll wind up with the kinds of unhealthy work that worries the author of the tweet.