The brief is simple: make the most accurate prediction of the relationship between any two countries. It sounded naive but when I thought about it, questions arose about what it really meant. A system that predicts wars? Famine? Coups? By being a way to look into the future, the model wouldn’t just tell us ‘what will happen’—but ‘what should we do?’. I’m terrified. I’m coding anyway.
When the team recruited me as the tech developer for this project titled “Diplomacy Software”, the technical part sounded straightforward. Our main objective was to build a predictive model that amasses data and creates insights. “Nothing a developer couldn’t do overnight”, I thought.
Instead of focusing on the development process itself, this story examines the inputs that drive it. I finally came to terms with a fact I had always acknowledged but never laid out explicitly: it is part of a developer’s core responsibility to resolve moral dilemmas about their creation before they start to build.
Ideating Revolution
When we were discussing the idea, it quickly became clear that it wasn’t a tool to just aggregate information but rather a tool to produce extremely accurate predictions. My team initially thought predictions simply meant extrapolating the data you have right now to the future.
If this had been the case, it would have been a trivial problem. After a few runs of a couple of the simple algorithms we developed, we realised how much more complex the problem was than we could have imagined.
This is an example of an issue that affects developers at all stages: misunderstanding the scope of the problem. Your algorithm can be overwhelmingly complex, but added complexity alone doesn’t guarantee a better solution. Yet, we often adopt the simplistic mindset that piling on sophisticated algorithms will make our solution better.
While this does apply to a few, well defined problems, it is very important to remember that most real world problems are different. Dealing with these problems is like playing chess on a 100 x 100 chessboard. A board where the rules can change halfway into the game. There are a lot more variables than you can capture and a lot more relationships than you can think of. The approach we need to solve these problems are different.
In hindsight, the approach I should have followed would have been to take some time to better understand the academic field of geopolitics before starting to build.
Back then, we went the other way. The failure taught us this: the future doesn't just depend on past events but it depends on the unique circumstances of the present. More often than not, the present cannot be captured in an un-opinionated manner because different people see the issues that affect the world in different ways. This then affects the predictions they make.
Our revolution to the world of geopolitics could therefore never have been just a presentation of data. It would always have a certain worldview attached to it. As a result we are imbuing our worldview into the decisions made by our clients. This led us to a harder question: was this justifiable? Selling predictions to top generals which carry our model’s implicit opinions.
The Transparency Obsession
My nightmare? A false prediction starts a war. We fed our model 80 years of data—treaties, speeches, even crop reports. It spots patterns humans miss. But is ‘unmatched accuracy’ possible? Or hubris?
Thinking about this made me start to pivot my focus and energy from accuracy towards transparency. What mattered to me was that all our predictions were backed up by the assumptions, data and pre existing knowledge that went into them. In addition to just the moral obligation, I also started to understand this as the key business function that would help us build the trust of our clients. It is not easy to make a president listen to an algorithm, is it?
The need for transparency definitely complicated the build. We couldn't just build a black box model like a large neural network and throw it at the problem. So then came the blowing up of development timelines. We needed to start from scratch to create a learning framework that would emulate current geopolitical thinking, so as to be able to explain our findings in a way that our clients will understand.
However I still firmly hold my belief that transparent but limited is much better than board ranging but opaque. The costs were simply too high of our algorithm making decisions that could not be backed up. The lives and livelihoods of people are at stake when it comes to building such transformational algorithms.
Stress-Testing Mania
Often, it's not just useful to look at the future to understand the potential your application has, but also to understand the challenges that it faces. In our case where we were trying to create radical change, this was crucial because any unintended behaviour could affect the lives of millions of people. It's not hard to see why:
Model predicted chain reactions: Hackers fake data → AI misreads intent → Missiles launch. Failure isn’t an option.
It is not unreasonable to think that such a situation might arise with an algorithm that is fully independent. Fortunately, our algorithms did not go into such extremes but we definitely saw our fair share of inaccurate or ludicrous predictions. As a developer, it came across to me as a personal responsibility to ensure that maximal amounts of testing were done to ensure that such mistakes were properly studied and corrected.
However, this proved to be difficult: maybe even a bit too difficult. Our progress was very slow. Each time we made a mistake, we conducted enormous amounts of testing. Excessive complications arose with the already complicated algorithm. Basically each new day of work, we came across a new issue and spent even more time trying to fix that issue. Eventually, we abandoned the project.
Staying Strong
Although no real world changing impact came out of the first iteration of the project it highlighted some key lessons when it came to how algorithms can change the world.
The most important lesson is to understand the problem firsthand before you start building a solution. Use tools and techniques that are proven in your field instead of relying solely on generic algorithmic approaches, which often oversimplify real-world complexity.
So this is a call to all the developers out there who want to build amazing applications: go out and explore the breadth of ideas out there. You never know that one day they might become central to your world-changing creation.
The second lesson is adaptive resilience. Applying more and more force is often not the best way to get something to budge. It is more efficient to change your approach. What is required is that you don’t give up. Remember: no one ever changed the world because it was easy.
As of July 2025, I'm trying to re-architect a solution to this problem. I've taken into account all the limitations that plague does last time around and then planning to build a significantly better algorithm that is better engineered to be able to deliver transparency without becoming overly complicated. Taking a step back has helped put the problem in perspective. This perspective is badly needed to be able to see hidden opportunities that I could use to overcome limitations of the past.
Changing the world
The best way to have an impact on the future isn’t to predict it, but rather to build it. As developers, there has never been a better time for us to go build systems that remake relationships. It might sound impossible but it's not: it's just very, very difficult.
There are a lot of ethical questions that go into building revolutionary products. There's also a lot of ingenuity in the process. Combining the two will help you build systems that will win the trust of customers, clients, friends and family. In the business of changing the world, trust is the most precious resource.
So start today and put your revolutionary system into the real world. Just remember: design with humility.