When I joined TetriXX AI in July, I thought I knew what an AI internship would look like: data, models, maybe some training runs. Four months later, I have worked on two very different projects. The first was sirius, our weekly freight cost index. The second is Ask freya, the assistant inside our freight audit platform.
Neither turned out the way I expected, and both left me with more questions than answers. Questions about where the real work in data science sits, about what an engineer does when an AI writes most of the code, and about where progress in AI actually comes from. This post is about those questions.
The hard part of data science often comes before the analysis
sirius measures what it costs to move freight, lane by lane, every week. To do that, it reads dozens of public market signals: container spot rates, fuel and bunker prices, diesel at the pump, traffic through ports and maritime chokepoints, macroeconomic series. Each one tells a small part of the story of world trade.
What I did not expect is how much of the science lives before the analysis. Every source has its own rhythm. Some publish daily, others weekly or monthly, sometimes weeks late. Some are clean files. Others are only published in formats that take real work to turn into a clean series. A source can change its format overnight, stop publishing without warning, or keep publishing a value that has quietly stopped moving. The collectors that fail loudly get fixed quickly; the ones that keep writing a stale number can go unnoticed for weeks.
So a large part of my work there was about making the data trustworthy over time: knowing where each value came from, noticing when a signal goes silent, and learning, from each signal's own history, what a normal value looks like so that an abnormal one stands out. It is less visible than a model, but every model downstream depends on it.
One episode taught me this better than any rule. Every month, a group of air cargo signals was flagged as down, even though nothing was broken. At first it looked like a failure somewhere in the collection. It turned out that these statistics are published several weeks after the month they describe, sometimes nearly two months, and that the check compared their age with the interval between publications without allowing for that delay. The alarm was misreading how the data is produced. Fixing it meant measuring each source's real publication delay and letting the check take it into account.
I found it a very interesting project. It is a real product, published every week and read by people making freight decisions. It forced me to understand the economics behind each number, not just its format: why a bunker price moves before a container rate, or why a chokepoint disruption shows up in invoices weeks later. And it taught me something no course had: that in data science, the difficulty is often less in analysing the data than in accessing it, processing it, and keeping it correct month after month.
freya got more reliable when she stopped typing her own numbers
On Ask freya, one feature changed how I think about AI more than anything else.
freya could already answer questions about a client's invoices, but only in sentences. I built a way for her to answer with tables, KPI cards and charts instead. The constraint was that freya should never type the numbers in those views herself. She asks for a view of data the platform has already returned, and the system builds it and checks that every figure really comes from that data. If something does not match, the view goes back to her with the reason, and she corrects it.
I expected nicer answers, and was surprised to see freya become more accurate overall. In our evaluations, with the same model from start to finish, answers became measurably more reliable as the checks and the instructions around the model improved. The errors that remained sat in the free text, the one part nothing was checking yet.
Another surprise came from reading evaluation answers myself. I had assumed that when the model went wrong, it was forgetting its rules. In most cases it was following other instructions instead: older guidance, written before views existed, that told it some lists could not be shown, or gave it sentence templates it then copied word for word under a table that already said the same thing. The model was being faithful to everything in its context, including what had gone out of date, and cleaning up that guidance did more than any new rule I could have added.
The model itself had not changed, only what surrounded it, and that raised a question I have not been able to put down since.
What does an engineer do when an AI writes the code?
I wrote very little of my code by hand these past few months. Claude Code, the coding agent we use every day, did most of the typing, and every pull request I open is reviewed by a more experienced engineer before it merges.
My time went into deciding what to build and what not to build, defining what "correct" means for a given feature, designing tests that measure it, and reading results one by one. When producing code becomes cheap, judging it and explaining it to the team become the skills that matter.
That shift only works in a certain kind of environment, and TetriXX AI is built for it. The code behind our agents and our platform is shared across the team and organised the same way, so I could follow a question from freya's chat window down to the logic behind the answer in an afternoon. And interns are given real ownership. For freya's views, I was trusted with building the feature, evaluating it, and defending my choices to our tech lead with numbers. That is a lot of trust, and it is the main reason I learned as much as I did.
It also raises a question I take seriously as someone at the start of a career. If engineers learn judgment by writing a lot of code, and agents now write most of it, how do people like me build that judgment? Reviewing code and reading failures teach some of it; the rest is something the profession will have to work out.
Where does progress in AI really come from?
Most of what I read about AI, in research papers and in the press, focuses on the models themselves: more parameters, better benchmarks, longer context. That progress is real, and every product I worked on benefits from it.
But my experience with freya made me wonder whether that is the whole story. Inside a product, what matters most is how often the model is right about this client's invoices, this week. That seems to depend a lot on things that are not the model: what it can see, what it is allowed to say, how its output is checked, and what it is told when it gets something wrong. Even the coding agent I use every day is a model wrapped in a carefully designed set of tools and rules.
Better models may make some of this scaffolding unnecessary, and the balance will likely differ from one problem to the next. Either way, the design of the system around a model is engineering work, done by people, and it deserves as much attention as the model itself.
Four months in
I came to TetriXX AI expecting to learn about models. I now have a better sense of everything that surrounds them: the data that feeds them, the checks that keep them honest, and the people who decide what they should and should not do.
I do not have firm answers to the questions in this post. Four months ago, I would not have known to ask them.
