About Me

Hi! I’m Gerson Azevedo, an AI Engineer from Brazil 🇧🇷. TL; DR:

1. The Kid Who Built Things: my (nerdy) adolescence building websites and playing with tech by sheer curiosity.

2. Earth Before SaaS: landed my first job building an e-commerce from scratch with PHP+MySQL; lived through a Big Rewrite,

3. From WordPress to Rails: built dozens — if not hundreds — of websites with pure HTML, WordPress or Joomla; figured out marketing funnels to get demand; learned Rails; joined a startup as co-founder.

4. Building at Scale: managing a team of developers, iOS and Android apps alongside Rails, 10K DAU, high concurrency on peak windows, learning performance from people like DHH, Nate Berkopec and Evan Phoenix; running an AI Olympics with over 700k registrations.

5. Pivoting to AI: code is being commoditized; the value is shifting from writing the code to deciding what to build and how to build it with AI; I commit to becoming an AI Engineer.

6. When AI Meets the Therapy Room: working for a startup that uses AI to provide support for people going through therapy who face emotional crises.

7. The Two-Fold Study Path: my plan for studying both the practical tooling (LLM Engineering) and the scientific foundations (statistics, neural networks, Transformers) of AI.

---

I. The Kid Who Built Things

It was 1998 when I first got in touch with the web. After class I would go to my school computer lab and browse websites about 12-year-old self’s favorite interests: Pokemon, Dragon Ball and rock bands. It didn’t take long for me to start writing my own websites.

My first creations were simple text-based websites written with the windows notepad and featuring embarrassing “under construction” images. Everything was static with the occasional marquee and blinking GIF in the background. But I kept on improving. Soon I could make cool ImageMaps, CGI forms and even the holy grail of hardship for me at the time, which was building an animated menu as a Java Applet.

Then came Macromedia Flash, which introduced me to a whole new world of keyframes, animations and logic. I studied ActionScript hard and landed my first freelancing gigs making Flash websites for local businesses. This taught me a lot about design, sales and dealing with clients — skills that would prove valuable in the future.

II. Earth Before SaaS

My first real job came in 2005 at a company based in Tecnopuc, the largest technology park in southern Brazil. I was hired to work as a developer on their new e-commerce software. The only issue was that there was no e-commerce software at all. They closed some deals but had no idea how to get this kind of software working. We were going to build an e-commerce from scratch. So me and two other recently hired young developers took the challenge. I was also responsible for visiting customers to better understand the business and see what was fundamental or not during the development phase, since that was something I was comfortable with from my previous experiences.

There was no separation between frontend and backend at the time. Everyone wrote everything. The first iteration was pure PHP with MySQL as the database — with the mandatory PHPMyAdmin attached. On the frontend we added some magic with script.aculo.us. The architecture was pure OOP that I had learned intuitively while writing ActionScript and was improving in my Algorithms classes in college.

The second iteration (yes, we naively approved a Big Rewrite) was a bet with CakePHP. This framework was the shiny new thing for me at the time. Also, it was my first contact with an architecture pattern (MVC). Finally every piece of code had it’s place and problems were a thing of the past. Innocence is not the absence of knowledge, but the absence of suspicion. Our old code had been used. Tested. Hard bugs were fixed with hours on Google Groups (or Experts Exchange). The amount of new bugs and complaints from customers that preferred “the previous version” made me learn that this kind of change is very risky from a business perspective.

Meanwhile, I learned how to create websites in WordPress (which is still very much around today) as a hobby and decided to try to sell some of my services to make a few extra bucks. At some point, I left my job and decided to go full-time freelancing.

III. From Wordpress to Rails

At first, I would print business cards and leave them around downtown. Soon I was getting customers by designing HTML/CSS/JS from scratch or personalizing WordPress themes from ThemeForest. Then I learned how to use Google Adwords effectively and created a marketing funnel that kept my demand flowing for quite a few years. I made dozens — if not over a hundred — pure HTML, WP and Joomla websites between 2007 and 2012.

By 2013 I was pretty sure that in a few years code would no longer be necessary to build websites for most small businesses. It was time to change. I had been experimenting with Git, PostgreSQL and Ruby on Rails since Rails 3 came out in 2010. Why not invest in that?

I had built websites for a few local tutors who ran prep courses and knew they needed software. So I offered a personalized application where they could handle courses, enrollments, attendances, payments, Google Calendar integration, everything. We would build it together, having meetings, talking to students and understanding what worked and what didn’t. At first, a single tutor made a deal with me. It was a lot more work than I expected, but the end result was awesome. He was really happy and promoted the software to a lot of his peers, which helped me close more deals and also eventually land a part-time job as a consultant at a local high-growth startup that was Rails based.

As time passed, my plan was to end my business and work full time for this new startup. O Fortuna, Velut Luna. I got an invitation to be a tech leader at a new edtech whose mission was to build education management software (similar to what I was building) for public school networks. In Brazil, 4 in 5 students study in a public school and the quality of the education they get is mediocre at best. It was my chance to work with something I enjoyed (code) and make a difference. So I took the plunge.

IV. Building at Scale

Building a Rails application for a single prep course is one thing. Building one that needs to handle the full K-12 spectrum — with all its edge cases — is another. Grading systems varied wildly: some schools used numeric grades, others used written evaluations, others used letter-based concepts. Some used them all. Course structures could be trimestral, semestral or annual. A single teacher might handle one subject or five. A user could be both a teacher and a school principal. The iOS and Android apps needed offline support. Every school had its own rules, and the software had to accommodate all of them. Complexity was everywhere.

Still, I was pretty confident in my OO skills and knowledge of the Rails ecosystem to pull this off. Leading a team of 4 developers (2 Rails + 2 iOS/Android) we kept on building, collecting feedback and improving the software. Everything was going well until the memory issues started. The slowdowns. The crashes. Background jobs that would just silently die. From a logic standpoint, everything looked fine. But there was a whole other layer of performance I hadn't touched yet.

With around 70 schools and 10k DAU, I had to learn about Little’s Law, profiling, database optimizations, average and p95 response times and the need to extract heavy endpoints into separate services to keep the application responsive.

Nate Berkopec’s material on Rails performance was a turning point for me. Learning from DHH, Mike Perham (Sidekiq), Sean Griffin (ActiveRecord), Evan Phoenix (Puma) and Eileen Uchitelle (Rails Core Team) on topics that directly impacted my application’s performance was invaluable.

In 2024, we started working with academic olympiads, which aligned well with our mission of bringing opportunities to public school students. The following year, we were responsible for the Brazilian stage of the IOAI (International Olympiad in Artificial Intelligence), which had around 700k registrations and 80k exam submissions. The performance challenges I had faced before paid off — we were able to properly size our infrastructure and delivered a smooth experience for all participants.

V. Pivoting to AI

It started slowly, with Copilot autocompleting in VSCode. Then came copying questions into ChatGPT and pasting the answers back. Fast forward to 2026 and we have assistants like Cursor and Claude Code that can write entire features from a prompt. What took months now can be built within days. Or hours. What a change.

It's true that AI doesn't do everything on its own. We're not yet at the point where it can understand requirements, architect systems, write code, test, deploy and fix bugs — all without human intervention (according to the researchers behind AI 2027, something like that is coming in 2030). Code isn't worthless now, but it's being commoditized. The value is shifting from writing the code to deciding what to build and how to build it with AI.

Then I decided to do something about it.

Considering my background, I could pivot to product or marketing. But technology itself was always what fascinated me. So, instead of running from AI, I decided to run toward it. Not just learning the tools, but understanding their ecosystem and how they work under the hood.

VI. When AI Meets the Therapy Room

Currently, I work as a AI engineer at a startup that uses AI to provide support for people going through therapy who face emotional crises. The users are real people going through real difficulties. This is not a playground. When a model misbehaves, someone in distress gets the wrong response.

It’s not enough to know how to make an API call. We have the challenge of coordinating agents to handle human escalation, manage sensitive conversations and ensure critical information reaches the right people safely. Learning how to orchestrate reliable and safe agents is a big part of the solution.

Just like I did with code 20 years ago, I feel the need to understand what's happening inside — how models make decisions, where they fail, so I can know how to build guardrails that actually work. Truth is, I'd be studying this regardless. The curiosity that made me build Pokémon websites at 12 is the same one pulling me toward AI now. The fact that I get to apply it in a context where it truly matters makes it all the more urgent.

VII. The Two-Fold Study Path

I've split my study plan into two parallel paths.

The first is to understand the technology. I call it the scientific path. Build a foundational understanding that allows me to understand scientific papers, architectures and make informed technical decisions. This means going back to the fundamentals — statistics, linear algebra, neural networks — and understand how Transformers and LLMs actually work. I studied calculus, linear algebra and statistics in college, so the foundation is there (though it needs to be dusted off).

Then there is the business path. My goal here is to be very effective solving business problems with AI. I’ll work to master the stack of LLM Engineering focusing on topics like APIs, RAG, agents, orchestration, fine-tuning, safety, evals, guardrails and observability. Twenty years of building web applications don't disappear. Understanding systems, debugging production issues and designing for scale still apply here.

I also plan to deepen my understanding of AI for Mental Health, which comes with very specific ethical and regulatory demands. This means studying responsible AI frameworks, understanding bias and safety in clinical contexts, and keeping up with the growing body of research on how AI interacts with therapy and emotional support.