AI blogs

There's a particular kind of conversation that happens when a new developer joins a project that's already been running for a year. "Walk me through the authentication flow." Twenty minutes of explanation, questions, and the new developer's growing expression of polite confusion as each answer spawns two more questions. "Why is this in this folder?" Because of a decision made eight months ago when the structure was different, never documented, now just history. "Why doesn't this API follow the same pattern as the others?" Because one of those endpoints was added by someone who'd moved on before we standardized the approach. Onboarding is expensive. It's expensive in experienced developer time, in the time the new person spends finding things through indirect experience rather than documentation, and in the mistakes that happen in the gap between "I think I understand how this works" and "I actually understand how th...

There's a specific kind of confidence that settles in after you've been living inside a codebase for several weeks. You've written most of it yourself. You've debugged it, iterated on it, watched it evolve from a rough scaffold into something that actually works. The tests pass. The features behave as expected. You look at the code and feel, if not exactly proud, then at least comfortable. This was mine, and it was fine. That's exactly the mental state where blind spots grow. The project was a task management application for small teams — a full-stack build with a React frontend, a Node.js backend, a PostgreSQL database, and a REST API connecting them. About eight weeks of work, including a fair amount of refactoring as the feature set evolved. Not a massive codebase — around five thousand lines of meaningful code — but substantial enough that I couldn't hold the whole thing in my head at once. I'd been reading about using AI for code review as a compleme...

Debugging is where development time quietly disappears. A feature might take four hours to build. Debugging a subtle bug in that feature might take another three. And that ratio — more time finding and fixing problems than building — isn't unusual for developers working on real-world applications with non-trivial complexity. I'd been using AI to help with debugging for a while, but always informally — paste an error when I was stuck, see what it said, evaluate whether it helped. I didn't have a clear sense of how reliable it actually was across different categories of bugs, or where it was genuinely useful versus where it gave me plausible-sounding nonsense. So I ran an experiment. I collected 100 real bugs from my own projects and client work — nothing invented, nothing artificial — and let AI take the first shot at every one of them. I tracked the results, categorized where it succeeded and where it failed, and paid attention to the patterns. The rules were simple: AI...

At some point last summer, I counted my browser tabs at the end of a working day. Twenty-three. And that was a relatively focused afternoon. There was the project's GitHub repository, the documentation for two libraries I was using, a Stack Overflow answer I'd been meaning to read properly, three different conversations with AI assistants in separate browser tabs, the Jira board, two architecture diagrams I'd been referencing, and the usual cloud of context accumulated from a day of writing code. The deeper problem wasn't the tabs. It was that I was maintaining four or five different tools simultaneously during active development — the code editor, the browser, one AI assistant for code questions, another for general research, documentation I was checking manually — and the switching cost between them was constant. Every time I had a question, I had to decide which tool to ask, navigate to it, provide context again because nothing remembered our previous conversation,...