Building a polished website from a blank page is slower than reverse engineering one whose design you already like. I use Claude Code every day to build things. This approach works well for studying any site whose design catches your eye. Give it the link. Ask it to study the code, understand how each effect works, then send out a subagent that scrolls the whole page and screenshots every single frame. That gives it a complete picture of the site before it builds anything. From there, have it rebuild the site exactly as it is. Treat that rebuild as your starting point, not the finished product. Swap in your own images, copy, colors, and scroll mechanics once the structure holds up. That is the step that turns a clone into something worth shipping. Pick a site you have been eyeing and try it. Drop what you end up with here.

You do not need to be the best AI user in the room. You only need to be a step ahead of the people around you. In most workplaces that is already enough. Right now almost every company is stuck in the same spot. Everyone is talking about AI, and nobody is quite sure what to actually do with it. Not the manager, not the team, not the new hires. Whoever closes that gap becomes the person others go to first. That person is hard to replace. In practice it looks like this: → Find one task at work that annoys everyone, and fix just that one. → Show the result, not the tool you used. → Explain it so someone who has never touched AI still understands it. → Then repeat it for the next task. It does not matter where you sit: manager, employee, assistant, or new hire. The role comes from doing the work, not from someone handing you a title. Does your own workplace already have someone who has become the AI person?

Writing a rules file for an AI agent does not guarantee the agent keeps following it. Running automation pipelines taught me that the rules that hold are rarely the ones you only wrote down. I run a set of pipelines on a VPS: scrapers, rankers, render jobs, bots. Claude Code is how I build and operate them, not a side experiment. One of mine sat silently broken for days because a lock swallowed every failure without a sound. Another one nearly took the whole box down when several browser automations ran in parallel; they run one at a time now, behind a single lock. A parser once read a field at the wrong level of a nested JSON payload and returned nothing for every row. It just looked boring instead of broken, which is worse. None of those got fixed by a stronger line in a rules file. I fixed the JSON one by asserting on real values instead of just checking that a key exists. I cap how often a scheduled job can call a model instead of trusting someone to remember a limit, and I block a run instead of hoping secrets stay out of a repo. Where do you draw that line in your own setups? What do you still rely on a written reminder for, and what have you made the system enforce on its own?