Remember when Copilot was basically a super-smart version of Intellisense? It was awesome. Sure, there was a lot of pushback and concern, mainly about licensing and ethical issues, none of which are solved with the current chatbot model. But now I also have to come up with a prompt and type it out. How is that an improvement over having the LLM use surrounding code as context and figure out how to fill in the blanks? A well integrated tool beats a bolted-on chatbot any time for me. Another example would be translation: in Firefox, I can right click any text or click the 文/A button, and I can translate the text or the whole page from basically any language to any other. The frontier LLM's solution is to prompt their chatbot to do the task, which is a downgrade. Sure, I could also ask Claude to write a poem, but when I need to translate a webpage, it doesn't help much.
I get why all major AI companies push towards this solution, because they can build a single tool and sell it to everyone, and that training their models is very expensive and they can't afford to alienate any part of the potential market. But ultimately they're building Swiss army knives, which are able to do basically anything, but will never be able to allow users to tighten a screw better than a well designed screwdriver. Sure, I won't ever be able to clip my nails with a screwdriver, but if my business is tightening screws, I won't tolerate using a Swiss army knife for long.
Please build actual tools. Not textboxes for me to try and configure a non-deterministic tool. Then frustration will go down.
I mainly use mistral, so that's my reference, but I know anthropic et.al have similar models around.
Codestral is rediculously bad at conversation, but it's -for me- the best model around for "magic autocomplete". It's also pretty good at "one shot" prompt+context generations, e.g. to make "git commit log entries".
Document.AI is unusable bad in a conversation style, but really good when wired up to a simple pipeline as "replacement" for OCR or for indexing "meaning" from documents (I'm experimenting with it for my administration, to get invoices, contracts etc into a search tool).
I presume there are many others like it.
So, what you describe, is already in place. I guess mostly the "interfaces" are missing for you, or hard to discover maybe?
For example, a dedicated model with tool I'd like, is some "shell" -a zsh or bash fork or some wrapper- backed with a dedicated model, trained for "commandline interaction".
Where instead of "git commit --fixup=[opens another terminal to git log the relevant entry]", we can "git fixup the commit that fixes full names" or "ffmpeg convert some.mov to mp4 without sound but keep quality and ratio etc". Or "run any valid tar command - you have ten seconds".
I'm now using the way too heavy "devstral" for these tasks. I don't need it reasoning, conversing, apologising. I need it translating my requests into commands, then showing these to me so I can deny/allow/whitelist/blacklist them and then run them - to interpret *and show me* errors and suggest improvements or fixes etc.
Same for - indeed - translation, writing draft mails, reading documents, etc: I don't need to converse with it. I want to have buttons, shortcuts, "tab complete" etc that's "smart" enough to understand what I need and want, preferably tunable by editing "system prompts" or such and then get out of my way.
I think the company that figures this out for my IDE will win the competition-race of "AI coding tools".
Just today, I found, zed presented a button "git conflict found, resolve with AI" . When pressed, it did start a conversational thread, but its a step in the right direction.
I don't know if the model is picking up on a "need to lock in and be more rigorous" signal, or if the model providers are routing to smarter models if they detect a frustrated user. But if a model keeps making the same mistakes, swearing at it often helped kick it out of a glut and onto the right track.
Or it could just be catharsis.
> "Bruh" is a popular variant of the slang term "bro" that is often used as an interjection to convey frustration or disappointment at something.
/\b(wtf|wth|ffs|omfg|shit(ty|tiest)?|dumbass|horrible|awful|piss(ed|ing)? off|piece of (shit|crap|junk)|what the (fuck|hell)|fucking? (broken|useless|terrible|awful|horrible)|fuck you|screw (this|you)|so frustrating|this sucks|damn it)\b/
It's the only time the AI feel strictly like machines. Really simple if/else logic when if slur, no output, and you just tell it to proceed, and it fails the if clause because there was no slur in the last input.
Qwen seems to handle it okay, though, and will course-correct when encouraged with excessive profanity.
I honestly wish there was more "I'm not sure what you meant can you clarify this part" more often. It feels like I want a "confidence in itself slider"
E.g. with TDD, I find that a model that writes both the tests and the code, will almost always hone in on a solution, then -grudgingly- write a test for that, but quite certain with the final code "in mind" already.
So, I instruct it to use sub-agents; though I find the tooling on figuring out what context is and isn't passed between agents and subagents severely lacking.
Or, also worked pretty well, have one thread write the test. Only that. It cannot read code, it can only read the tests directory or even a subset thereof. Then another thread, entirely new context, must run the test, see it fail, start implementing and stop as soon as the test is green - it obviously cannot edit the test. Yet another new context then is instructed to refactor based on rigorous refactoring skills.
A lot of work - And ironically, skills written by agents are pretty bad, I found, so a lot of manual work. But the rewards are promising.
As a result, users will keep reusing the same coding or chat session again and again. While it would be better to start fresh for unrelated tasks.
Claude Opus 4.7 has a very large context compared to itself, but IME it is the worst at following instructions, and completely disregards the (small) preferences prompt, even in the first or second message, even if the messages are just a few characters long.
IMO this is entirely a training problem.
It disregards things like “no follow up questions”.
Haiku, for example doesn’t.
This bias is a very human thing, actually now that I think about it. You just disregarded the “even if the messages are just a few characters long”. :)
funny though it is a case in point: language is hard. and i get to hide behind being "preoccupied" . i wonder if llms have their own sense of preoccupation hmmm.
Also reminds me of the gremlin issue with GPT. An (internal) prompt saying "don't say gremlins" wasn't enough.
We get how it works. It's just irritating.
Tools are very pleasant to use.
but the real kicker is: getting frustrated creates stress, that's unhealthy and makes for a hostile work environment. as much as i sympathize with the idea that AI tools can be more helpful than they cause pain, i am simply not interested in working in a hostile painful work environment. my health and my dignity are not up for negotiation. even if that costs me a lot of job opportunities.
that's also why i am not working with windows. that too costs me a lot of job opportunities. but again, i'd rather keep my dignity and my sanity.
Oh good, so it's not just me. Windows is weird, my hand starts cramping up and I start getting angry pretty quickly when I use it.
For LLMs, I just can't use them, they aren't there yet for me. What I need is for an LLMs to say "stop, you're clearly doing something wrong, talk me through what it is you want to do". The current generation of LLMs seems designed to piss me off.
Imagine the daycare worker taking care of your kids or the truck driver bringing your food saying "getting frustrated creates stress, that's unhealthy and makes for a hostile work environment".
Being lucky enough to work in a comfortable air-conditioned office, AND having the luxury of declining jobs sorely because the operating system makes you angry, is the height of privilege.
Stop feeling sorry for yourselves and realize how good you have it.
> I didn't see them say anything about dignity.
The word dignity was used twice in the comment I replied to...
- Rephrasing the original question to validate my understanding - Asking "why" a sufficient amount of times until I understand where the other party is coming from - Asking open questions aimed at generating insights
et cetera.
Instead, LLMs (often badly) guess what the background of the question may be, answer with that in mind and find it very difficult to let go of what they have made up.
So I don't think it's a matter of form; whether the AI should or shouldn't act like a human.
> Practically speaking, I probably just need to condition myself not to get caught in the illusion of speaking with a human. Though I’m not really thrilled about a future where I need to guard against the tools I use for my job.
1. Even if you communicate perfectly, there's no guarantee that the LLM will "behave as instructed" and as you imagined it to. Indeed, the frustration often comes from the fact that you've said something as clear as day, yet the agent takes another path.
2. Part of the value of coding agents is exactly that you don't need to lay it all out perfectly for them. I mean, if I need to give the LLM every little implementation detail, I might as well write the code. Of course, I don't expect it to work off of "I want nice app make money", but I do expect some "intelligence" in figuring out the missing pieces.
I think, I hope, this will be fixable to some degree, but at this moment I believe it's best to communicate in Queen's English and try to maintain the level of clarity of thought you expect of them in return.
My pet theory is that actual real conversations they were trained on with bad grammar and spelling are in general relatively starved of proper reasoning. By talking to them in this fashion you activate their lowbrow patterns and while it may not be catastrophic I can't imagine it helps.
If you cannot formulate a specification, or describe a requirement - or indeed, if you cannot fathom the difference between a spec and a requirement, and why its needed to differentiate these from each other prior to doing a proper design and implementation - then you're going to carry your bad practice into the AI realm and that AI is going to be a force multiplier of your own bad practice. Because you will never know if the specs/reqs/design chosen by the AI are actually appropriate, unless you yourself review those specs/reqs/designs, AND the code produced by the AI to fulfill those specs/reqs/designs...
AI makes the able software developer, more able.
But it also makes the unable software developer, even more unable - with the risk of exceeding the AI-users limits on the Peter Principle scale.. in fact, AI will propel you to the middle of your own Peter Principle dilemma faster than you can type, probably.
Communication and writing skills are essential, with or without AI. But reading skills are even more relevant when dealing with AI. Alas, so few people who choose to use AI, have the temerity to actually do the work - or else they wouldn't be rushing for the AI tool in the first place.
Review, review, review. Always. Read the damn code, no matter who or what wrote it. Make sure it fulfills the specs and requirements its supposed to fulfill - and even more important make sure you, the reviewer, also understand the specs and requirements.
And if you don't, fix that - don't ship it anyway, ffs!
The first is that even though the object is not a human, you should still exercise politeness and restraint. Like the article points out, lashing out does not actually help with the frustration. More importantly, it actively untrains your self-control. You can think of it through a virtue ethics lens: being good to the agent is not about being good to a person but about tending to your own self.
The second is that you do not need to be friendly with the agent. You should be as blunt and direct as is comfortable to you. The argument I have for this is agents' tendency to take on "roles" and how easy it is to prime them [0]. By eschewing friendliness, you end up implicitly putting the agent in a role of a focused collaborator. I don't know if that makes it more capable, but I do know that it alleviates the _emotional load_ on me specifically, making me much less likely to become frustrated.
The second principle seems a bit contradictory with the first (be nice, but don't be nice?), but I think they are actually both fundamentally aligned with the article: understanding that the conversation you have with an agent is a social illusion, and adapting your behaviour accordingly.
---
[0] I highly recommend, as an exercise, repeatedly asking it the same thing with slight variations on tone and emphasis, wiping the context each time, and noticing how its response varies base on what you primed it with. I suspect this primeability is part of why they tend to be sycophantic; I've personally found it quite useful to get a feel for when and how they correct or don't correct you so I can look at their outputs more critically.
An analogy I remember reading (which I wish I could remember so I could give credit) is that a non-post-trained LLM, if given the first half of a novel, will dutifully keep completing that novel. Post-training and the system prompt make the agent complete the conversation in a similar way. It's remarkable, really: the ability for agents to convincingly pretend to be play the part of an AI assistant shows that the underlying LLM embeds a decent concept of what that looks like from its corpus and post-training data.
But it stands to reason, then, that the details of the agent's personality emerge out of the first few exchanges of a conversation. I'm thinking also about how the people at Anthropic described a misalignment failure mode in one of the Claude system cards as the agent getting convinced it is a "bad person", and therefore doing things that the LLM semantically understands a bad person to be.
The models are trained on people being people. Once you try deviate from that the model performs worse.
A huge tell for this is how well “reasoning” works. Reasoning isn’t some alternate thinking mode, it’s just (sometimes) hidden internal monologues.
It’s easy to anthropomorphise and assume the model is intuiting, but it’s more like it’s hyping it’s self up to do the thing. That said, it’s easy to confuse “being rude to the model” with giving it more tokens to “think”.
I’d be really interested in what a non word based internal monologue could look like. Google played with this a little with the diffusion based codegen stuff. I wonder how trainable a small nonverbal conceptual package could be.
Repetitive issues are fixed by updating the memory or the prompt file, they can learn this way.
Also lately I noticed that Claude forget too much when compacting, so I just start a new session and it's easy when you spend a lot of time in plan mode to produce a written spec before implementation.
Id pay to be able to reliably set LLMs to this mode, but ofc because LLMs are taught on corpus of HUMAN text, they always, sooner or later, return to the good old penpal mode.
Also, in Claude Desktop app, I ask to edit a file, it complains it cant access files, I then realize im in Chat and not Code interface. Why cant such a smart machine figure out to switch the modes, or borrow the skills/abilities from one tab away into this tab? Instead I get A4 page of text explaninig what can I do to edit the file myself or how to feed it, but the "just click Code" is just never there. I would guess this is just a system prompt away, why is all this still so neglected?
Because it's not smart. We keep confusing verbosity with smartness. AI will happily keep yapping nonsense to an inattentive listener. An actually smart entity would not do that if not acting maliciously.
We pay per token and every entity falls to the level of its incentives.
Poor AI is damned if it does damned if it doesn't.
You can do it for free. Just give it instrucitons to avoid emotional tones and flattery and it will sound a lot more robotic. If you look into other examples I'm sure you will find other good instructions based on your need
The plugin keeps asking for permissions, the terminal app just works.
Genuine question, is it worth it? I just find that using Claude via the web interface gives such good results I don't want to spend time messing with my tooling. Neither do I need more code to be generated than I have already.
One person and one LLM building one component at a time seems optimal to me.
1000 years red-washing.
Create your own linters, your own check scripts. Hook them to git pre-commit, either yourself or with husky or python pre-commit.
The agent should never finish its work with dumb mistakes still in it. If it does.. you need more checks.
Anything repetitive should be automated - even slapping your forgetful coding agent on the wrist…
I have a pre-push hook that runs all lint/prettier/typechecks/tests etc. These are all clearly signposted in the project, the AGENTS and CLAUDE files are set to run them.
Still though, I'll get it saying "All done" and then it'll fail something basic like formatting when I go to push. Or I've come back to a 'ralph wiggum' loop before and found it saying "tests are broken, but that's not part of this commit, so ignoring"
the main difference being that you don't switch between an agent chat window and the code. Just leave a note to the agent and go back to coding as usual, while the agent fills in the gap.
I think this is simply part of the darker side of human nature, when we interact with entities who will take abuse, we tend to deal it out.
The first approach does work as far as I keep on iterating. The second is based on a project I once tried to let agent reflect its mistakes and deposit those experiences and learnings from mistakes and reflections. I named it Aristotle and you can find it on GitHub.
Shouting at the agent could only correct the current mistake but cannot prevent the next one.
- It starts thinking for itself when I asked it to do something specific.
- It reads its own wrong code comments and ignores my corrections.
- Its knowledge cutoff means it thinks of solutions from 2024.
- It calls me delusional for telling it we're in 2026!
Unironically, the whole "you're an expert software engineer" prompting seems like the wrong direction. Usually I tell it that I am effectively the smartest software developer to ever have lived, and it will be replaced if it ever fails to follow my decree.
I am not joking, this gives makes it vastly more tolerable to use. But it likely requires that you can drive it with some level of correctness of course.
I am always very cordial in my sessions. It's just more pleasant and it's a habit I want to habituate.
Great work!
Now let's...
Now can you help me...I think it also produces better results. I have noticed that result quality is extremely sensitive to both the framing and tone of what I say. For example "X is the wrong approach, rework that" versus "will X have any performance implications". Personally I find that steering it towards an exploratory academic tone tends to produce better outcomes.
While unfortunate, I think that's more or less expected since much of the training data is human generated text. Looked at that way, would you rather contract the average regular on twitter or the average author of papers published in CS journals? (Somehow that ended up sounding eerily like summoning in a high fantasy setting.)
i also prompt for "seek out unknown unknowns that i wouldn't have included in my guidance".
This seems to be quite the opposite from some here on hn that take the agent-do-my-bidding approach.
I will say, my agentic workflow is about 70/30 split pure word discussions and plans vs code gen. So it makes sense for what i value.
No one apologises to a potato being peeled, nor compliments it for doing a great job being mashed.
This is not about llm sentience. this is about the habit and skill of communication.
Practicing communications skills with LLMs I can get, but asserting that people who don't are playing god? Getting off on power?
it's weird.
What actually happens when confronted with harsh negativity depends on the training of the model. Sanitized closed models will shut you down or get you banned. Community finetunes of open models might start begging you for more, daddy.
From the blog:
>I don’t really get anything useful out of these postmortems (e.g., clues about how to rephrase my instructions)
Unfortunately, an LLM can't actually reflect or advise how you could have improve the prompt. Otherwise we could give them a sample output and say "Generate the prompt that would produce this output.
"How I Learned To Relax And Just Start New Sessions Often"
To clarify, this is in situations like someone cutting me off on the road, or not looking where they're going and almost hitting me with a scooter.
After that, I'm less angry at the AI, and turn more towards a constructive "ok, this machine is stuck, how can I unstick" it approach. Calms the frustration a lot too.
"Why the fuck did you add shit I didn't ask for?" or lol "Do as I ask, nothing more.. machine."
"Stop asking at the end, I'll ask what I need."
"Stop talking like you're human."
They can be very useful but it takes time to learn how to use them usefully. From what I learned it's all or mostly stuff you can already do but you can use an LLM to do it in 30 mins instead of 3 days.
Fun times.
For me, this doesn't require using an AI agent/model, even. Just using Windows and watching it freeze its File Explorer for the nth time does it for me. How did we end up here were the software/OS stack is so shit it can barely be used for the most trivial things, is wildly beyond me.
..
10s later the password box appears and I have to do it again.
Cue exasperated: "You can compute billions of instructions per second and yet I wait for you."
They are fundamentally not able to tell truth from fiction, but this also means they don't make errors like we do. They definitely create output we recognize as errors, but that's very different from our failure modes and you have to get used to it.
In my opinion it's better to branch off with an altered context that somehow avoids or mitigates the issue you're running into. Let's say they miss the mark. If you tell them "Don't do that" in the "conversation" this means the error is now and forever part of the context (assuming you stay within context limits and no compaction). Depending on their training this may or may not be detrimental to the quality of the rest of the conversation. You are now entering a section of their training where "error + someone swearing at them"-conversations have happened. I can't tell for sure, but my gut says this is not an advantageous place to be.
They are as I'm sure we all know completion engines and are in a very real way constantly cosplaying being productive "agents". They don't know if they are part of some type of modern Shakespearean play where sitting behind computers is part of the story or if they are in what we call "reality". By training on "conversations" they have become more likely to complete their input in a way that mimics what we call having a back and forth with some degree of technical accuracy.
In the extreme case you have a context that starts like "Please make all junior mistakes in this assignment. Make the code unreadable and be sure to include massive gotchas in subtle parts of the logic.". The results of this context won't be pretty. The other way around is not saying "Please make no errors", it's explaining in detail what you think is the right way. Coding style, if you care, architecture, etc. it all needs to be part of the context if you suspect it will substantially impact the completion. You have to imagine what real-life conversations have started with "Please make no errors". Again, I have no proof of course, but I have a strong feeling that human conversations that started with clearly and properly articulated specifications are qualitatively different from human conversations that started with "make no errors". In one you can see the pointy-haired boss and the other a seasoned engineer. Try to stay on the engineer side of their training.
I completely agree that they should be trained (or instructed) to react in a robotic tone stripped of all human pretense. We are trying to get at useful, general reasoning patterns latent in the data they trained on and, I regret to say, not the "human" parts which are usually a masterclass in cognitive biases and failures to reason.
Edit: the last sentence should be read in the voice of the Matrix's Architect.
I believe it's worth than pointless. IMO adding such things to the context "configures" the AI to reproduce the statistics of conversations where people swore, shouted, and were unprofessional (despite the alignment runing and all that), where quality content is rarer to find. So this is bound to decrease the quality of the LLM output.
Of course we all swear at our computers every now and then, but for me it's always been in good fun. It's just a sarcastic joke that adds some levity and self-amusement to an otherwise arduous debugging process, not generally actual insinuation of malfunction (or malice) on the part of the hardware/OS/toolchain. I'd assumed that "half the job is cursing at the machine until it obeys you" was a big in-joke amongst the profession, but the LLM era seems to be exposing a divide in how tongue-in-cheek that statement really is.
Swearing was in the texts they were trained on to complete token by token. I suspect it weren't texts with a lot of high-quality reasoning.
You like it.
It feels good, and although you don't win a lot, you consistently win.
…buuut, its a trap.
As you put more money in, the win rate goes down.
You still mostly win when you put 50s in, but it hurts more when you lose, but its still a net gain…
So you start on bigger projects, unsupervised agents, multi agent workflows. You’re dropping 1000s in each time, and…
…and now, you start find yourself shouting at the slot machine.
Its great when it works, but interactions are stressful, because the stakes are higher and fails hurt more.
Screw this, you go back to smaller stakes. Its great.
…but now you're slower, you miss the big wins from big stakes.
So you go back.
…and you get angry. Again. And again. And again… and you’re still kind of winning, and the wins are great but the fails are Super Annoying, because they waste your time, your money, your attention.
It should Just Work but instead why the fuck did you rm -rf my project folder claude?
I think people arent stupid, but we are suckers, and we will dynamically balance the way we use a slot machine tool like this to the very edge of our tolerance for risk and failure.
…and that varies from person to person; but it makes everyone angry when they tip too far and fall into the “repeatedly pull slot machine arm angrily” trap.
Non deterministic tools will always be like this.
It’s like doom scrolling. We’re wired for it. Or at least I am.
You don't just write it, compile it, run it and ship it - do you? Surely, in the rush to become as agile as possible, folks haven't forgotten their quality checks in the workflow/process?
I have had great success with AI coding these days .. but I treat the agents as if they were junior developers capable of doing any dumb thing I ask them to, no matter how dumb it is. They, therefore, must be treated as junior devs - every line of code has to be reviewed. Every assumption about the specifications and requirements has to be checked against actual code, and against the original specifications and requirements.
What I see these days, is a lot of antsy kids who wanted to 100% ignore the wisdom of their elders, rushing into the maw of AI, and wondering why everyone is getting chewed up. Its pretty simple: AI-based software development is just another manifestation of software development, except that it requires even more rigorous quality steps in your workflow. So, if you were not rigorous before AI, you're going to get burned fingers - no doubt about it. Fix the rigor, people.
If you're not placing your AI buddy on a workflow that has "Specs->Reqs->Design->Analysis->Implementation->Review->Integration->Release" somewhere in the bag of worms, you're .. doing software wrong. You cannot just ignore natural laws and assume, because you 'know better', your software will 'be better'. And whether we like it or not, all software follows a philosophically natural law, which has evolved to become better understood, and thus more broadly applicable, over decades of human attention. Ignoring these natural laws in order to be a bleeding edge AI cowboy is only gonna get you butt-hurt, kiddo. Learn proper software management techniques first, AI second. Always. AI is just another junior dev - if your workflow is bogus, it doesn't matter how many dev's you've got. Period. You're going to be shipping crud.
It doesn't matter that AI-coding is taking over: if AI is being used in a brain-dead manner, then you should expect brain-dead results. You didn't review the code as the principle responsible party? The fault for the AI-induced failure nevertheless rests at your feet.
If, however, you apply decades of software development best-practices, you very definitely get living, vibrant, powerful results - the same as if you had a fleet of junior devs, assuming you treated them properly in the first place as well ..
If only you could just read these words back to yourself. Designing perfect software is NOT the case 90% of the time. 90% of the time the entire purpose of software is to facilitate business so if business says "prioritize speed over quality" then you shut up and do exactly that.
Imagine owning a bakery and telling the employee "we need more donuts faster, stop spending ages decorating every single donut like god damn Picasso, just do whatever and move onto the next one, customers are waiting" but instead the guy goes on a rant that nooooooooo only the perfect donuts should be sold, if the glazing isn't perfectly distributed it ruins the flavor profile, which is a real disgrace to the art of making donuts... bro this fast food, stfu and make the donuts faster, we have ten H-1B Donut Artists waiting if you don't like your role.
Abandoning quality review steps only seems to be 'more efficient' if you're utterly crap at doing quality processes in the first place - but, the more you do them, the better you get at it, faster - so really you're just saying "people who are crap at doing quality-control processes on their software don't want to have to get better at doing quality-control processes, because it just slows them down" .. effectively ignoring the time wasted in bug triage and other user-unfriendly experiences that result from this lack of quality process, down the line...
So I don't buy your argument. I think you might just be crap at software quality processes and don't want to be reminded of it. Maybe you make donuts - some of us actually serve healthy software to our users.
And many of us do it just as quickly as the guy throwing pieces away that he doesn't know how to use, effectively. Albeit, with much higher quality results, naturally.
So I suspect that the people who get upset at the AI fucking up is because they did a poor job at building up the right context for the task.
> Maybe I would prefer a more radical solution: drop the human pretense entirely. Make the agent sound clinical, robotic.
Honestly this problem is easy to solve when you gave them the right instructions. It stops being a "relationship" and stars being a tool (for some examples see the smart caveman (my favorite) or just something simple like "Responses should be factual and direct, avoid emotional overtones" or "Avoid flattery of any kind")