The first guest invites my system wrote for the firm’s podcast went out in late July 2026. I sent them by hand. The first reply was a no.
I am a business student at the University of Miami, working toward a BBA in entrepreneurship with a minor in business law. Since May 2026, I have built AI systems part-time at EG Capital, a finance firm, and the first one went into use in June 2026. If another business student asked me how to start, this is what I would tell them.
Start with a real task
Many people start by picking an AI tool and then looking for something to do with it. I think that is backwards. Start with a task someone already does that takes too long. One of mine was finding and inviting guests for the firm’s podcast. That meant researching each person, checking they fit, finding an address that really is theirs, and writing a note worth answering.
A real task tells you what good looks like. It also gives you someone who can tell you, honestly, whether your system helped. A no is still an answer, and it is more than a demo on your laptop will ever get.
Pick something small enough to finish. The outreach system did one task, and it got used. A system that does one task well teaches you more than a big one that never leaves your laptop, and you can add the next task once the first one works.
Write the rules down
Decide how the task is supposed to be done, and write it down, including what should never happen. For outreach, my rules include never writing to a shared inbox, never sending to an address I haven’t confirmed, and never repeating a person’s deal terms back to them.
Written rules are the business skill in this work. They are what the system follows and what a reviewer checks against.
Expect the checking to be the work
A finished batch of drafts is not a batch you can send. The first time I checked one against its sources, most of it could not go out. I wrote about that batch in Why a person checks every change before it ships.
So decide where a person reviews the work, and what they look at, before you build the part that writes.
Learn enough of the plumbing
You don’t need a computer science degree, but you do need to learn some of how software works. I build with Claude through Claude Code, and I review every change. The systems run on Python and SQLite, and Playwright and Lighthouse test the portal and websites in a real browser.
In my view, the fastest way to learn a tool is to need it. A real task gives every lesson a reason, and a lesson with a reason is easier to keep.
Get a second reader
I also built a team system for my own work. It builds a team of AI experts for each problem, and a fresh reviewer checks the work before I decide. The idea behind it is old: the person who wrote something is the worst person to proofread it. That holds for AI as much as for people.
Be honest about the limits
It is tempting to make AI sound like magic. Don’t. A study of consultants at Boston Consulting Group found that AI made them faster and better on tasks within its reach, and worse on a task just outside it. I wrote about where that line fell for me in Where AI helps at a finance firm, and where it doesn’t.
The people you work with will trust your systems more if you tell them plainly where the limits are. In finance especially, being trusted counts for more than being impressive.
Your edge as a business student
Engineers will usually know more about the code. What a business student brings is knowing what the work is for: who reads the email, what a wrong one would cost, and who should sign off before it goes out. Those are business questions, and a business education trains you to ask them. AI keeps making building easier. Knowing what is worth building, and where a person has to check it, is the part that stays valuable.
Next post What building this site taught me about working with AI All posts