What I learned using AI outside software

At 47, after years in software development, I found myself back on the job market.

I’ve been applying for IT roles since the layoff and am still figuring out what the right next step looks like. At the same time, I’ve had more space than usual to explore something completely outside my normal technical world.

One of those explorations started almost accidentally, over dinner with a friend.

It became one of the most useful experiments I’ve had with AI outside software.

Not because AI gave me a brilliant idea. Not because it knew everything. And not because it replaced people with actual expertise.

What interested me was something else: how useful could AI become when I had to enter a field where I had almost no domain knowledge, no network, and no obvious starting point?

The subject happened to be the food industry.

I knew almost nothing about it.

That was exactly what made it interesting.

It started over dinner

During a casual dinner with a friend, adaptogens came up in conversation.

He (Silf) half-jokingly suggested there might be a business idea around them.

I barely knew what an adaptogen was.

The conversation could easily have ended there. Instead, curiosity followed me home.

I started where most people probably would: asking AI basic questions. What are adaptogens? What kinds of products exist? Who supplies them in Switzerland or Europe?

One of my first practical prompts was essentially:

Who are the suppliers in Switzerland or Europe that work with adaptogen products?

AI gave me a list of companies to investigate.

While going through them, one company caught my attention because it focused less on adaptogens in the broad sense and more on functional mushrooms, mushroom species commonly sold as powders, extracts, capsules, or tinctures rather than simply as food. Names like Lion’s Mane, Reishi, Cordyceps, and Chaga were suddenly part of a vocabulary I barely knew.

Then came the next layer: powder versus extract, fruiting body versus mycelium, beta-glucans, extract ratios, capsules, tinctures.

I had entered completely unfamiliar territory.

At that point, AI was still mostly a better starting point than a search engine. It helped me discover terminology, adjacent concepts, possible sources, and questions I did not know enough to ask five minutes earlier.

Useful, but still fairly conventional.

That changed later.

There was no single source of truth

One of the first surprises was how difficult it was to get a clean answer to even basic questions.

The information was scattered across supplier websites, technical documents, laboratories, regulations, authorities, and people working in different parts of the industry. One source might explain the product, another the testing, another the import process, while none of them necessarily answered the whole question.

Even people working in the industry often had a clear view of their own part rather than the entire chain.

Coming from software, I kept looking for something that resembled a source of truth: documentation, a specification, an owner of the problem.

Instead, I found fragments.

AI was useful because it helped me orient myself inside those fragments. It could unpack unfamiliar terminology, suggest which kind of source might answer a question, compare explanations, and flag when two pieces of information did not quite line up.

But an AI summary did not make the underlying information authoritative.

That distinction quickly changed how I researched.

I stopped asking only, “What is the answer?”

The more useful question became:

What do I know, what is still unclear, and who or what can actually confirm it?

Quite often, the answer was: ask the supplier.

The first useful supplier questions were basic

Before worrying about extraction methods, detailed regulation, or technical documentation, I had a more immediate concern:

Are these people legitimate, and do they actually know what they are doing?

My first questions were not sophisticated. I wanted to know whether they had worked with other brands, whether their products had already been sold in Switzerland or the wider DACH market, what new clients usually started with, how products were stored, and whether they could actually ship to Switzerland.

Looking back, those questions seem obvious.

At the time, they were how I learned the shape of the problem.

It reminded me of requirements discovery in software. A client rarely arrives with a perfectly specified problem. You ask questions until something vague becomes concrete enough to work with.

The same thing was happening here.

I had started with: adaptogens might be interesting.

Talking to suppliers forced that vague thought into something testable.

And then reality introduced constraints.

A small acronym changed the whole system

Some conversations went nowhere.

Some suppliers were clearly set up for established companies rather than someone trying to understand what a small-scale test might involve.

Some minimum order quantities were much larger than I expected.

And suddenly I had a new acronym to care about:

MOQ stands for minimum order quantity.

At first, MOQ sounded like a purchasing detail.

It wasn’t.

A larger MOQ meant more cash tied up in stock. More stock meant more storage. More products multiplied that again. Packaging, shipping, customs, and risk all moved with it.

One supplier constraint was suddenly affecting half the system.

That part felt familiar.

In software, one dependency can quietly affect six other things you thought were unrelated. Here, the dependencies were physical and financial rather than technical.

That was when my background started helping in a different way.

Instead of looking at each question on its own, I started asking:

What does this change downstream?

That became one of the most useful questions in the whole exercise.

AI stopped being a search tool and became a sparring partner

The biggest change came once I had material of my own.

Supplier replies. Quotes. Specifications. Product documents. Notes. Conflicting answers. Questions that seemed clear on Monday and somehow looked less intelligent by Thursday.

Now I was no longer asking AI to explain an industry in the abstract.

I could put real material in front of it and say: challenge this with me.

What does this document actually say? What am I assuming? Does this reply answer the question I asked? What is missing? Which uncertainty matters now, and which one can wait?

That felt very different from search.

Working solo on an unfamiliar topic, I did not have a colleague sitting next to me to ask, “Are you sure that’s what the supplier meant?” or “Why are you spending two hours on that if it doesn’t change the next decision?”

AI started filling part of that gap.

Not as an expert. More like a sparring partner.

I could push an idea at it, ask it to find holes, compare versions, challenge an assumption, or help me prepare the next question before I went back to someone who actually owned the answer.

That is where it became genuinely valuable to me.

A document existing does not mean it proves what you think it proves

Technical documentation became one of the clearest examples.

Initially, if a supplier sent a Certificate of Analysis, my reaction was roughly:

Good. There is a COA.

Then I learned that the more useful question was:

What exactly does this document prove?

A product specification is not necessarily a batch-specific laboratory result. A supplier declaration is not the same thing as raw test data. “Complies with EU legislation” is not the same thing as showing the measured values behind that statement.

AI helped me turn a vague reaction, this document looks reassuring, into a more disciplined review: what does it cover, is it batch-specific, and what remains unanswered?

That change in questioning mattered more than the summary itself.

AI could help me interrogate the evidence.

It could not turn missing evidence into evidence.

That became an important rule.

Regulation taught me to separate answers from confidence

Swiss food regulation added another kind of complexity.

I kept expecting to find one authoritative page that would tell me exactly what to do.

Instead, I found federal information, cantonal responsibilities, EU material, supplier interpretations, laboratory advice, and product-specific details that did not always fit neatly together.

Novel Food was one example.

A question that sounded simple, “Can this mushroom product be sold in Switzerland?”, quickly became more specific: which mushroom, which part, what kind of extract, how it was produced, how it would be consumed, and what evidence existed around its previous use.

Again, the useful habit was not getting AI to give me a confident answer.

It was using AI to break the question down until I could see what needed evidence and where that evidence should come from.

I started mentally classifying information as official text, supplier statement, laboratory result, interpretation, assumption, or open question.

That reduced a lot of false certainty.

And it reinforced something I think matters far beyond this particular topic:

A confident synthesis is still not confirmation.

My to-do list stopped being a list

By then, my notes had expanded into products, suppliers, packaging, regulation, shipping, costs, testing, and marketing.

Each topic could easily become its own rabbit hole.

I know this tendency from software too. Give me a new API and I can spend days understanding every detail before integrating the one endpoint the project actually needs.

Sometimes that depth is useful.

Sometimes it is procrastination wearing technical clothes.

AI became useful here as a way to keep me honest.

Instead of asking, “What else should I research?”, I started asking, “What decision is blocked right now?”

If the next step depended on a supplier answer, reading ten more articles was not helping. If packaging depended on choosing a product format first, I could stop thinking about packaging. If a regulatory detail only mattered later, it could stay later.

My to-do list gradually became a dependency map.

That was probably the moment when the whole exercise felt most familiar.

Not because it looked like software.

Because it looked like problem-solving.

Cost modelling made the dependencies visible

The financial side reinforced the same lesson.

At first, the calculation seemed almost embarrassingly simple:

product cost versus selling price.

Then came shipping, customs, packaging, storage, recurring tools, possible testing, minimum orders, and inventory.

The question stopped being, “Is there margin on one pouch?”

It became:

How does the whole system behave?

What happens when one assumption changes? Which costs are one-off and which keep running? Which number actually has enough impact to change the decision?

A spreadsheet could calculate the numbers.

AI was more useful as the thing I could challenge the model with.

What am I forgetting? Which assumption is carrying too much weight? If this cost changes, what else should I revisit?

Again, less “do the work for me” and more “help me think through the work I’m doing.”

That distinction became increasingly important.

Being a beginner again at 47

The technical learning was only part of the experience.

The other part was ego.

At 47, after years of professional experience, being a complete beginner again is uncomfortable.

In software, I generally know how to orient myself. I know what a useful technical question looks like. I know when documentation feels incomplete. I know roughly what I do not know.

Here, I initially had none of that.

Sometimes a supplier answer made me realize my question had been badly framed. Sometimes a new term invalidated an assumption I had carried for days, even worse, for weeks. Sometimes I spent far too long investigating something that did not matter yet.

And sometimes I hesitated to ask a basic question because I did not want to sound like a beginner.

Which was slightly ridiculous, because I was one.

Keeping that ego in check became part of the learning process.

I had to get comfortable saying:

I don’t understand this yet. What am I missing?

There is something strangely refreshing about that.

Experience is useful, but it can also create pressure to always look experienced. Starting again in an unfamiliar field reminded me that curiosity is often more useful than pretending to know.

The software skills were there, but AI changed how I used them

Looking back, my software background helped, but not because food products resemble software.

They don’t.

What transferred was the way of thinking: break a large problem into smaller ones, follow dependencies, read documentation critically, separate facts from assumptions, test one variable at a time, and know when more research will not unblock the next decision.

Those habits gave me a framework.

AI gave me something I did not normally have when working alone: a responsive partner I could use to challenge that framework in real time.

That combination mattered more than either one on its own.

My experience helped me decide how to approach the problem.

AI helped me iterate on that thinking faster.

And the final call still stayed with me.

What AI actually changed

There is a lot of talk about AI making people “10x” more productive.

I understand the appeal of the phrase.

But that is not how I experienced it.

AI did not make me ten people.

It shortened the learning loop.

I moved faster from:

I don’t know what this is.

to:

I know enough to see what I don’t understand.

to:

I know where the answer should come from.

to:

I have enough evidence to make the next decision.

Before AI, I probably would have spent much more time reading documentation, manually comparing sources, building notes, and repeatedly losing context. I have done exactly that on technical projects.

AI compressed part of that work.

But more importantly, it gave me a way to think out loud when I was working solo.

It became less like a machine I delegated tasks to and more like something I could reason with while still checking the sources, asking the people who actually knew, making the decision, and owning the consequences.

That distinction matters to me, especially in software.

Using AI should not mean caring less about the result because “the AI did it.”

If anything, the easier it becomes to produce an answer, the more important it is to understand what you are accepting and why.

The experiment is still just that

I still do not know where this exploration ultimately leads.

That is part of why I wanted to write about it now rather than wait for a neat ending.

A casual dinner conversation led to an AI query.

That query led to a supplier.

The supplier led to functional mushrooms.

Functional mushrooms led to terminology I did not understand, then to documents, regulation, logistics, costs, and a much larger system than I expected.

Somewhere along the way, the exercise stopped being mainly about mushrooms.

It became a test of how I approach the unknown.

At 47, I am still learning, still asking basic questions when I need to, and still discovering that skills built in one field can be useful somewhere completely different.

AI did not remove the uncertainty.

It gave me a better way to work through it.

And perhaps that is the lesson I will carry back into whatever problem comes next:

AI is most useful to me not when it gives me the answer, but when it helps me understand which question is worth answering next.

Note

This article describes a personal learning exercise. It is not legal, regulatory, tax, customs, or food-safety advice. ;)