Seven Big Opportunities for Developers to Save Time with AI

Now we have Fable 5, Codex 5.6 Sol, and open-weight models that keep getting stronger. Nobody knows how to use them best, but by now everyone has been experimenting for years. So what do you do when no one has the answers, but you need a signpost? For me, the answer is clear:

1. You listen to different perspectives.
2. You take the perspectives that feel right to you, and you run experiments based on them.
3. Then you form your own opinion.

That’s exactly what I recommend to every software team: Talk to each other, experiment, and find your own way. You had to do this before generative AI, too, and just because the voices of the people who want to tell you they know what they’re doing have grown louder, that doesn’t mean it’s suddenly true.

And even though my consulting work takes center stage on my blog and social channels in particular, I still build software every day, too.

So here are the seven areas of software engineering where I personally notice the biggest time savings in my daily work:

1. Research

AI processes information faster than I do — maybe not always 100% correct, but then again, we humans don’t manage that either. Back when I had to learn all the best practices for backend authentication from scratch on one of my first projects, it took hours — especially because it’s cognitively challenging to recognize early that you’ve taken a wrong turn. That’s how you can lose a lot of time running into dead ends.

Today, by contrast, when I want to find out how the Angular community handles error handling in modern projects, AI gives me a broad picture from a range of opinions that I couldn’t have found in such a short time. This is especially effective when I instruct the AI not to give me a recommendation, so that I can choose the path that best fits the project — without bias — and strikes the right balance between quality and speed.

Three tips for better AI research:

1. Avoid framing and bias: Give the agent only enough context that it can tell valuable information from useless information, but not so much that it makes the final decision for you or influences you.
2. Keep advertising from skewing the results: In my experience, Claude is very good at this; other models may need an explicit instruction. For example: if I’m looking for a SaaS provider for a compliance topic, I don’t want to be influenced by the providers’ blog posts, but rather, as much as possible, by independent comparisons or community discussions on Reddit.
3. Define the output format: This applies especially when you want to share the research results with your team. Nobody enjoys reading five A4 pages of AI prose. Train the agent to keep it short, avoid rambling, and highlight and back up the key information.

2. Code Exploration

For some concepts or decisions, I need a deeper insight into the codebase than my own knowledge and the existing documentation give me. If I want to make sweeping changes to the design of an API, for example (and have a good reason for such a drastic overhaul), I might want a list of all endpoints in table form, including request and response data types.

In 2020, I would have spent a large part of a workday on this, and probably questioned more than once how I got to this point in my life. In 2026, I get analyses like these in barely fifteen minutes.

Three tips for better code exploration:

1. Divide and conquer: In large repositories or with complex tasks, code exploration can fill up the context window fast. To prevent this, have the agent orchestrate several subagents that can each focus on one part of the codebase or the task, so that the agent only has to put the results together. If you work with Claude, you can also expect Claude to spot-check the agents’ results.
2. Check the results with spot checks: Read through the results and verify any statements or data points that give you pause. So that the time you saved isn’t lost during review, judge correctness based on the “hard” spots rather than on all of them.
3. Check the results with a second agent: Open a new context window and give this new agent the exploration results and the original task. Have it go through every point, and tell it that you have doubts about whether the first agent’s results are correct.

3. Library Debugging

Oh, how I’ve come to love and hate some libraries over the years: baffling query optimizations in NHibernate that couldn’t translate LINQ code correctly. A bug in Apple’s Foundation SDK that sometimes made generic JSON decoding crash an iOS app. A quirk in the Flutter SDK that made a certain screen layout look like it was breaking the laws of physics.

Back then, we joked that for some problems we had to decompile all the way into Bill Gates’ office — and that’s exactly what it felt like. This kind of debugging requires a high tolerance for frustration and a lot of tool know-how that some developers simply don’t have. On top of that, some of these bugs are so obscure that no one on Stack Overflow (RIP) or Reddit could help either.

Here, too, an AI agent can ease or prevent a lot of pain, simply because it already has a lot of library code in its training data anyway. That makes it the most powerful debugging tool I’ve been missing all those years.

Three tips for better library debugging with AI:

1. Use the GitHub integration: You can connect practically any agent to GitHub so that it can search current issues on the library for you and look for solutions “straight from the source.” As with the research in point (1): being able to search through so much information in such a short time is a blessing.
2. Use Context7: Anyone who reads the docs has a clear advantage. Even though it often helps to read the library’s code, good documentation frequently reveals valuable information about how a function is actually meant to be used. With the Context7 MCP, this information becomes accessible to the agent across a great many libraries.
3. Let the agent go as far as you never wanted to go yourself: Create a fork of the library just to try something out? Add another library just for this one case and see if it does the job better? Rebuild the library and simplify and adapt it for your own purposes? In the past, that might never have been worth the effort; today, an experiment like this is a morning’s project and, depending on the use case, maybe worth a shot.

4. Code Generation

The classic. Some people, mostly on LinkedIn, like to claim that they rebuilt Slack or Notion over the weekend. The rapid generation of code, especially on a “blank sheet of paper,” is what Anthropic and OpenAI reeled us in with. But the blank sheet of paper almost never exists in my everyday life as an engineer, which is why I’m selective — and getting more and more selective — when it comes to handing a suitable task in an existing system over to generative AI.

Three scenarios where code generation adds the most value:

1. Coherent projects: AI extends what’s already there. If your codebase follows conventions throughout, the AI will follow those conventions too. But if you often find yourself saying things like, “This part of the project was done cleanly; that other part, unfortunately, wasn’t,” then you have to tell the AI that as well. In this case, Kent Beck’s rule applies: Make the change simple, then make the simple change. Align the conventions across those areas before you let the AI off the leash.
2. Projects that honor standards: A backend that sticks to the REST standard needs no further explanation when it comes to adding an endpoint. A backend that “sort of uses REST, but sort of not really” has the problem that you have to explain the “sort of” to the AI so that it deviates from the standard as well. It’s better to ask yourself whether a deviation from an industry standard is really justified by the product. In my experience, that’s actually almost never the case.
3. Unit and integration testing: Here, too, coherent structures are an important prerequisite. Writing tests is tedious, and many engineers don’t enjoy doing it. For the AI, it doesn’t matter anyway whether it writes features or tests — and in the age of agents, tests are all the more important because they help you verify the AI’s work; a problem that keeps growing with the increased output and the extra review load.

5. Automation

If it takes me six hours to automate a task that costs me ten minutes once a month, the automation isn’t worth it. At the same time, there have been countless moments in my career when I wished I had a script I could just run instead of spending those ten minutes copying data from A to B by hand, for example.

Sometimes wishes come true: with the right eye for inefficiency and the discipline not to let a simple automation turn into the next internal SaaS with its own spot on the roadmap, AI makes it possible to automate many unpleasant tasks. Both complex Bash scripts that simply do what they’re supposed to and headless agents (e.g., via claude -p) make the hearts of those who loathe inefficiency as much as I do beat faster.

Three tips to turn your AI into an automation machine:

1. Ask yourself more often whether something can be automated: A few years ago, I rarely asked myself this question, because I knew automation wouldn’t be economical (see the first sentence of this section). That threshold has dropped, and the results are good. Even generating good App Store screenshots for an app can be automated well — an example where, back then, I would have thought, “How is that supposed to work?”
2. Always try the one-shot first: To minimize the risk of building the next internal SaaS after all, always limit your automation to a single prompt at first. If that doesn’t land, it can be a sign that the automation is more involved than you’d hoped. Keep the economics in mind.
3. Use Git for your little helpers, too: Just because it’s a private helper doesn’t mean it wouldn’t benefit from version control. A small extension doesn’t work? Then here, too, you’ll want the old state back. I had to learn that the hard way.

6. CI/CD

CI/CD stands here for everything whose correctness you can verify well, but which you don’t write yourself very often and which therefore feels extremely cumbersome every time. For me, it’s CI/CD configuration: often YAML syntax, regular expressions, and nested rules and conditions meet slow validation mechanisms. How do I know whether my configuration is correct? By trying it out. A build takes six minutes? Then go grab another fresh coffee and pick out your favorite episode of Hell’s Kitchen, because this can take a while.

As much as I enjoy watching Gordon Ramsay teach young cooks new skills: a task that would otherwise happily eat up half a workday becomes, with AI, something you can knock out in a single move (and a single prompt). Why? Unlike me, the AI knows CI/CD configuration more or less inside out, simply because it has it in its training data.

Three tips for how AI can make up for your blind spots:

1. Acknowledge that an area is your weak spot: In my experience, you have to name it. Subconsciously, you know which areas you have little experience in and which tasks are hard for you. You don’t have to be the all-star in every language, every framework, and every corner of your company. Acknowledging that lets you spend more time on the tasks where you are the all-star, and be realistic enough to get the unpleasant tasks done effectively with the help of AI.
2. Have its work explained to you: The mode used to be roughly: try it → google the error → fix it → google the next error → […] → be glad it’s over. Take advantage of the fact that these loops fall away, and take the time to ask questions about the work the AI did for you — not least because you’re still the one responsible for the code.
3. Have the AI document what’s happening: You’re probably not the only one on the team who’s reluctant to take on this task; otherwise it would hardly have landed with you. So that the next person doesn’t have to puzzle over how the code works again, have it briefly documented in the same session. Once you understand it yourself from the documentation, you know it’s solid.

7. Prototyping and User Testing

Rudimentary mock-ups are only of limited use. The less technical know-how users have, the less meaningful their feedback is in UX tests. If we manage to make what we show users up front less abstract, so that it instead feels almost like a real product or feature, then the feedback we get becomes more concrete as well.

Product-like prototypes always meant a lot of work. At the companies I’ve worked with, the consequence was often that UX tests were rarely or never carried out. Today, that’s easier: with clear instructions and good prompts, AI can build prototypes that feel real, and in a timeframe that would have been unimaginable just a few years ago. These prototypes can strengthen the exchange between customers and the product team, and keep us from building something that nobody actually needs.

Three tips for working with AI-generated prototypes:

1. Know the difference between a prototype and an MVP: A prototype is not developed further. It’s there for testing and does not represent the first version of a new product or feature. That’s exactly what makes it so appealing as a way to gather early user feedback. It’s not meant to become part of your core product.
2. Integrate your existing design system: Even if it’s just a prototype: your existing customers expect (usually subconsciously) that everything you show them looks like what they already pay for. If your prototype looks completely different, that can weaken the impression, because most people don’t like change, and a completely different look and feel can be a subconscious hint of exactly that.
3. Focus on the experiment you want to run: While generating prototypes, the AI usually has ideas for additional features that feel logical, and because it’s so easy, you tend to just tack them on. Always ask yourself: “Is this additional feature relevant to my user testing? Does it pay into the bet I’m making with it?” If the answer is no, leave the feature out and, at most, note it down for later.

Closing Words

What fascinates me is that this is a snapshot in time: after years full of experiments and rapid developments in this field, the seven areas above are the ones where I currently perceive the biggest time savings. In every section, you’ve read about conditions that, in my eyes, are very important for success in that area.

These statements hold now and as I perceive things. Two questions arise:

1. What about the future (in half a year, in a year, in five years)? Will we look back at this snapshot and admit that not much has changed? Or will we laugh and say, “Ha, look at all the things you used to have to do yourself back then”?
2. How much does my perception overlap with that of other engineers? I’m continuously working on the answer to this question through countless conversations, and it seems there’s a certain consensus between me and the best engineers I know. A side note: I’m looking forward to finding out, in a little over two months (at the time of writing this article), what the greats of software engineering think about it at GOTO in Copenhagen.

And finally: what are your experiences? Did you take away any impulses from this article that you’d like to bring into your daily work? Do you see certain points fundamentally differently? Do you have anything to add? I always welcome a productive exchange, and I’d encourage you to connect with me on LinkedIn. I look forward to hearing from you!