AI ENGINEER | Fashion Designer | Sound Engineer | Arsenal Fan | Dataguy @accionmfb
Joined August 2019
- Tweets8.7K
- Following1.3K
- Followers2.1K
- Likes103K
Pinned Tweet
I was in class last week. One of my students raised their hand mid-lecture and asked something that stopped me for a second.
"Why is every AI tool built on Python? C++ is faster. Rust is faster. Even Java is faster. So why Python?"
Honestly it’s a fair question. And the answer reveals something really interesting about how the AI industry actually works.
Let me explain this properly. 🧵
Joseph Pajos retweeted
A small reminder for every engineer:
You don’t have to know everything.
You just need to know how to find the answer, test it and learn from what happens next.
That’s real engineering.
Joseph Pajos retweeted
Should I build one big agent or several small ones?
It's one of the most common questions in agent design, and the answer is usually: start with one.
Here's when multiple agents actually make sense 🧵
Joseph Pajos retweeted
🚨Arteta on his reaction to Max Dowman during the game:
'We spoke about it before the game. You have to understand the context. We’re not in Disneyland, we’re in the Premier League.'
Joseph Pajos retweeted
Did you know?
The hardest bugs aren’t always in the code.
Sometimes, the code is right.
The assumptions are wrong.
Joseph Pajos retweeted
AI term of the day: guardrails
Guardrails are the rules and checks around an AI system that stop it from doing or saying things it shouldn't.
They work at three points:
Input: block off-topic requests and hide sensitive data before the model sees it.
Output: check the answer before anyone sees it.
Actions: limit what an agent can do, and require a human to approve anything risky.
Example: a bank's AI can explain loan products, but it can't approve a loan or reveal another customer's details.
The model is the engine. Guardrails are the brakes.
AI term of the day: guardrails
Guardrails are the rules and checks around an AI system that stop it from doing or saying things it shouldn't.
They work at three points:
Input: block off-topic requests and hide sensitive data before the model sees it.
Output: check the answer before anyone sees it.
Actions: limit what an agent can do, and require a human to approve anything risky.
Example: a bank's AI can explain loan products, but it can't approve a loan or reveal another customer's details.
The model is the engine. Guardrails are the brakes.
Congrats Eureka.
Eureka Studios is now part of NVIDIA Inception. 💚
A month ago, Danfo Run was a game about Lagos traffic. Now we’re a studio building original games.
This one means a lot.
#NVIDIAInception
Joseph Pajos retweeted
Eureka Studios is now part of NVIDIA Inception. 💚
A month ago, Danfo Run was a game about Lagos traffic. Now we’re a studio building original games.
This one means a lot.
#NVIDIAInception
Should I build one big agent or several small ones?
It's one of the most common questions in agent design, and the answer is usually: start with one.
Here's when multiple agents actually make sense 🧵
Rules if you do go multi-agent:
Prove a single agent can't do the job first.
Give each agent one clear job.
Pass structured outputs between agents, not long paragraphs.
Keep a human approval step for decisions that matter.
Joseph Pajos retweeted
A junior engineer almost made a production outage worse by trying to fix it too quickly.
The application was failing.
He restarted the pods.
Increased the replicas.
Changed the configuration.
Nothing worked.
Then a senior engineer asked:
“What changed before the issue started?”
They checked the deployment history.
A new environment variable had been added with the wrong value.
One small question saved hours of guessing.
Lesson: Before changing the system, understand what changed.
Sometimes the best troubleshooting tool is the right question.
Joseph Pajos retweeted
Schema-on-write vs schema-on-read: the difference, in plain words
Both are about when you decide what your data should look like: before you store it, or when you use it.
Schema-on-write
You define the structure first: the columns, the types, the rules. Data is checked as it's saved, and anything that doesn't fit is rejected.
This is how traditional databases and data warehouses work.
Example: a bank's transactions table. Every row must have an account number, an amount and a date, or it doesn't go in.
Schema-on-read
You store the data as it arrives, raw. The structure is applied later, when someone queries it.
This is how data lakes work.
Example: a mobile banking app's raw activity logs. Every tap, login and error is saved as it comes, and analysts decide later which fields they need.
Look at the image: with schema-on-write, the schema is applied once, before the data is written. With schema-on-read, it's applied again for every analysis.
The trade-off:
Schema-on-write: clean, consistent and fast to query, but rigid. A new field means changing the table first.
Schema-on-read: flexible and quick to collect, but every query does the cleaning work. Without discipline, a data lake turns into a data swamp.
Many modern teams use both: raw data lands in a lake, then the important parts are cleaned into structured tables.
Easy way to remember it:
Schema-on-write: clean it before you store it.
Schema-on-read: store it now, clean it when you use it.
