The work I do is changing, and so is the market around it. In 2026, I started seeing a noticeable shift in how teams value the work that goes into digital products. Rather than rely on what I was reading, I wanted to understand it through my own work, so I spent several months timing how I create digital products, doing the same work by hand, in a chat, and with an AI agent.

Work that used to take weeks now comes together in a fraction of the time, from first research to something a team can use. The skills that mattered most were knowing the subject, giving clear context, and deciding where people check what AI produces. This is a reflection on what I found, for anyone whose work is changing in the same way.

What my time logs showed

  • The whole process changed, not one step of it, and research shrank the most.
  • AI brought hands-on development back into my process, from early working versions through to production products, so a team can give feedback, test, and review much sooner.
  • Conversations with the people driving a project, and understanding their constraints, haven't changed. I don't expect them to.
  • Review and correction time is part of the total. Leaving it out makes AI look faster than it is.
  • Results depend on how well I know the task. Where I'm an expert, I give better context and judge the output quickly. On newer tasks, both take longer.
  • The more instruction I gave, the better AI agents performed, and speaking instead of typing made the biggest difference. The best overall results came from working in partnership with AI.
  • With output faster to produce, the value of my work has shifted toward judgment and direction.

How the market for my consulting work is changing

For most of my career, my value rested on judgment and a track record of launching products and marketing campaigns that worked. That hasn't changed. What has changed is how output is valued.

Anyone can now use an AI tool to produce output that looks high quality in a fraction of the time, sometimes modelled on what they see as a good example. Without data or experience behind it, that output can still look finished. In the short term, at least, that cycle is lowering what buyers expect to pay.

A website redesign shows it clearly. What I would have quoted two years ago is very different from what I'd quote today. That isn't because the quality has dropped. If anything, it's better and more informed. But when a buyer compares two proposals and one is a third or half the price of the other, the higher one is hard to justify, especially if the buyer already has a number in mind.

I don't mean to devalue people earlier in their careers, or anyone working outside their area of expertise, who use these tools. Used well, AI can give someone the confidence to build their skills, as long as the thinking and learning don't get handed over to the tool.

Jamie Gerrard presenting in front of a slide that asks, What skills actually matter now?, beside a projected social media post that reads, if your boss dresses like this, you're not getting replaced by AI, above a photo of dress pants and leather shoes.
Where this article started: a slide asking what skills actually matter now, beside a post joking that you're not getting replaced by AI if your boss dresses like this.

Measuring my own time was the most direct way to see how much of this shift was real in my own work, and what it means for the skills that matter now.

How I tested the same work by hand, in a chat, and with an AI agent

I tracked my hours by task type over several months. My main test was an end-to-end homepage redesign, from research through development, which I ran 3 times, each time doing it three ways: by hand, in a chat interface, and with an AI agent working through it. Then I compared how long each took to reach a result I'd stand behind. Time is the clearest record I have of how I work, regardless of how someone bills.

For each test, I set aside uninterrupted time, sized tasks against my own estimates of how long they used to take, and worked on my own projects and test builds.

This is a practitioner's record, not a controlled study. A few conditions are worth knowing:

  • I ran these tests in 2026. AI tools change quickly, so the times reflect that period. The method and the skills are what I expect to last.
  • I judged the quality of each result myself, against my own standard.
  • I usually worked by hand first, then in a chat, then with an agent, so each method benefited from the one before.
  • Each pass got smoother as I settled into an approach.
  • The biggest variable was me: how clearly I could describe what I wanted. I removed tests where my prompts weren't my best, so the results show what's possible with good input.
  • I used the same base model throughout, rather than the newest frontier model, so changes came from how I worked and not from a new release.
  • I've worked in tech for about 25 years. Someone earlier in their career would likely see different results.

AI changed every step of creating a digital product

A homepage redesign touches every step of creating a digital product, from research through development. The same way of working carries into the production products I work on, not only early versions.

Research is where time dropped the most. Gathering what's performing, reviewing analytics and past campaigns, and pulling together supporting data points could take upwards of a day. Now it takes a fraction of that time.

What hasn't changed is the conversations. Talking with the team and the people driving the project, and understanding the constraints they're working within, still comes first, and the rest of the research builds on it.

From there, giving a chat enough context up front gets me a first pass of the content and a visual design in a fraction of the time it used to take, followed by a couple of rounds of review and revisions. I haven't been using visual design tools like Figma lately.

AI has also brought hands-on development back into my process. A terminal window, GitHub, and Visual Studio Code are now part of my daily setup, something I wouldn't have considered a year ago. It isn't a substitute for what an experienced developer brings. It means I can carry an idea through to something working, so a team can give feedback, test it, and review it much sooner, while there's still time to change direction. To my standard, the quality of what comes out is as good or better.

Adapting to new tools has always been part of working in tech

AI is reaching more people, and moving faster, than earlier shifts in how digital work gets made. For anyone going through job loss or a career change, that isn't abstract, and I don't want to understate it. Still, the way I work with AI doesn't feel new to me.

When I started as a developer in the early 2000s, websites were coded by hand. Browser compatibility issues meant searching the internet for code snippets, and many people were working things out for the first time and sharing what they learned.

By the late 2000s and early 2010s, front-end frameworks and component libraries, such as Bootstrap in 2011, meant developers no longer built every interface element from scratch. Tools that set up a new project's starting structure automatically saved even more time.

Design tools went through their own version. Drawing boxes and saving them as reusable masters gave way to UI kits you could buy that covered most of what a project needed.

There will always be a place for people who prefer doing things by hand. I've never been one of them. Production was never the part I enjoyed, which is why my time as a developer was short and why I moved into strategy and the people side: solving the problem, testing it with real people, and improving it based on the data.

What's different now is how much of the process one person can carry, especially with the background to judge each part. I've worked in most of these roles over my career, so AI helps me do more of what I already know how to do.

Review and correction time belongs in the total

The part that's easy to miss is the time after the first output. Reviewing, correcting, and redoing what was wrong all count, yet that time rarely comes up when people talk about how fast AI is. Counting it showed me where AI saves time and where it doesn't.

The first output was strongest when the task was straightforward and I gave the right context. When I went in vague, because I didn't fully understand what I wanted yet, I spent time going back and forth and sometimes fumbling. That's normal in research, where I often start with an idea and don't know what the result will be. It still counts as time. The quality of what I give the tools depends on how well I understand what I'm asking for.

I track my time in a small desktop tool I built for time tracking, invoicing, and proposal drafts, which replaced my spreadsheet. It records the hours a task actually took separately from the hours I billed, with a note when I absorbed time on a platform that was new to me. The difference between those two numbers is the cost of unfamiliar work, and the same cost shows up when I use AI on tasks I know less well.

Knowing the subject is how I catch AI being confidently wrong

AI can be confidently wrong. Once, it gave me a detailed hosting plan that read well but didn't match how the account was set up. I caught it because I've done that work myself.

Building this website brought more examples. AI described a deliberate setup choice as a bug before reading the note that explained it, and reported a fix as failed when it had actually worked. I caught both because I knew how the site was set up, and each one went into the site's decision record along with what changed.

People can be confidently wrong too. In conversations about AI and other topics, I often hear firm views from people who have read a few articles but haven't done the thing themselves, succeeded at it, or failed at it. Hands-on experience is what lets someone tell a sound answer from one that only reads well, whether it comes from a tool or a person.

A study by Microsoft Research and Carnegie Mellon University found a similar pattern in a survey of 319 knowledge workers. Those with more confidence in their own ability at a task reported more critical thinking when using AI, while those with more confidence in the AI reported less. Even as the tools sped up production, my confidence in the results came from knowing the subject well enough to verify them.

Working in partnership with AI agents gave me the best results

Agent results depended on the type of task. Agents did extremely well on research and on taking my inputs and turning them into an output. Given little instruction, though, an agent's output was hard to judge. Some tasks could run fully on their own. Others worked better as start and stop: the agent runs, pauses at a checkpoint, and continues once I've reviewed it and given permission.

The more instruction I gave, the better agents performed. Switching from typing to speaking made the biggest difference. Dictating lets me give much more context in less time, and the tools understand what I'm after more clearly.

For how I work today, the best results came from a partnership. I like to think out loud and share as I go, so neither doing everything myself nor handing everything to an agent suited me as well. That may change as the tools do.

I've been listening to Ethan Mollick's new book, Co-Existence, where he describes different ways of working with AI. In the post that launched the book, he describes the newest one, the conjurer: someone who summons AI agents when needed, assigns them work, and evaluates what comes back. He also notes the risk that comes with it: losing control over what the AI is doing to get its results. My logs point to a bigger question: how to divide tasks between people and AI from the start, including when human input is needed, who provides it, and how it shapes the result.

My next project comes out of that question. I'm building an MCP (Model Context Protocol) server that lets AI tools work directly with the systems a team already uses, so the context people hold is there from the beginning.

Changing how I work mattered more than the tools themselves

The biggest gains came when I changed how I use the tools. I reordered my process and built in checkpoints to stop and review before moving on, so less needs fixing later.

On this website's build, checkpoints worked like this. Structural decisions came to me as two options with a recommendation before anything was built, and design changes started as a mockup before any code. Each build stage then went to a separate AI review that hadn't seen it being made, which scored the result against a bar I set. Anything that came in under the bar was fixed before the next stage started.

A Statistics Canada study found a similar pattern at the business level. Canadian firms that adopted AI had higher productivity than those that didn't, but the researchers found that the gap largely reflects which firms adopt AI and their broader innovation and digital transformation efforts, rather than AI alone. Their conclusion was that AI is most effective as part of a broader strategy, and that adopting it in isolation is unlikely to deliver major gains.

The value of my work has shifted from production to judgment

When production gets faster, its cost goes down. What remains is what was always at the core of my work: judgment, expertise, conversations with the people involved, and deciding what gets designed, built, and tested.

For the teams I work with, more of my time now goes into those conversations and decisions, and less into handoffs. They see a working version sooner and can respond to it while there's still time to change direction.

That shift is also why I now bill one rate for all of my work. The same judgment runs through everything, from setting the strategy to building what comes out of it.

The skills that mattered most when working with AI

Across my time logs, the same six skills made the difference between AI saving time and AI creating rework:

  1. Knowing the subject well enough to verify the output. Catching confident mistakes came from hands-on experience with the subject.

  2. Giving clear context up front. The first output was strongest when I understood what I was asking for and said so.

  3. Designing where people check AI's output. Checkpoints and review points decided how much needed fixing later.

  4. Counting the full time, including fixes. Without it, I would have overestimated what AI saved.

  5. Setting direction with the team. As production gets faster, more of my time goes to the conversations and decisions that shape what gets built.

  6. Adapting as the tools change. Hand-coded pages, frameworks, UI kits, and now AI each changed how production happens. Staying open to each shift has mattered more than any one tool.

Tracking your own time is the most honest way to see what AI changes

I'm more optimistic about AI than most of what I read suggests. For experienced people, it frees up time for the part of the work that matters most.

If you're trying to figure out where AI fits into your work, start by tracking your time, including the time spent fixing what it produces. Note how well you know each task, too, since that changes the results. Doing this is how I found out what had actually changed for me.

Amazon's engineering leadership took a similar view when it revised its role guideline for software engineers. It says it's best to measure, and be measured by, long-term outcomes, and warns that metrics like AI tool adoption can drive negative outcomes when used as targets. Engineers whose work doesn't benefit from current AI tools are asked to document why, share it with their peers, and bring it to their manager. In Amazon's words, that is "a finding, not a failing."

I've also written about what I hear from people who use AI, dabble with it, and fear it. These time logs are the hands-on side of those conversations.

I'd like to hear what others have noticed.

Sources