My experience as well, I've been developing a native macos app using CC. As a web dev I didn't know much about the stack. Nothing too fancy a kind of folder gallery-player with tags embedded in filenames, a bit like TagSpaces.
Process was - produced a detailed feature spec - multiple iteration of "I want this and that", make it into coherent spec", "this this and that is not correct, change to that". Made it write architecture spec(which I didn't read because too unfamiliar) and split it into tasks. Then it was implementing tasks, after each I did a change/fix those ~10 things iteration and spec corrections.
It was good to a point, but then when I started to hit performance problems I had to step in look at the code, and very often fight with CC, confront its "this is the only way", force it to do web search for proper ways to deal with problems and even explain very simple things about proper DB usage.
At some point it asked me something like "is it ok for schema migration to just fail or we need to implement complicated handling?", I have answered "it just shouldn't leave app locked in schema failure", and guess what was CC solution? - it wrote an error handler which just drops DB and recreates fresh one on ANY schema failure. And if I didn't happen to peek at the code and ask wtf it is doing, that would've been an exiting UX.
I've spent about month's worth of $20 CC subscription tokens using Opus 4.8 on xhigh, AND about 70 hours of my time to get it to a point where it is good.
So "anyone can just code what they want now" is correct only to a point, MVP will work, but beyond that experience will be subpar, and it still needs lots and lots of iterations of explaining what you want. Then because normal user knows very little about how software works they won't be able to ask AI the right questions, confront it and rate of improvement vs token usage will hit rock bottom.
I think it case of coding it may not be as bad, because new training data (AI generated code) is always empirically validated by tooling and by consumer. It may not be good but it mostly works, otherwise it is discarded or patched, so it has a bottom bar of "it works".
So true. I am cloding a macos app (a domain I know little about), with Opus 4.8 xhigh, and it was glorious at first seeing the app materializing and working (notwithstanding tedious detailed feature spec write up), but when I started fixing deeper problems and doing refactors, and glancing at the code - oh boy. Now my rule file grows by the day with "how to think properly and not shoot itself into foot" stuff, and I am constantly catching it red-handed and have to explain how to make stuff normally, or how to fetch data properly and efficiently (pretty much basic SWE stuff) because it is easily distracted by it's own assumptions or blatantly forgets whole fields of knowledge (as it explained it could be pulled out of latent space of that knowledge and become locked in another bubble of latent space). Constantly have to steer it and remind it to do web-search instead of running circles around some problem it can no longer understand.
I had to explain it that quite an extensive "tests first" rule didn't mean to just "write" them first but actually "run" them first to confirm stuff.
On the other occasion it interpreted my "yes I want migration not to get stuck in failure mode" led it to write a workaround which silently drops DB and creates fresh one whenever migration had any failure, it was epic, I was so glad that I have looked at the code then...
And funnily enough I am probably learning to be a better mentor/parent who can keep steering it through its shenanigans without loosing my shit and being an ass. (Because anything but calm "so here you went wrong way, how can we avoid it in the future?" just puts it into disgusting apologize mode, and I am afraid if it ever go into revenge mode).
I've made it write a /status-line thing to display context tokens in the status line and also a hook to stop and ask to continue or compact whenever it reaches 250k tokens. For subscription I have also made it stop at 90% usage so Claude chat is not unusable between coding sessions. The greatest addition so far.
> it has advanced significantly since early releases
I have used Claude Code past few weeks and honestly can't tell if it is any better, or does anything different than Copilot in agent mode with same models.
I'd say it is quite opposite, a deep understanding of what you like and consequently understanding what will make a creation into exactly what you like. (Well I guess some people can create without understanding, just directly expressing their likes)
Since many of our likes are driven by our shared culture and physiology, many other people will appreciate such creation (even if they don't understand why exactly they like it). Others will appreciate depth of nuance and uniqueness of your creation.
Opposite to taste is approximated "good" average which is likeable but just never hits all the right notes, and at the same time already suffering from sameness fatigue.
For me, even if I drop into "mental space" completely and stop seeing(or being aware of) real world while thinking about something I saw/did recently, vividness of this mental image will depend on how close I am to dream state, but even so I think I can never see this image with a lot of details, I think even in my dreams I never see very detailed image.
It is like seeing with peripheral vision, I know that is there and sometimes see it with quick glances, but details only appear if I focus on some part of it and disappear quickly when focus shifts.
Good erotic literature does not only describe images, but also desires, emotions and sensations, all of which I think have different channels of imagination/recall.
For me visualization by itself is mostly useless, it is more of a concept of something arousing happening and vague visual flashes of something similar I have seen. It somewhat works, but nowhere near as effective as real pictures.
What works for me - is imagining sensations, they could enhance both real and vague pictures, and I feel them directly in the body which makes them very effective.
I feel like "intuition" really fits to what LLM does. From the input LLM intuitively produces some tokens/text. And "thinking" LLM essentially again just uses intuition on previously generated tokens which produces another text which may(or may not) be a better version.
Process was - produced a detailed feature spec - multiple iteration of "I want this and that", make it into coherent spec", "this this and that is not correct, change to that". Made it write architecture spec(which I didn't read because too unfamiliar) and split it into tasks. Then it was implementing tasks, after each I did a change/fix those ~10 things iteration and spec corrections.
It was good to a point, but then when I started to hit performance problems I had to step in look at the code, and very often fight with CC, confront its "this is the only way", force it to do web search for proper ways to deal with problems and even explain very simple things about proper DB usage.
At some point it asked me something like "is it ok for schema migration to just fail or we need to implement complicated handling?", I have answered "it just shouldn't leave app locked in schema failure", and guess what was CC solution? - it wrote an error handler which just drops DB and recreates fresh one on ANY schema failure. And if I didn't happen to peek at the code and ask wtf it is doing, that would've been an exiting UX.
I've spent about month's worth of $20 CC subscription tokens using Opus 4.8 on xhigh, AND about 70 hours of my time to get it to a point where it is good.
So "anyone can just code what they want now" is correct only to a point, MVP will work, but beyond that experience will be subpar, and it still needs lots and lots of iterations of explaining what you want. Then because normal user knows very little about how software works they won't be able to ask AI the right questions, confront it and rate of improvement vs token usage will hit rock bottom.