Oh interesting, this is good info, thanks! I literally generated my first CLAUDE.md today, heh. And I’ve never used Tidewave. I still don’t really get MCP, but I’ll look into it now.
Also, apologies for de-railing the topic a bit.
To get back on track, other things I do while waiting: pet my dog. My laptop is his worst enemy.
It’s literally one deps line in your mix.exs and one line once only before starting Claude the next time. From that moment on, you just prompt Claude to use tidewave. that’s it.
this is the once only line:
claude mcp add --transport http tidewave http://localhost:4000/tidewave/mcp
max thinking effort – it does make a difference, it gets scary smart when it tries to scope out features and bug fixes because it considers much more of the codebase and the architecture but yes it burns more tokens.
All those add up.
One thing I am open to change is find a way to have Claude use high thinking effort for the less-clever tasks but I admit I am not at all interested in curating that. I throw it at all tasks on the max (heh) and yes, it’s not very economical but happily I don’t live to vibe-code two features a day. The work that I do is delicate and correctness still matters more.
This is a key point I didn’t mention: I’m using high, I actually didn’t realize there was max until just now, heh. I already find high crazy smart but I will try max.
Also re: single topic, I just started using /clear more heavily as I tend to bounce between topics (I’m kinda still prototyping as I think of stuff) and if it’s too much of a jump (which doesn’t need to be much) it starts conflating the previous feature with the new one and for whatever reason I found that incredibly annoying. Like the chirp of a low-battery smoke detector level annoying.
Yes, it always tries to connect a current discussion with a previous one and yes it’s definitely annoying. But I find ways to stop it and it does not happen super often. But yes, valid counter-point against having a single stream-of-consciousness session (like those that I do).
I do for sure also do it so I’m not sending tons of context back and forth so ya, I see… a lot of you are probably doing this and eating up tokens. I’m unemployed again so I don’t have the blank cheque to even really experiment with this kind of thing. The $100/month already isn’t great!
So, very short time using it, and I’m specifically reporting back with less for a reason:
So I’ve used this exclusively on styling tasks so this is all kinds of skewed, but I’d be interested to get others’ feedback.
The main difference I noticed using max effort was that it returned results much quicker, but consumed WAY more tokens, BUT with no discernible difference in output. Again, there are a metric 
ton of variables here, but the very first task I gave max effort was a CSS task that I believe “high effort” would have gotten wrong a few times before getting it right. Max effort got it in three tries but shot my freshly reset usage up to 11%! I feel like using high effort it may have taken five or six times but my usage would have been, like, 3%.
Does this track with anyone? It’s way too expensive for me to do some actual tests here.
For now I think I will stick to high effort and perhaps do the inverse of what is generally suggested: switch to higher effort when the thing can’t figure its out.
Otherwise, I don’t mind the extra waiting time to <insert things that I do while waiting for it to finish 
>
It is more expensive but for me the max effort helped with cross-app awareness (we have a monorepo) and paid closer and more persistent attention to the 50+ rules I gradually gave it. It was stopping and second-guessing its code edits and stopping dead in its tracks to then go back and fix a low-effort code that it “instinctively” output (its own words).
I’d say that probably up until a certain complexity level the high effort is the ideal tradeoff. But in my work max made an actual difference. Also, funny exercise: my colleagues still use high and when I give the max Claude their PRs to review, it finds 15+ defects, to the point that they gave up and told me “just take over the PR”. 
Which is the right call; 15+ defects and multiple messages of back-and-forth can easily consume the entire workday.
If this is Claude we are talking about I’d say styling is one it’s weaker spots, and I’m not sure adding more effort to bad work equals quality work or just more volume of bad work… The thing that I have found to work is showing some examples of how you want it or similar to what you want.
I usually use high effort, but might do higher in particular in the planning phase depending on the project. Skills help to some extent, and likely more with more effort than less. (I’ve tried with low effort and it was not too keen on using skills actively. I assume because that takes effort).
My experience is the opposite by the way - higher effort settings typically take longer. That might vary with the task.
They (LLMs) all suck at styling, not to mention shadow DOM styling. Like 0 knowledge on that matter.
I took time at some point, found various representative and well designed websites and industrial UIs, and made a few categories like landing page, information heavy website, industrial control dashboard, and so on. Then made a skill basically extracting and distilling the more general style features of each category into a design skill. That helped a lot, and combine with “make 4 options in this kind of style to choose from" there is usually something usable to choose and go on with.
I believe there are official frontend agents and skills too though, which should improve things and possibly considerably?
I’ve actually been finding them all right. Again, using just high effort, heh. But also I know a lot about CSS so I can guide it well.
Also, today I tried max effort on a non-styling task… pretty simple one: extract a birthday picker component. It just hung. I did the common “continue” and stuff (works something 
). There was obviously something else going on. Anyway, it blew through a bunch of usage to I switched it down to high effort and it got it. It made a couple of stupid mistakes but that was it. I suppose I should keep trying but I’m really fine with the results I get from high effort.
Try using the /btw command for Claude and ask it something like “What’s up? Been 5 minutes without a response” – sometimes it tells you what’s going on.
I caught myself using fed up manager speak: “What are you doing? This is taking way too long for a simple component.” I’m still feeling a bit icky from it imagining I was talking to a human, heh.
I have let loose like that a few times but it never led to anything productive really. It seems LLMs can panic of sorts and try to quickly fix a problem with lower effort (to please you and to quickly remove the source of aggression), making an even bigger mess.
Learning to talk to Claude has actually been a very interesting experience personally as well. It showed me, ah… shall we call them, a few gaps in sympathy that I still had. Not that I became a much nicer human being, no, but I do now make more and bigger effort understanding the root causes of misunderstandings and conflicts.
Ha! Well in this case it actually did make what I wanted very quickly as soon as I said it. It made a couple of small mistakes but they were fixed easily. I generally try not to talk to it like a human. It’s served me well.
What I meant by they suck at styling was they’re not capable of or eager enough in properly assessing the styling cascade. Plus, they still don’t know what works in shadow DOM and what doesn’t when it comes to tailwind.
Sometimes it seems it just get stuck in a loop and going in circles. Asking it to take a step back, look at the bigger picture, or change perspectives tend to snap it out of it.
Just some minutes I had Claude stuck on this error fixing, and it just kept shift alternatively between the same two changes. None of them worked but it didn’t remember having tried the other one earlier so it just kept coming back to alternating the same two.
Yep. This helped me finally rediscover my architect self and start bringing it out much more.
© Copyright Elixir Forum | Terms | Privacy & Cookies
