My Summer Inside Eclipse

By Yi Cui

Before I joined JGM Innovation this summer, I had a certain picture in my head of what a nonprofit focused on improving education in Peru would look like. Spreadsheets, maybe. Email newsletters. Not much in the way of "advanced tech." I was wrong almost immediately. JGM has been quietly building Eclipse, an internal AI chatbot that automates a surprising amount of the organization's daily work, and I spent my internship helping build it out.

Over the summer, I worked on three main projects inside Eclipse. The first was a safety layer, a system that screens what users send to and receive from the chatbot, so Eclipse stays reliable and on brand no matter what gets typed into it. The second was a donor email automation skill: a feature that reads a donor's information and generates a personalized thank you email and PDF receipt, cutting down what used to be manual, repetitive work for the team. The third, and the one I ended up going deepest on, was a Google Ads keyword advisor: a tool that reads JGM's Google Ad Grants account data and tells the team which keywords are working, which should be cut, and what to try next, all while respecting the strict rules that come with running a nonprofit ad grant. Building the keyword advisor was where I really learned how to turn a vague, high-level ask ("help us manage our ads better") into something concrete, tested, and actually useful to the people who'd use it. That vagueness was itself a lesson. Instead of guessing at what our founder, Waldo, meant and hoping I'd land somewhere close, I learned to just text him and ask.

What helped me grow the most, though, wasn't the code. It was the weekly meetings.

Waldo was intense from day one. He told us early on that he wouldn't treat us like interns; he'd treat us like full-time employees, because our internship was short and he wanted us to walk away having actually built something real. At first, that framing was intimidating. I remember my first demo: my hands were basically shaking. School had trained me to be good at exams and at solving problems on paper, not at standing in front of someone and explaining, out loud, what I built and why. I'd gotten used to putting projects on my resume that I'd mostly "vibe coded" my way through. I could get them working, but I couldn't always tell you why they worked, or defend a design decision if someone pushed back on it.

Waldo's meetings didn't let me get away with that. Every week, I had to show a real, working demo of what I'd built, and he'd ask questions, real questions, the kind that expose whether you actually understand your own code or just got lucky. Some weeks I'd walk in with a list of technical improvements I was proud of, only for Waldo to point out that none of them were actually the priority, that I was polishing something that didn't matter yet while ignoring something that did. That was frustrating in the moment, but it's probably the single most useful thing I learned all summer: a product mindset. Before you improve a feature, you have to understand why it exists in the first place. Once I started asking "why are we building this?" before "how do I build this?", the features I shipped got noticeably better, and so did my ability to explain them.

By the end of the internship, the shaking hands version of me was gone. I could walk into a meeting, show real work, and hold a conversation about trade-offs I'd made, not because presenting stopped being nerve-wracking, but because I finally had enough understanding of my own projects to trust myself in the room. That's not something a class can teach you. It took a founder who cared enough to push, and a summer of standing up every week and doing it anyway.

I came into this internship expecting to write code for a nonprofit. I left having learned how to build a product, explain it, and defend it, and that's a version of engineering I didn't know I was missing.