claude

most of what i do in a day goes through claude in some form.

the chat is the first one. quick questions, looking things up, checking whether i understood something correctly, editing my own writing until it sounds less stiff. it replaced the tab where i used to keep ten half-read search results open.

then claude code, which is what i build with now. i used it through my work and i still use it for everything personal.

how i got here

cursor was first. it was the tool that made me realize an editor could hold a conversation about the code instead of just autocompleting it.

then github copilot, free on the student plan. that lasted until the plan got trimmed and the claude models were pulled out of it. once those were gone there was not much reason to stay.

i moved to claude code, and later gave codex a month because i kept hearing the usage limits were better. they were. it was genuinely strong on backend work, better than i expected. the frontend was the part i could not settle into. not bad, just not what i would have made.

i also tried antigravity for a bit. terrible experience, i kept landing on the outages.

i came back. what keeps me on claude code is the design sense. it is the best tool i have used for building the part people look at. i care about minimalism, and it gets there without me fighting it the whole way. the backend matters too, obviously, that is the engine. but the screen is the part someone has an opinion about.

the setup

my ~/.claude folder does most of the work now.

CLAUDE.md sits at the root as a router, and its only job is to stop claude from reading everything. it points at the few files that matter and nothing else.

commands/instructions.md is the main one. how to plan, when to break a task into steps, when to just do it, what to write down when it is finished.

rules/branch-strategy.md handles branch naming and tracking. agents/ holds the specialists: a code reviewer, a security officer, a performance optimizer, a QA lead, a release engineer that writes the PR description. each one is a role with a checklist, and i call the one i need.

skills/frontend-design/ is the design skill, which is the piece i lean on most.

then there is artifacts/<repo>/, and this is the part i would keep if i had to throw the rest away. every project gets a folder outside the repo holding vision.md for the plan, branch.md for what is done and what is left, tests.md, setup.md, pull-request.md. none of it touches the codebase. i can close the terminal, come back three days later, and the work remembers where it stopped.

working around the resets

usage limits reset five hours after your first message, the window you get is the window you started.

mine are 8:00, 13:00, and 18:00. at eight i say something small, sometimes just yo, before heading to the office. that sets the clock. i start at nine and work through the morning, take lunch at twelve while the limit is running out, and by one it has reset and i keep going. if i want to build something of my own at night, i send another at six.

it sounds fussy written down. in practice it is one message before coffee, and it is why the limits never really bothered me on pro.

which model

opus, almost always. i tried fable when it came out and it was more than i needed for what i do. opus already handles it.

sonnet i keep for chat. quick questions, small lookups, things that do not need much.

what did the work

during my internship, one of the devs wrote that i was among the most consistent in delivering quality work, and that the code was well structured and followed the specs and mockups closely.

i am putting it here because it is the honest counterweight to everything above. the tools are good. they are not what got written on that form. reading the output properly, knowing what the design was supposed to be, catching the thing that looks right but is not, that part does not come out of a folder of prompts.

all the setup does is clear the boring parts out of the way.