Using AI every day, and still falling behind

Last week I gave a session on AI development tools to the learning community I run at Concordia University in Montreal. I’ve been using AI tools since April 2022, starting with the GitHub Copilot beta, more than half a year before ChatGPT came out. My team has used them in our daily work for about 2 years. These days I work with Cursor, Claude Code, and Codex, switching depending on the task, the latest features and models, and sometimes my mood.

I regularly give talks about how I use AI in my work. But preparing this one showed me how much I didn’t know: features I’d used once or never, and ideas I’d only half understood.

Even with daily use, there was plenty I wouldn’t have discovered without deliberately trying new ways of working. Having to explain these tools to my colleagues pushed me to explore beyond the tasks I already used AI for.

Some of those ways of working were brand new themselves. Cursor had just introduced Projects, where you give one agent a goal and it plans and delegates work to other agents. Then on September 22, 2 days before the session, OpenAI and Anthropic released major new versions of the models behind the tools I was showing: GPT-6 Sol and Opus 5.5. One of my demos had run on the previous models, and I said so in the room. Parts of the presentation were already out of date before I gave it.

In the week after the session, Anthropic released another model, Sonnet 5.5. OpenAI made more than 20 announcements at its developer conference, including Dots, always-on agents that each get a cloud computer of their own. Google announced Gemini 4. And while I was finishing this article, Claude Code added mods, small additions that let you change how the tool itself works. That’s one more thing to learn.

Those were two busy weeks, but something changes almost every day. Here’s the release pace across Anthropic and OpenAI this year.

Counting both companies, that’s something new on 179 of the 196 weekdays from January 1 to October 1, and several of the days with nothing were holidays. Claude Code, the tool I use most, has published more than 200 releases so far this year.

Nobody has a manual

I find this exciting, and a little dizzying, and I’m not the only one.

Last December, Andrej Karpathy, a founding member of OpenAI who went on to lead AI at Tesla, wrote: “I’ve never felt this much behind as a programmer.” He described a profession being rebuilt: the programmer writes less of the program, and there’s a new layer to learn on top of coding, from briefing agents to deciding what they’re allowed to do, with tools that are fallible and keep changing. He felt he could be 10 times more powerful if he properly used what had arrived in the past year. Nobody was given a manual, he wrote. His advice: roll up your sleeves.

No course can keep pace with tools that change every day. Networking and cloud platforms change all the time too, and most Cisco and AWS certifications are still valid for 3 years. Three years ago, almost nothing I describe below existed.

Training can give us a place to start, but it can’t keep us current on its own. And I have to stay current, because these tools keep changing how much of the work I can hand over. If I don’t learn the new way of working, I keep using a newer tool the old way.

The way I already use these tools still works, which is what makes it easy to stay with. I can finish the task, get a good result, and nothing breaks to tell me there was a better way. Most days I’m busy with the work in front of me, and I use the tools the way I did the day before. Preparing the talk interrupted that: I had to understand ways of working I hadn’t needed to get through my own day.

This can sound like chasing the next shiny thing. The difference is that each new way of working is something I can try on my own work and judge by what it produces, often within an afternoon.

Take Cursor Projects again. If you’ve only ever given an agent one task at a time, you wouldn’t think to hand over a whole feature. I only learn that kind of thing by trying it.

Ethan Mollick, a Wharton professor who studies AI at work, has been saying something similar since 2023: spend 10 hours just playing with one of the best models, and you’ll learn to do something nobody else knows how to do.

From answering to doing

The tools change every day, and the way we work changes every few months. In less than 4 years, we’ve gone from tools that answer, to tools that do the work, to tools that keep doing it on their own.

When ChatGPT arrived in November 2022, it answered. You did the rest: copied the code, ran it, found what was wrong, and went back to ask again. Every shift since then has moved a bit more of that work over to the tool. Here are the milestones I’d pick.

Two of these shifts changed my own work more than the others. The first was the terminal, and I think many developers would say the same. Once a tool on my own machine could read a whole project, run the tests, and keep going on its own, I stopped copying and pasting answers and started reviewing work. That’s when I began handing these tools bigger pieces of work, and understood how powerful they had become.

The second came this year: working with an agent directly in the browser. I lead the team that develops and maintains our CMS, so the browser is where most of our work shows up. Cursor and Codex now have a browser built in, so I can point at an element on a page and tell the agent what to change. And the agent can drive a browser itself. It opens a page, clicks, types, and reads what’s on the screen, so it can check its own changes or carry out a task for me.

From doing to doing on its own

The rest of this year’s shifts all point the same way: the agent keeps working when you’re not watching.

Half of the milestones I picked for these two timelines arrived this year. And the vendors keep landing on the same ideas: scheduled runs came from Cursor and Claude Code 2 days apart, and the always-on personal agent from four companies within 5 months. When several vendors ship the same idea, that’s a sign of where the work is going.

For most of my career, my tools worked the way Photoshop did when I started using it around 1995. Version 3 had just introduced layers, which changed how everyone worked, and more shifts like that followed, a version at a time, every year or two. Each one took time to learn. But through all of them, the tool never decided what to do next. It could repeat steps I had recorded, but it waited for me to work them out first. Getting better meant knowing the tool well enough that my hands kept up with my ideas.

A day can now look like this. I might ask one tool to translate a form into French, another to tidy up a set of pages, and a third to sort out a pull request, and they work while I do something else. When I come back, I read what they’ve done, decide what to keep, and check it. Very little of that is me typing, but the reading and checking is still work.

What this pace has meant for my team

We look after the design, accessibility, and development of the university’s CMS and its mobile app, with support from our colleagues in IT. The CMS alone has about 170 components and 98,000 live pages, with more than 300 people publishing in it and a release every week. I shared an earlier version of these observations at CMS Connect in August.

We ship more, and take on more. Our release notes listed 155 changes in 2023-24, 184 the next year, and 283 in 2025-26. That’s almost twice as many in 2 years. Building takes less time, so more fits into the same weeks. About 40% of last year’s changes were improvements to components already running across the site, the kind of work I wrote about in When AI breaks what it’s trying to fix. We also take on more at once. One example is modernizing our 13-year-old CMS: rewriting the code behind its components one at a time, while the site stays live and we keep shipping every week. We would have done it without AI, but not as smoothly, and not alongside operations and our other projects. The faster we change what’s already running, the more can go wrong.

The job got harder. There’s less grind, because the tools take on a lot of the typing and the repetitive work. But some of that grind was a kind of mental vacation, and what’s left needs full attention for longer stretches. We also need to know more than before. Experience and technical skill haven’t gone away: we still need to understand the technology we build on, know what depends on what, and troubleshoot problems nobody has solved yet. On top of that, we have to stay current with AI tools that keep changing, and with the ways of working that change with them. And we still own the work, even when AI wrote it.

We’re still getting used to this pace. Everything we add has to be reviewed and tested, meet our design and accessibility standards, and be maintained afterwards, so we have to decide what not to add. With several things running at once, we also have to know when to slow down: when to pause, when to take a break, and when not to start something new before the last thing is checked. I don’t have all the answers yet.

What has helped so far

Trying new ways of working takes time, and it takes a reason too. In large organizations, a few things usually hold people back: they’re waiting for an account, waiting to be trained, not sure what’s allowed, or too busy with the work they already have. All of that is understandable, and it’s rarely a lack of interest. But at this pace, a few months is a long time. This year alone brought eight of the shifts in the timelines above, and nothing visibly goes wrong while they go by.

Having an account doesn’t settle it either. I had three, used them every day, and still hadn’t tried several of those shifts. I’m lucky that my reason is curiosity: these tools excite me. I’m lucky with my team too. They use these tools every day, as I do, and we keep learning from each other. Even so, it took preparing the session to make me look past what already worked. For someone else, the reason might be a project at work, or something personal, like learning a language.

What follows comes from preparing that session and from my own team. I expect it to change.

On your own:

• Pick something you care about. Something small and low stakes, using tools you’re allowed to use. It can be for fun. One of mine was bringing an old project back to life. What matters is that you care how it turns out, because that’s what makes you check.
• Try new things on purpose. It’s easy to stay with what works. When a tool adds a feature or a whole new way of working, I push myself to use it on a real task, even when I doubt it will stick. Some of it won’t, and I can’t tell which from reading about it.
• Ask how AI can help. A line that changed how I work comes from Geoff Woods’s book The AI-Driven Leader: instead of asking “How do I solve this problem?” start asking “How can AI help me solve this problem?” I’ve been asking that ever since I read it, even when it feels a bit silly. It’s why I use AI for as much of my work as I can.
• Make sharing a habit. I understood these tools better once I had to show them to someone. So I try to keep doing it, and it doesn’t take much: a quick demo, a message to my team, a note on what worked and what didn’t.

As a team:

• Know the boundaries. Which data never goes in, which tools we’re allowed to use, and who to ask. Rules about data hold up longer than lists of tools, because the tools change so fast. (I wrote about how I handle sensitive data in Sensitive data doesn’t mean no AI.)
• Have a safe place to try, and the time. Somewhere a mistake doesn’t matter. For us, that’s a local copy of our system. It can just as well be a personal project, or anything where nothing serious is at stake. And enough time to try, without expecting every attempt to produce something useful.
• Have a place to share what you tried. Including what didn’t work and what needed checking. Our learning community started as a way to share what we know about web interfaces and accessibility, and it’s become the place where we talk about what we’re trying with AI.

I came into this session thinking daily use gave me a good view of these tools. Preparing it showed me how much I could miss while staying busy with the ways I already knew. The tools I showed that day have already changed. I want to keep the habit: try a new way of working, check what happens, and show someone else.

Read the stories behind the CMS Connect talk →

Read about one side quest →