The Path to AI Engineer Nobody Tells You About (From LATAM)
I have never taken a formal AI course. My first LLM integration serves 236 users daily. This is what the path actually looks like.
The Trap Nobody Warns You About
You finish Andrew Ng's course. You understand transformers. You can explain attention mechanisms at a dinner party. You build a sentiment classifier on the movie review dataset. You feel like an AI engineer.
Then you apply for jobs. They want "production AI experience."
You look at their codebase. It's nothing like the tutorials. There are retry loops. There are rate limits. There are three different error states you never considered. There's a database call that sometimes takes 8 seconds and sometimes times out. There's a Slack alert at 3 AM because the API response format changed slightly.
The gap between "make this work in Jupyter" and "make this work when real money depends on it" is not a small step. It's a chasm. Most people get stuck in it, endlessly tweaking portfolios that nobody will ever use.
I was stuck there too.
What Actually Changed Everything
I stopped building for hypothetical users. I built for one real person with one real problem.
A friend's marketing agency was drowning in email summaries. They had a client sending 40-60 emails daily, and someone had to read each one and write a 2-line summary. It took 3 hours a day. The client wouldn't pay more for it. It was just eating their margin.
I said: "I can automate that."
That was it. No portfolio project. No "let me learn more first." Just: there's a problem, someone loses money if I don't solve it, and I have to make it work.
That constraint changed everything about how I built.
Tutorial Code vs. Production Code
Here's what I learned in the first 48 hours:
Tutorial code:
import openai
response = openai.ChatCompletion.create(
model="gpt-4",
messages=[{"role": "user", "content": email_text}]
)
summary = response.choices[0].message.content
print(summary)
Production code:
import openrouter
import logging
from tenacity import retry, stop_after_attempt, wait_exponential
import json
logger = logging.getLogger(__name__)
@retry(
stop=stop_after_attempt(3),
wait=wait_exponential(multiplier=1, min=2, max=10)
)
async def summarize_email(email_text: str, user_id: str) -> dict:
"""
Summarize email with production safeguards.
Returns structured response with metadata.
"""
if not email_text or len(email_text) > 50000:
logger.warning(f"Invalid email length for user {user_id}")
return {
"status": "error",
"reason": "invalid_input",
"summary": None
}
try:
response = await openrouter.AsyncOpenRouter(
api_key=os.getenv("OPENROUTER_KEY")
).create(
model="anthropic/claude-3-5-sonnet",
messages=[
{
"role": "system",
"content": "Summarize this email in 1-2 sentences. Be specific about action items."
},
{"role": "user", "content": email_text}
],
temperature=0.3,
max_tokens=150,
timeout=15
)
summary = response.choices[0].message.content.strip()
if len(summary) < 10:
logger.warning(f"Suspiciously short summary for user {user_id}")
return {
"status": "warning",
"reason": "short_output",
"summary": summary
}
logger.info(f"Successfully summarized email for user {user_id}")
return {
"status": "success",
"summary": summary,
"tokens_used": response.usage.prompt_tokens + response.usage.completion_tokens
}
except openrouter.RateLimitError:
logger.error(f"Rate limited for user {user_id}")
raise
except openrouter.APIError as e:
logger.error(f"API error for user {user_id}: {str(e)}")
return {
"status": "error",
"reason": "api_failure",
"summary": None,
"retry_after": 300
}
except asyncio.TimeoutError:
logger.error(f"Timeout for user {user_id}")
return {
"status": "error",
"reason": "timeout",
"summary": None
}
The second version is 10x longer. It's also the only one that doesn't wake you up at 3 AM.
I chose OpenRouter because:
- I could switch models without rewriting code
- Better rate limiting behavior than direct API calls
- Cheaper fallback options when Claude was expensive
- One API key instead of managing ten
This flexibility saved me when Claude had issues. I switched to GPT-4 for 6 hours. Users never noticed.
The Real Learning Curve
Week 1: Built the MVP. It worked for one email. My friend tested it. It broke on emails with attachments, forwarded threads, and HTML formatting.
Week 2: 10 users. That's when I learned about:
- Emails that are 200KB of quoted history
- Encoding issues with special characters
- What happens when the LLM refuses to respond to certain content
- Rate limiting when multiple users hit at the same time
- Database queries that should be cached but weren't
Week 3: 50 users. The system was slow. I added caching. I batched requests. I learned that 90% of emails are duplicates of yesterday's emails, and summarizing the same thing twice is waste.
Week 4: 100+ users. Now it's a business. There's a Slack channel. People depend on it. I added monitoring. I set up alerts. I learned that one user's workflow was generating 500 emails a day and I needed to handle that gracefully.
Month 2: 236 users. The system is boring now. It just works. I spend 2 hours a week on maintenance.
That's the path. You don't become an AI engineer by studying. You become one by shipping something that breaks, then fixing it while real people wait.
Why LATAM Is Actually an Advantage
I'm in Buenos Aires. UTC-3. Most of my users are in the US (UTC-5 to UTC-8).
This is a feature, not a bug.
When it's 9 AM here, it's 4 AM in California. If something breaks at their morning, I can fix it while they sleep. I can push updates, monitor for issues, and have it stable before they wake up. That's competitive.
The model doesn't care where I am. Claude doesn't care if I'm in LATAM or Silicon Valley. The API response time is the same. But my cost of living is 60% lower. That means I can:
- Charge less and still make real money
- Spend more on infrastructure that's actually needed
- Take longer on projects that matter
- Turn down bad clients
The salary difference between "AI engineer in San Francisco" and "AI engineer in Buenos Aires" is real. But the skill difference is zero. And the opportunity difference is actually inverted—there's less competition here, and the market is hungry for this work.
I've turned down three job offers in the last six months because the consulting work pays better and I control my time.
The Uncomfortable Truth About Compensation
Here's what nobody tells you:
- AI engineer who completed a course: $80K-$120K
- AI engineer who deployed one production system: $200K-$300K
- AI engineer who maintains three production systems with real users: $350K+
That's not a typo. The jump isn't 20%. It's 300%.
Why? Because the first person can't be trusted with anything that matters. The second person has scars from production failures and knows how to prevent them. The third person is irreplaceable.
You can't fake this jump with a better portfolio or a certifications. You have to have actually done it.
Your Challenge This Week
Pick one real problem. Not hypothetical. Not "I could build this." Something where if it breaks, someone loses money or time or both.
It should be small enough to ship in a week. It should be something one person actually needs.
Build it. Make it work. Show me what you made.
Post it in the comments. Tell me:
- What problem did you solve?
- What broke first?
- What surprised you about production vs. tutorial?
The people who do this will be the ones who aren't stuck between the tutorial and the job in six months.
The model doesn't care where you are. It doesn't care if you have a degree. It only cares if your code works when someone depends on it.
That's the path.
What's the real problem you're going to build for this week?
Need an AI system for your business?
I'm Alessandro Trimarco, AI engineer behind a 6-module AI stack for a 14-location restaurant chain (236 users, ~88k EUR/month processed).
Email: alevibecoding@gmail.com | Portfolio | Case study
Top comments (0)