Retrospective: The Work Habits That Actually Changed for Me in 2026
The last eight months feel like they packed in more change than several previous years combined. Not just faster AI tooling — although that’s obviously a big part of it — but how my day-to-day routine as a freelancer shifted without me noticing, until I compared how I worked back in January to now. This isn’t a prediction piece about the future of software engineering. Just an honest look back: which habits actually stuck, and which ones I tried briefly and dropped.
What stuck
The biggest change: I write far less code from scratch, but read a lot more. Earlier this year my time was still weighted more toward writing than reading. Now it’s completely flipped — most of my working day is reading diffs an agent produced, understanding the intent, deciding whether it’s right. This wasn’t a shift I planned. It happened gradually enough that I only noticed the day I compared how I “code” now to the definition I held five years ago.
I’ve also gotten a lot stingier about what I trust without verification — sounds like a negative but it’s actually the opposite. I used to trust AI output more easily whenever it sounded plausible. Now there’s a fairly consistent habit: anything touching security, financial data, or something hard to undo gets verified manually first, no matter how confident the tool sounds. Not paranoia, just a more accurate calibration of where AI is actually reliable and where it isn’t.
The line between “technical work” and “administrative work” got a lot blurrier too. I used to keep a clean split: coding time, invoice-and-client-email time. Now, since some administrative tasks can go to a browser agent or an AI assistant, that line isn’t as clean. My workday feels more integrated but also harder to measure — I can’t say “I coded for this many hours today” anymore, because a lot of time now goes into supervising and reviewing, not pure execution.
Two other things shifted alongside that: I’m a lot more comfortable telling a client “I’m not sure” about a time estimate — not committing to a fixed number upfront anymore, giving a range with more frequent checkpoints instead, and clients have consistently appreciated that more than a fixed estimate that often ends up wrong anyway. How I invoice also got more granular. I used to bill per project or per big milestone. Now I explain to clients differently what they’re paying for — not “this many hours of coding,” more like “this many hours of driving and reviewing the work until it’s correct.” A few clients were initially confused by that framing, but once I explained why it’s more accurate, most trusted it more, because it felt more honest than pretending everything was still typed out line by line the old way.
What didn’t stick
A few months back I had a phase of being genuinely excited about a multi-agent workflow — running several agents on different tasks at once in the background. Sounded efficient in theory. In practice I lost context: couldn’t review everything with the same depth, review quality dropped because my attention was split. I went back to one task at a time, just with an agent that finishes each one faster. Per-task speed went up, but the parallelism I thought would boost productivity wasn’t worth the trade-off in review quality, at least for how I work.
Chasing every new tool that came out didn’t stick either. Earlier in the year I tried almost every trending tool at least once. I’ve stopped. Not laziness — switching cost is real, and most new tools were incremental improvements on what I already used, not genuine leaps. I still try new things, just more selectively, waiting for a clear signal something’s actually different rather than just trending.
I also tried giving up on writing documentation myself and fully relying on AI to generate it. The result was documentation that was technically correct but missing the context for why a decision got made — something only I know because I lived through the discussion with the client. I went back to writing the “why” myself and letting AI handle the “what.” That mix is what actually stuck.
And treating “learning to prompt” as a separate skill to formally master — that didn’t stick either. Earlier in the year I read a lot of guides on prompting techniques supposedly guaranteed to dramatically improve my results. Some helped early on. But over time I realized the skill that actually mattered wasn’t clever prompting, it was my own ability to recognize when an output was right or wrong. A review skill, not a skill for writing elaborate instructions. The more I invested in review, the less it mattered how elaborate my prompting was.
If I had to boil this down to one pattern: the habits that stuck were the ones that added control and clarity to my own work, and the ones that didn’t were the ones that promised efficiency but ended up adding cognitive load for supervision instead. I have no idea what my routine will look like eight months from now — this year alone taught me not to be too confident about that. But at least I’ve got a more honest way to evaluate it: not “this sounds cool,” but “did this actually make my work better after I tried it for a few weeks.”