Anna Kate Black

The problem

I had applied to about 30 roles and had 17 networking conversations going. Deadlines, replies and follow-ups were spread across Gmail threads, applicant portals and my own notes, and nothing tied them together.

What each run does, at noon and midnight

1. Email audit. Reads new recruiting mail and my sent mail, then updates where each application and conversation stands. A scheduling request is not logged as an interview until a confirmation arrives.
2. Role check. Rechecks each posting on the company's own careers site. A role is marked closed only after it is missing on two checks in a row.
3. People. Finds a few relevant contacts from public sources, and searches my Gmail first so it never suggests someone I already emailed.
4. Drafts. Writes replies and follow-ups inside the right Gmail thread, with a bracket wherever it needs a fact only I have.
5. Prep. Writes interview and call prep notes from the actual invite emails.
6. Report. Updates the hub page and emails me only when something new needs me.

Who decides what

When something breaks

• Save as it goes. Each stage writes its results as soon as it finishes, so a failure late in a run doesn't lose earlier work.
• Report each stage. The hub page shows whether email, roles, people, drafts and prep each finished, partly finished, failed or were skipped, and what may be out of date.
• No overlapping runs. A run lock stops two runs at once. A lock older than 50 minutes counts as abandoned, so one crashed run can't block the next.
• No overwriting my edits. Every write is pinned to the record's version. If I changed the record in the meantime, the database refuses the write and the run re-reads it first.
• Fall back. If it can't write to the hub at all, it still checks my email and says plainly that the hub wasn't updated.

How it got here

1. Started with a weekday 7 AM inbox triage that drafts replies and emails me a one-minute summary. It still runs.
2. Added three separate scheduled tasks for open roles, networking targets and my Gmail pipeline, all writing to one shared hub. Two of the three failed on their first run when they hit usage limits.
3. Rebuilt them as one cycle, which is when the run lock and the version check on every write went in.
4. Now it runs at noon and midnight every day.

My role and how I used AI

I built it in conversation with Claude. I described the workflow and the rules; Claude wrote the run instructions and built the hub page, which runs as Claude scheduled tasks with my Gmail and a contact database connected. When a run failed or did something I didn't want, I changed the rules. I use it every day.

The problem

Students at UGA rent formal dresses from student-run Instagram accounts, and I had 221 rental posts saved. Picking one means checking size, price, availability on the date, whether it fits the occasion and season, and whether I like it. None of that is structured. It is free text, written by a different person every time, in a caption that was never meant to be searched.

It grew out of research I wrote up in May on why fashion search fails: shoppers search by occasion and feeling, like "something for graduation week," while listings read like spec sheets. In a nine-product test, GPT-4o inferred occasion and style from product details, while GPT-4o-mini and Gemini Flash returned flat descriptions. After Locker Lens, I also wanted a project that went deeper than calling one API, and that I understood well enough to explain every design decision.

What I built

A pipeline that reads my own Instagram data export, with no login and no scraping. It pulls facts out of captions with tested rules, removes dresses that fail hard limits like size, price and date, and ranks the rest on six scores you can trace. Of 221 saved posts, 157 were dresses and 149 made it into the final ranking.

Then the experiment: Claude's vision model reads the photos to fill in details captions leave out, like neckline, silhouette and color, and the exact same ranker runs again.

Decisions that shaped it

• Rules for simple facts. My parser read "$50" but missed "50$", so a listing that clearly stated its price looked like it had none. The fix was a rule and a test, which is cheaper and more predictable than asking a model every time.
• The caption wins on what the renter stated: size, price and dates. Vision can only fill a blank, and only above 0.55 confidence. When the two disagree, the conflict is recorded instead of silently resolved.
• Unknown stays unknown. Scoring a missing neckline as zero would rank how chatty a caption is, not how well the dress fits the occasion.
• One difference between the two versions. Both use the same ranker, weights and filters, so any change comes from the photos.
• No Instagram credentials, ever. Real photos, captions, usernames and my labels stay on my computer and never go into the repository.

Status

It works today, on my laptop. It reads my Instagram export, pulls facts out of captions, filters and ranks dresses for an event, explains every score, and runs as a small local app where I type a request like "a Christmas cocktail dress, festive and sparkly" and get ranked cards back. The vision experiment ran live on the labeled dresses. Not built yet: the database, image embeddings, taste learned from my saved items, and any hosted version anyone else can use.

Result

The first live run sent the photos of my labeled dresses to Claude's vision model. All 7 reachable photos came back, with 91% of the requested visual fields filled. The top-10 score (nDCG@10) was 0 in both versions, because none of the dresses graded as good matches made the top 10 either way. The two good matches the system could reach moved from rank 90 to 35 and from rank 89 to 44, and 5 of the 6 labeled dresses I could compare moved up. Only 7 of 157 dresses were enriched, so this shows the photos moved the right items. It does not show the system got better overall.

My role and how I used AI

Claude wrote the code, and the commit history shows every step. I chose the problem and the question, set the privacy rules, ran it on my own data, caught the price bug in my own listings, and decided what the result can and can't claim. I picked the 8 real dresses used as the test set; Claude assigned each one's grade for each event. I built the slides for my AI research group at UGA.

The problem

I had 100 days before starting on BRG's turnaround and restructuring team. A UGA student who had done the same internship told me the hard part wasn't the news. It was the legal vocabulary, the jargon, and doing restructuring work in Excel and PowerPoint without hesitating. A news digest wouldn't teach that, so I wanted a tutor that used each day's news to teach the job.

What it did each morning

1. At 6:00 AM, Windows Task Scheduler woke my laptop and ran the Python script.
2. Serper's search API pulled the top three results for Chapter 11 and distressed-debt news.
3. Claude, prompted as a senior restructuring mentor, wrote a six-part lesson: a summary, why the news matters, an interview question with a worked answer, one vocabulary term, an Excel exercise and a PowerPoint exercise.
4. Resend emailed the lesson to me.
5. The script saved the new term to a flashcard file and logged what I had covered for the next day.

Decisions I made

• A search API instead of a scraper. News sites block scrapers; Serper returns results as structured data.
• Memory so it didn't repeat itself. Before each call, the script read a learning log and told Claude what I already knew and to make the lesson slightly harder.
• Flashcards without copying. The prompt asked Claude to end with a hidden "term | definition" line, which the script split off before sending and added to a spreadsheet file.
• Reliability over length. My first version asked for 25,000 tokens per email, and requests that long ran past the API's time limit and crashed. I cut it to 8,000 so it would finish every morning.
• Keys out of the code and no server bill. API keys lived in a local file, and the laptop's scheduler replaced a paid cloud server.

My role and how I used AI

I built it in Python with Claude's help, and Claude wrote each day's lesson. I spent about 30 minutes each morning on the lesson and its exercises, including building a debt waterfall from mock numbers.