Claude is really good. It has definitely become an indispensable part of my toolkit. Maybe even the most indispensable after the OS itself, the editor and the compiler (and git of course).

However, over the last two days I’ve definitely learned the type of tasks it (still) can’t handle well. This one was not even too complex, it’s just it takes a bit of that “returning back to the problem and wrapping your head around it again”:

The change request was effectively to refactor a specific pattern typically having two LiveComponents, one of which is additionally wrapped into a function component and turning it all inside out - effectively inverting the slotted child with its parent. It required some thinking about the assigns, the order and syncing of the rendering relative to fetching the data, taking care something that didn’t use to flash/get hidden while waiting/syncing doesn’t do so this time either (both LC’s being self-managed in terms of fetching their respective contents and reporting any errors to the user), and so on.

My personal estimate for doing this “manually” was 4-5 hrs for the pattern and the first UC leveraging it, together with all the testing.

Claude and I have been on it for ca. 2 work days now and it’s almost done (almost because it’s finally working but we’re now polishing Claude’s left-overs).

The take away:

1. When faced with across-the-board changes - applying changes over several related elixir modules, some of which “inherit” from (use) other modules, some having their templates slotted into the templates of others, etc., it only seemingly does this better than me (because I initially feel no burden myself), but the payback time comes as soon as the testing begins.
2. Some of the bugs (types of bugs) it introduces are of the kind a skilled developer would never make such as placing conditional LV renders at will with zero acknowledgement of possible repercussions, freely inventing new naming/terms (that mask the old ones used elsewhere sometimes even in the inverted fashion when booleans) in what seems like an OO paradigm encapsulation (directly conflicting the easy-to-search-for-and-find-later “paradigm”)
3. Even when pointed to patterns/modules to reuse, it tends to forget it after a while and implement it all over (generate redundant and completely pattern-non-conforming code).
4. Does such tiny little messy things such as adding conditionally-hidden <div/> wrappers where only one side of the condition is covered (i.e. “hidden”, while forgetting the “contents” for a flex layout item).
5. Last but not least, it’s way too slow for many cross-template or cross-module operations I can do faster and better.

On the other hand, what it’s truly good at is diagnostics, and adding incremental code/features within a limited, well-defined and isolated context.

UPDATE: Almost forgot - the main issue remains the state tracking (or the lack of).