The Question Came Before the Code

How a simple question about trustworthy AI turned into an engineering experiment and what the process taught me about building systems.

It started with a question

Most software projects begin with a problem to solve or a feature someone wants to build.

This one began with a question.

What would it take to build an AI system that does more than produce a convincing answer?

I had been thinking about the difference between generating information and actually investigating it. Modern AI models are remarkably good at producing explanations. They can organize complex topics, summarize information and present conclusions in a way that feels coherent and confident.

But a convincing answer is not necessarily a reliable one.

I wanted to explore what happens when we expect more from an AI system. What if the process mattered as much as the answer? What if the system had to examine evidence, question its own findings and acknowledge the limits of what it could establish?

That question became the starting point for Evidence Investigator.

At the beginning, I was not trying to build a finished product. I wanted to turn an idea into something I could observe, challenge and improve.

Moving from ideas to experiments

One of the easiest traps in software engineering is spending too much time imagining the final system.

It is tempting to think about everything a project might eventually become. More capabilities, more integrations, better interfaces and increasingly sophisticated workflows all sound exciting.

But none of those possibilities answer the most important question.

Does the original idea actually work?

I decided to approach the project as an experiment rather than a product launch.

The first goal was deliberately limited. I needed a small environment where I could test the basic idea without introducing unnecessary complexity. I wanted to understand the behavior of the system before worrying about how impressive it looked.

This changed the way I evaluated progress.

Writing more code was not necessarily progress. Adding another component was not necessarily progress. Even receiving a successful response did not automatically mean the experiment had succeeded.

Progress meant reducing uncertainty.

Every useful test either confirmed that something worked under specific conditions or revealed another assumption that needed attention.

That approach made the project much more interesting than simply following an implementation plan.

The first version was only the beginning

The early development process was fairly straightforward. I built a small foundation and started checking whether the pieces behaved as expected.

Then I began connecting them.

That was when the more interesting problems appeared.

Something that worked perfectly in isolation could behave differently when it became part of a larger workflow. A response could look correct while containing an instruction that made no sense. A sequence of operations could appear productive while never reaching a conclusion.

Sometimes an external service rejected a request. Sometimes a provider was temporarily unavailable. Sometimes the application itself made an assumption that turned out to be wrong.

None of these problems were particularly surprising on their own.

What surprised me was how clearly they demonstrated the distance between a working demonstration and a dependable system.

I had initially been focused on what the application should accomplish. As development progressed, I became increasingly interested in how it should behave when things did not go according to plan.

That distinction started shaping nearly every subsequent decision.

The failures were more useful than expected

There were several moments when a test stopped before completing the investigation.

One issue involved an operation that appeared valid at first glance but did not meet the rules the application needed to enforce.

Another involved a process that continued through several stages but eventually reached a dead end without producing a final result.

Both issues forced me to reconsider assumptions I had made earlier.

It was not enough for individual components to perform their assigned tasks. The overall process also needed a reliable way to recognize invalid behavior and a controlled way to continue or stop.

The solution was not simply to let the application try harder.

In some situations, stopping is the correct behavior. In others, the system should be able to recover without discarding everything it has already accomplished.

Learning to distinguish those situations became an important part of the project.

I also began to appreciate the value of repeatable tests.

Fixing a bug is useful. Creating a test that demonstrates why the bug existed and prevents it from silently returning is much more valuable.

Each failure became an opportunity to make the next version more predictable.

That is a lesson I want to carry into future experiments.

When the pieces finally worked together

Eventually, a local test completed the full workflow and produced an investigation report.

It was an important milestone because several previously independent parts of the project had finally worked together in a real execution.

The result was encouraging.

But it was also important not to give that result more meaning than it deserved.

The successful test used a small synthetic dataset. It demonstrated that the application could complete a controlled investigation. It did not demonstrate scientific reliability across unfamiliar research material. It did not prove that the approach was better than a simpler alternative.

There is a meaningful difference between saying the system worked in this experiment and saying the system is reliable.

I want to preserve that distinction as the project develops.

It is easy to celebrate a successful result and move directly to the next feature. I think it is more useful to ask what the result actually tells us.

Which assumptions were tested?

Which conditions made the result possible?

What remains unknown?

And what experiment should come next?

Those questions are becoming part of how I define success.

Building with uncertainty in mind

Working on Evidence Investigator has reinforced something I have been thinking about more broadly in AI engineering.

The challenge is not only making intelligent systems capable of doing more.

It is making their behavior understandable and their limitations visible.

AI introduces a kind of uncertainty that traditional software workflows do not always prepare us for. The same input may not produce the same behavior every time. External models change. Providers enforce different limits. An apparently reasonable response may still be unsuitable for the task.

This makes experimentation especially important.

It also makes restraint important.

Not every problem needs another agent. Not every failure requires a more complex architecture. Sometimes the most valuable improvement is better validation, clearer feedback or a simpler decision about when to stop.

I am increasingly interested in building systems that are not only capable but also easier to reason about.

That means accepting that uncertainty cannot always be eliminated. It can, however, be observed, measured and managed.

Why I am sharing the process

Evidence Investigator is still an experiment.

There are more evaluations to run, assumptions to challenge and engineering decisions to revisit.

I could wait until the project feels complete before writing about it.

But that would leave out much of the work that actually matters.

The failed tests, unexpected behavior and small design corrections are not just obstacles on the way to a finished application. They are part of the knowledge produced by the experiment.

They also explain why certain decisions were made.

This is one of the reasons I started sharing engineering work through Runtime Garden.

I want this space to document more than finished software. I want it to capture how an idea develops into a prototype, what happens when that prototype meets reality and what we learn from trying to make it better.

Not every experiment will become a product.

Some ideas will need to change. Others may turn out to be less useful than expected. A few might grow into tools worth maintaining and sharing over time.

All of those outcomes can be valuable if the work is documented carefully.

What comes next

For Evidence Investigator, the next stage is less about building something new and more about understanding what has already been built.

I want to challenge the system with more varied examples, compare its behavior against simpler approaches and identify where additional complexity genuinely provides value.

I also want to keep improving the development process itself.

Better experiments. Better tests. Clearer documentation. Fewer assumptions left unexamined.

The project began with a question about whether AI could investigate information more responsibly.

The development process has led me toward a broader question.

How do we build systems that deserve our confidence rather than simply produce confidence?

I do not have a complete answer yet.

That is precisely why the experiment is worth continuing.

And perhaps that is the most useful thing I have learned so far.

A good engineering project does not always begin with a clear answer.

Sometimes it begins with a question interesting enough to keep testing.

This is part of my ongoing engineering journal at Runtime Garden.

Build. Experiment. Share. Grow.