imankulov

You can actually test it yourself. The actual URL is in the post and the website is still up.

Like others mentioned, I like the framing of treating Claude Code as a tool (and I had to remind myself of it constantly).

Like any tool, it takes effort to master and configure. Before LLMs, I used cookiecutter templates to codify my best practices. Now I invest in custom skills and context management so the tool produces solutions that match my standards and team conventions.

I agree with the author that the craft still matters, and probably now more than ever. I'd add that mastering and configuring your agent is now part of the craft.

> I liked GPT primarily because I felt like it respected me: I never felt like it was trying to distract me from my work or get me to waste time doomscrolling.

Not about Sora, but about ChatGPT. I felt the same way for quite a while until I noticed that its response pattern has changed, apparently aiming for higher engagement. Someone aggressively pursued a metric.

At some point, ChatGPT started leaving annoying cliffhangers in its every response, like "Do you want me to share a little-known secret of X that professionals often use?" Like, come on!

Hackbraten is right. When I talk about dicts, I refer to a specific Python data type. Still, the truth is, I struggle to spell "dictionary." Even now, I copied the word from your comment.

I'd rather phrase it as "well-defined data structures help maintain your app." In another comment, leetrout recommended using named tuples. They define a list of their attributes without saying anything about their types, and this may be a perfect choice for some scenarios.

Huh, I worked with this architecture, and while it was convenient at first, it became an issue down the road. Here's what we had.

- A few times, we inadvertently exposed internal fields. They were not sensitive, just internal. Still, clients discovered and started using them and effectively blocked us from changing the data schema without updating the API version.

- A risk of inadvertently exposing sensitive fields. We never had this, but the mere fact that it was too easy to have, kept unnecessary pressure on us.

- Adjusting the serialization format for different purposes became a problem. When everything is a dict, it's difficult to bolt in custom serialization logic. We had this issue when we had to support different API versions, different object representations for different clients, or different purposes. For example, when we cache an object, we want to keep all the fields, but when we return it to an object, we need to maintain the subset of them.

- Slower onboarding. When a newcomer joins the project, they need to be aware that any database change may leak as an API attribute. They couldn't start working before they saw the whole picture.

Yes, the context is Python.