In April 2024 I wrote about a day as an rtCamp trainee: the cab, the bag that worked as an ID card, the CCD coffee. Two and a half years later I’m an SDE 2, working on large web products for global brands. Here is what changed in between, and none of it came from a course.
1. Code is written for other people
As a student, code had one reader: me, the night before a deadline. At rtCamp every line has at least three: the reviewer tomorrow, the teammate who changes it in six months, and the client’s developer who inherits it after that.
So I name things for the reader, not for myself. I keep pull requests small enough to review in one sitting. And I learned to read review comments as help, not criticism, which took longer than it should have.
2. Fast and accessible are the default, not the polish
On a site with a large audience, a slow image or a missing label is not a detail. It is a lot of people waiting, or people who cannot use the page at all.
Performance and accessibility stopped being a checklist at the end and became how I start: measure first (Core Web Vitals), test with a keyboard, and treat both as part of “done”. You can see the same rules in this site: every image has alt text, and every menu works from the keyboard.
3. When something breaks, own it and stay calm
Enterprise sites break at inconvenient times. The first incident I worked on, my instinct was to start fixing things. The lesson was the opposite: find out what is actually broken, tell people what you know, fix the smallest thing that stops the damage, and then fix the cause.
Calm is contagious. So is panic.
4. Explain the trade-off, not the tech
Clients do not need to know how a cache works. They need to know that the page will be fast, that an edit will take five minutes to appear, and why that is worth it. Learning to explain trade-offs in plain words, before anyone has to ask, did more for my work than any framework.
What changed in 2026
The biggest change since I was a trainee is not a framework. It is that I now write a lot of my code with AI. I work with Claude Code, on Claude models, every day: it drafts and edits code, writes the tests and runs the checks, and reads unfamiliar code with me before I touch it. We ship faster, and the small tasks that used to take an afternoon now take minutes. The time I get back goes into thinking about the change and reviewing it.
What did not change is who owns it. A person still reviews every pull request, whoever wrote the code. The conversations with clients about trade-offs are still mine. And my name is on the PR, so what ships is mine too.
The comment nobody sees
A while ago I started adding a hidden comment to the description of each of my pull requests. It does not show on the page, but it is there for anyone who opens the source: which models I used, which skills, how many tokens the work took, how much steering it needed, and how much of the change the AI did.
<!-- AI: Claude Code
models: Claude Opus, Claude Sonnet
skills: block-build, a11y-check
tokens: 1.2M · steering: light (3 corrections)
AI share: most of the code, tests by hand -->I did it to understand how I actually use AI, not how I feel I use it. A few months of it taught me three things:
- Steering is the real cost. The pull requests that needed a lot of steering were the ones I had not thought through before I started. The AI was not the problem; my brief was.
- Skills pay off. Work I do often, written down once as a skill with its rules, costs fewer tokens and far less steering the next time.
- Some things are faster by hand. The numbers show which tasks those are, so I stop reaching for AI out of habit.
What I would tell the trainee
You will not feel ready. Nobody does. Say yes to the thing slightly bigger than you, ask the question you think is obvious, and write down what you learn, because in two years you will not remember that you once did not know it.
