You don't start from zero: a farm school, a CrossFit box and AI agents
On Monday I gave a talk at IF Barbacena, during the Semana Nacional de Ciência e Tecnologia. Twenty-five years ago this campus was the EAFB, an agricultural school, and I was one of its students. I opened by asking the room to raise a hand if they felt late for something in their lives. I raised mine too. I came into software after more than fifteen years in a different career, and the talk was about what that career turned out to be worth.
Seven to five, every day, for three years
The EAFB was full-time. Classes from 7 a.m. to 5 p.m., lunch at school, and in the afternoon we went down to the fields for the practical part of the course. The work was ours to do: clearing brush, harvesting, feeding the animals, cleaning their pens, pulling tilapia out of the ponds. Every day, for three years, from the age of fifteen.
Nobody calls that a soft skill, but it is the first one I learned. You do what was agreed, including when it’s tiring, dirty or boring, because the animals don’t care how you feel about it. Three girls graduated in my class. Being the minority in a room started there, long before tech.
Teaching a movement is translation
Then came sport. Volleyball from thirteen to twenty, a degree in Physical Education at UFSJ, and sixteen years as a personal trainer and CrossFit coach — part of it in Ireland, Chile and Japan.
Ireland is where I learned English, and where the owner of the box welcomed me so completely that I practically lived in the gym for almost a month. Japan is where I felt most valued as a coach. I wasn’t from there, and people still recognized me on the street and called me sensei. The word carries a respect for teachers that I hadn’t felt anywhere else.
What that decade taught me was mostly one thing: explaining a complex movement to very different people, in three languages, and helping each of them understand their own body well enough to get the most out of it. Coaching is translation. You take something you understand deeply and find the version of it that this particular person, today, can actually use.
Questioned is fine. Doubted is something else
Back in Brazil, coaching came with a different experience. Being questioned is part of the job — a client who asks why is a client who’s paying attention. What wore me down was being doubted: having my programming second-guessed because someone with no training said something different on Instagram or YouTube. I eventually left coaching in Brazil. I didn’t give up on myself; I picked a different place to grow.
A spreadsheet, then an invitation
The way into tech wasn’t glamorous. I was working as an administrative assistant and started using Power BI to automate reports, mostly because I didn’t want to redo the same work twice. Without noticing, I was already solving problems with technology.
Then the pandemic left the market short of developers. The company I work for builds software for municipal governments, and it was already planning to migrate its systems to the web. The partners wanted someone they trusted to follow those projects. I enrolled in a degree in Systems Analysis and Development, and the original plan was for me to end up in project management. Over time we realized the plan itself had to change: the stack, the shape of the team, almost everything. I ended up in the middle of that change, on the technical side. I said yes before I felt ready. Nobody feels ready.
I didn’t do it alone, either. The partners bet on me while I was still arriving, and a senior developer who consults for the company became my technical reference. Having a senior woman as that reference made a difference I still think about.
The doubt didn’t stay behind in the gym, though. I joined a company where many people have spent more than a decade in support or development. They know the business rules and the production system better than anyone, and they had little experience with web development. I had the formal training and little experience in the field. Being questioned on technical decisions is normal. Being doubted over and over, on the same points, and having to prove myself again each time, is the part I named on stage — because I knew some of the women in that room would recognize it.
Where AI fits
The system we’re replacing is a desktop application with decades of business rules buried in its code, and the team doing it is small. AI is how a small team takes that on without pretending the risk away. The flow we built looks like this:
- Requirement. Someone who knows the business describes the need.
- PRD. AI helps separate business rules from technical decisions; the document becomes the acceptance criterion, so the business side validates before code exists, not after.
- Specification. Design, broken into small, ordered tasks.
- Tests first. What “done” means, written before the code.
- Agents execute. One task at a time, following the project’s rules — tenant isolation among them, written down as instructions the agents follow instead of something that lives in each developer’s memory.
- People review. The final decision is always human.
We’re also building agents that run on local machines instead of in the cloud. A code agent answers questions about the legacy system and cites the file and line its answer came from, so every answer can be checked. In our evaluation it got 8 of 16 questions right and invented zero citations — a modest score with an honest floor. A support assistant answers only from internal documentation, and a deterministic checker (plain code, no AI) blocks any answer that names something the retrieved documents don’t contain. We tested a bigger model expecting it to fix invented answers; it traded them for blocking far more correct ones. The safety net is in the process around the model, not in the model. I’ve written about the pieces of that process separately: isolation enforced by the database instead of the query in tenant-scoped RAG, and why some agent failures only show up across a conversation in an eval is not a test.
The question I’m still thinking about
Two moments from the Q&A stayed with me. The first was the blunt one: a developer who doesn’t learn this new way of building software — development assisted by AI — is going to find themselves outside the job market.
The second came from a professor. How can students use AI to become better developers, and not just people who produce code?
My honest answer was that my path doesn’t map onto theirs. I started using AI during my degree, but I was older, with years of life and work behind me, and I learned a great deal of development through it. For students starting at eighteen, I’d say the opposite of what they might expect: do the fundamentals with care and dedication. Not because AI can’t write the code — it can — but because the fundamentals are what let you understand and judge what it writes. AI writes code. It doesn’t know which problem is worth solving, and it can’t tell you whether its own answer is right.
What transferred
None of the skills that carried me here were technical when I learned them:
| Where I learned it | What I use it for now |
|---|---|
| The farm school | Finishing what was agreed, including the boring parts |
| Volleyball | The team over individual talent |
| Coaching | Explaining something complex to a junior developer, or a technical decision to the business |
| Three countries | Making myself understood in more than one way |
| Self-awareness | Leading each person as they are |
Explaining a CrossFit movement to a beginner is surprisingly close to walking a junior developer through why an agent’s suggestion is wrong. In both cases the hard part isn’t knowing the answer; it’s finding the version of it the other person can use.
At the end of the talk I went back to the raised hands. You don’t start from zero. You start from everything you’ve already lived.