Working With Artificial Intelligence on a Real Project

Artificial intelligence is talked about everywhere, but talking about it and delivering it are two very different things. Almost every business wants to explore it, and new ideas appear every day promising faster work, smarter decisions, and better experiences. I learned how much of that is real while managing a platform built around artificial intelligence for a public service, and the experience taught me a great deal about turning a fashionable idea into something people can actually rely on.

The technology, I found, is only one part of the challenge. The bigger responsibility is understanding how people will use it, where it creates real value, and how to build trust in the results it gives back. The goal on that project was never to add artificial intelligence because it was popular. The goal was to help people make better decisions while keeping those decisions safe, reliable, and easy to understand.

Why It Starts With a Clear Problem, Not the Technology

The first lesson was that a request to use artificial intelligence is only a starting point, not a plan. Many clients begin with a simple sentence. They want their product to be intelligent. That is easy to say and hard to build. Artificial intelligence is a tool, not the goal, so before the team writes a single line of code I want to understand why the client believes it is the right answer. What problem are we solving? What task should become easier? How will this improve the experience for the people using the product? Until those questions have clear answers, there is very little the team can build with confidence.

On that project we spent a lot of time discussing what a successful result would actually look like. The client wanted the system to make helpful suggestions. That sounded simple, until we realised everyone had a different idea of what helpful meant. Some people wanted the fastest answer. Others wanted the safest one. Some expected the system to decide on its own. Others believed every suggestion should be reviewed by a person. Those conversations turned out to be some of the most valuable work on the whole project.

Instead of making assumptions, we agreed on clear expectations before development began, in plain language. A good suggestion had to be relevant. It had to be easy to explain, so people could see why the system had proposed it. And anything the system was unsure about had to say so rather than guess. If there was not enough confidence in a suggestion, it was better to ask a person to review it than to present an unreliable answer as fact. That single principle guided many decisions later on.

Defining success early also makes testing far easier. When everyone agrees on what good looks like, the team can measure whether the product is meeting it. Without that agreement, every review comes down to personal opinion. And sometimes these conversations reveal that artificial intelligence is not the answer at all. A clear search, a simpler workflow, or better reporting occasionally solves the problem more effectively. For me this work has never been about building the cleverest system possible. It has always been about building the most useful one.

Keeping People in Control Instead of Replacing Them

The second lesson was that trust matters more with this kind of product than with almost any other. The platform helped organisations work with people who were trying to rebuild their lives, so the stakes were real. A feature that made a poor suggestion was not a small fault. It could affect a person. For that reason, I made sure someone always stayed in a position to review and question what the system proposed. The system proposed, and a trained member of staff decided.

That balance gave people confidence. They could review every suggestion, question it, and bring their own experience to bear before acting. The technology supported their work without taking control away from them. I have come to see artificial intelligence not as a replacement for people but as a tool that helps them make better decisions, and the most important part of delivery is finding the right line between the two.

We also had to decide how the system should behave when it was uncertain. It does not always have a perfect answer. Sometimes the information is incomplete. Sometimes two very different situations look alike. Rather than let it guess, we agreed that when it was not sufficiently certain, the answer was held back for a person to review instead of shown as fact. In my experience, admitting uncertainty builds far more trust than pretending to know everything.

People also need to understand why a suggestion was made. If they cannot see the reasoning, they are much less likely to trust it, so every part that used artificial intelligence was clear about what it was doing and a person could always follow and challenge its results. Many worries about this technology are not really about the technology at all. They are about trust. People want to know the system is reliable, that decisions are being handled responsibly, and that someone remains accountable for the outcome. Keeping people involved answers those worries far better than any technical explanation.

Why Ordinary Delivery Still Matters

The third lesson was that the ordinary rules still apply. It is easy to be dazzled by a new kind of technology and forget the basics, but every project of this kind still needs clear requirements, an agreed understanding of when a piece of work is finished, and honest communication. Without those foundations, even the most advanced technology can fail to deliver real value.

I start by building a shared understanding of success. Everyone involved should agree on what the product is meant to do and how that success will be judged. Without it, the development team may believe the work is complete while the client feels it is not delivering what they pictured. Clear expectations prevent that gap from opening.

Testing gets the same discipline as any other feature. Results are not accepted simply because they appear to work. We tested the system’s suggestions the way we would test anything else, against real examples with known good answers, and we did not treat a feature as reliable until it behaved consistently across them. If something did not perform as expected, we improved it before moving on.

I also pay close attention to the information the system can see. A tool like this is only as good as the information available to it, so before release we agreed and recorded exactly what data the system could access, who could use it, and how it was kept safe. Building that trust is as important as building the features, because if people are unsure how their information is handled, they will hesitate to use the product however advanced it is. Communication carries the same weight. These projects often involve ideas stakeholders have never worked with before, and a simple explanation of what the system can and cannot do is usually worth more than any technical demonstration. The technology was new. The discipline of delivering it well was exactly the same as always.

Using Artificial Intelligence in My Own Work

Managing the project taught me a great deal about the technology. Using it in my own daily work has taught me even more, and it keeps me honest about both its strengths and its limits.

It has become a genuine help with routine work. When I am preparing project plans, meeting summaries, requirement documents, or process guides, it gives me a solid starting point far faster than a blank page. Instead of spending time on the first structure, I can focus on improving the content and making sure it reflects what the project really needs. I also use it to explore different approaches to a problem. Asking for other ideas or another way to explain something often helps me see a challenge from a fresh angle, and even when I do not use a suggestion directly it tends to lead to a stronger decision. It helps with communication too, sharpening the clarity of emails and reports so I can spend more time on the decisions and less on the wording.

What I never do is treat it as the final decision maker. Every document I create is reviewed carefully. Every suggestion is checked against the project’s goals. Every important decision is made using my own experience, discussions with the team, and the needs of the client. These tools can save time and bring up useful ideas, but they do not remove the need for judgement. They are excellent at processing information, generating ideas, and handling repetitive work. They are much weaker at understanding business context, managing relationships, and balancing competing priorities, and those responsibilities still rest with people.

That is why I enjoy working with them. They let me spend more of my time on the work that creates the most value, planning, solving problems, supporting the team, and working closely with clients, while the routine work moves faster. I see artificial intelligence as a trusted assistant rather than a replacement. Someone still has to decide what good looks like, and someone still has to be responsible for the result.

A Real Project That Reinforced These Lessons

One project gave me a completely different view of what it means to deliver this kind of solution well. It involved building a platform for a public service organisation that supported people working to rebuild their lives. Artificial intelligence was meant to help staff make better decisions by offering useful suggestions based on the information available.

At first the request sounded straightforward. The client wanted an intelligent system that could assist their teams. As we dug into the detail, it became clear that everyone pictured something different. Some expected the system to decide automatically. Others wanted it to suggest while experienced staff made the final call. So before any development began, we answered a few important questions together. What decisions should the system support? What should always stay under human control? How would we know whether a suggestion was genuinely useful? Those conversations became the foundation of everything that followed. We agreed that every suggestion had to be relevant, easy to understand, and safe to act on, and that when the system was uncertain it should never guess. It should ask for human review instead.

Throughout development we tested the suggestions against real situations rather than relying only on technical checks. We looked at whether they actually helped staff decide better, and we confirmed that people could understand why a particular suggestion had appeared. When something was hard to explain, we treated it as a reason to improve the solution rather than something to accept. And we kept protecting trust. Every important decision could still be reviewed by a trained member of staff. The system became a source of support, not a replacement for judgement.

By the time we delivered, the technology was only one part of what made it work. The real success came from the careful planning, the clear communication, the honest testing, and the shared understanding that had guided the project from the very beginning. That is the lesson it reinforced above all others. Artificial intelligence alone does not create a successful product. Success comes from understanding the real problem, earning the trust of the people who will use the system, and delivering something that helps them work more confidently.

Common Mistakes I Still See

Artificial intelligence is changing the way we build software, but I still see teams make the same mistakes when they bring it into a project. Most of them have very little to do with the technology itself. They happen because the project is not planned with the same care as any other delivery.

The first is starting with the technology instead of the problem. Some projects begin with a goal of adding artificial intelligence because it is popular, and only later try to work out where it should go. That rarely creates lasting value. Understand the business problem first, then decide whether this is the right solution.

The second is expecting the technology to replace people completely. It can process information quickly and spot useful patterns, but many decisions still need human judgement. Removing people from those decisions lowers trust and raises the risk of a poor outcome. The technology should support people, not replace them.

The third is setting unrealistic expectations. Some stakeholders expect perfect answers every time. No system is perfect, and being honest about where it performs well and where it needs human review builds far more confidence than an overblown promise.

The fourth is skipping proper testing. A feature that produces reasonable results during development is not automatically ready. Suggestions should be tested against real situations and reviewed carefully before anyone depends on them.

The fifth is forgetting that trust matters as much as function. People want to understand why a suggestion was made and to know their information is handled responsibly. When a project chases technical performance and ignores the experience of the people using it, adoption becomes much harder.

And the last is assuming good project management matters less because the technology is doing more of the work. My experience shows the opposite. These projects need clear goals, thoughtful planning, regular communication, careful testing, and responsible decisions just as much as any other. The biggest challenges are rarely technical. They are about understanding people, solving real problems, and delivering something people are comfortable using every day.

The Biggest Lesson

If there is one lesson working with artificial intelligence has reinforced, it is that technology does not guarantee success. People do. It is a genuinely powerful tool. It can process information faster than any person, surface patterns that might be missed, and save time in many ways. None of that matters unless the product solves a real problem for the people using it.

So I always begin with the same questions, whatever the technology. What problem are we solving? Who will benefit? How will we know it is creating value? When those answers are clear, the team has a strong foundation for every decision that follows. And trust is worth more than impressive technology. People do not need a system that claims to know everything. They need one they can understand, question, and rely on. Being honest about what it can do, where it needs human review, and how decisions are made builds far more confidence than presenting it as flawless.

Artificial intelligence will keep changing the products we build. What will not change is the need to be clear about what we are building, careful about how we test it, and honest about what it can and cannot do. The best solutions I have seen do not try to replace people. They help people make faster, better informed, and more confident decisions while leaving them responsible for the outcome. Deliver an intelligent product with that discipline, and the technology becomes a genuine help rather than an empty promise.

Key Takeaways

• Begin with a clear business problem instead of adding the technology because it is popular.
• Define what success looks like before development starts, so the whole team shares one goal.
• Keep people involved in important decisions and use the technology to support their judgement, not replace it.
• Build trust by being open about what the system can do and where human review is still needed.
• Let the system say when it is uncertain rather than guess, and pass those cases to a person.
• Apply the same planning, communication, testing, and quality standards you would on any project.
• Test against real situations to confirm suggestions are useful, reliable, and easy to understand.
• Use these tools to work faster, but always review their output before an important decision.
• Strong project management remains the foundation of every successful project of this kind.
• The best solutions are the ones people understand, trust, and confidently use every day.