Forem: Ava Barron

The story of how Alicia Keys accidentally got me a career in tech

Ava Barron — Mon, 30 Mar 2026 01:24:32 +0000

This is a submission for the 2026 WeCoded Challenge: Echoes of Experience

The story of how Alicia Keys accidentally got me a career in tech

Can you stand the rain?

That's what New Edition asked about love and life. I was listening to the song while reading about the WeCoded challenge, and it made me realize the rain in my own life shaped me more than sunny days. I knew this was the story I wanted to tell. The way I ended up in tech came from the most unlikely place: an Alicia Keys concert my mom took me to by accident, and the online community of Black and brown people I found because of it. This is how diversity, real diversity, the kind with no panel moderator and no walls got me into tech.

The Rain

I grew up in a small suburb in the south right by the Ohio River close enough to see the North, but raised on the South side of it, in a family that made no sense to anyone around me. My mom was Guyanese. My family is diverse. "Mix up" is how we called it. At home my kitchen smelled like chicken curry and roti and dhal while every other house around my block ran on Kraft mac and cheese from a microwaveable cup. I was too different from the world around me. I said "sangwich" instead of "sandwich" (Guyanese patois that I forced myself to fix after years of getting laughed at). I brought lychee for snack time and watched kids give me stares and call me weird.
I lived in a small town. Same kids. Everyone knew everyone (or thought they did) type energy. But still, in that world, there was no room for nuance. Everything was black and white. You were smart or dumb. You were from here or you weren't. You were either white or not, and if you weren't, people just filled in the rest for you from their worldview.

I actually still remember my first day of kindergarten and it wasn't because I was crying for my mom not to leave (but I did do that too). I remember sitting on a rainbow round carpet, the kind that was woven and had some fuzzy threads sticking out. A group of kids walked up and sat down next to me. They started rubbing my skin, asking each other, "is she dirty?" Then one turned to me and said "Ew, did you take a bath?"

In eighth grade, a girl I had been in Girl Scouts and on the basketball team with for years pulled me aside in the hallway and whispered, "are you... Black?" like she was diagnosing something. Like it was shameful. What shook me then and still does now is not the question itself. It was the tone. The serious way she was asking it, like it was some deep dark secret. Her discomfort. And it wasn't just her, it was basically everyone around me back then. I heard this stuff all the time.

Between those moments was a decade of being called the n-word, of "go back to your country" from most of the neighborhood kids. Being told that races should not mix and that brown people were "mud people." I don't even remember what else. That was the rain. It was constant, and it started before I could spell my own name.
But here is the thing about rain, people usually don't just stand in it. They get a raincoat, buy an umbrella, or they find shelter.

I found my people on the internet. And that community became my raincoat.

The Accidental Ticket

By the time I was twelve, I was already online. I had taught myself HTML by using Lisa Explains It All, for my Neopets profile. I built little websites on GeoCities.

But I was doing all of it alone. The internet gave me somewhere to go, but it didn't give me anyone to go with.

What changed that was a concert ticket my mom bought by mistake.
When I was thirteen, my mom heard me talking about Aaliyah, the R&B singer who had recently passed away. She saw concert tickets for this new artist named Alicia Keys and bought them, thinking they were the same person. They were not the same person, but my mom didn't know that, and I wasn't about to turn down a concert.

I still remember the day we drove all the way to Cincinnati to go to the Taft Theater, excited for my first concert ever. Friday night. We sat up in the balcony section, they had these old red velvet seats, and I remember watching someone carry a keyboard onto the stage before the show and thinking, "oh, is that going to be for Alicia Keys?" It wasn't. But I remember that small moment because I was already leaning forward, already pulled in, before a single note had been played. Something in me already knew.

Then she performed her album, Songs in A Minor, and I only knew "Fallin" before that night, but by the time the show was over I knew I had witnessed something much bigger than a concert. The way the whole show flowed like a theater production. The classical training underneath the soul. The rawness. Here was someone who didn't fit neatly into one box either, bridging worlds that people said didn't go together. I left that concert knowing I needed to find out everything about this world immediately.

The Room

I had been exploring the internet before that concert, but after that night I wasn't just exploring anymore. I was searching with purpose. More of whatever THAT was. More of that artistry, that story, that connection.

Then I found it, the Alicia Keys Message Board, and it became, without exaggeration, the most important community I had ever been part of during that time.

Not because of the music. Because of the people. First time I was in a room where diversity wasn't a concept anyone had to explain, it was just the room. I talked to everyone on there. We had organized live chatrooms on Yahoo Messenger and MSN, conversations that went on for hours.

I met Nafiesa, who was from Amsterdam, but originally Suriname, a country right next to Guyana. She was the first Caribbean girl I ever met online. I told her I wanted to visit Guyana one day, she said, "GIRL, WHY WOULD YOU WANNA GO THERE? You know there are snakes that can KILL you? It's all jungle!" and I laughed so hard because that was it. That was what I had been missing the whole time. Someone who understood the reference without a confused blank stare or asking me if I meant Ghana, who knew the culture, who could roast me and get me at the same time.

There were a lot of connections made there. Dee, a Black woman and IT professional who I looked up to, ran a thread where she told us all to post our report cards. If you had A's, she sent you real money in the mail to encourage Black and brown kids to be excellent. I made sure to post my report card each quarter. There was Alana from MD, always typing "BRB" because she was studying for her IB classes, a joyful nerd who made being smart feel normal instead of weird. There was Cinna from Jamaica, who kept getting banned from the board for starting all the craziest drama (and I kept showing her how to hide her IP and slip back in). There was Sabina from the UK, Nic from Germany, Steph from Belgium. People watched The L Word together weekly episode by episode in the forum threads, posting reaction images before reaction GIFs were even a real thing. People argued music theory and shared relationship problems and asked for homework help. It was the first place where everything I was, the food, the family, the in-between-ness wasn't a problem to solve. It was just who we were. That's what a diverse community actually does. It doesn't make you feel included. It makes you stop feeling like you ever needed to be.

That community didn't just give me somewhere to belong. It gave me people I wanted to show up for, and eventually, a reason to use what I knew to make things better for the people around me.

The Curriculum

People on the message board posted about their broken computers ALL the time. Someone would upload screenshots to Photobucket talking about how their desktop was covered in popup windows and write "HELP, my PC has a virus, what do I do!????" and I would be in those threads immediately. "PM me your AIM screen name," I would tell them. "Lemme check your startup programs. Open regedit. Open task manager. Let me Google this right quick." I was like 15, walking grown adults through virus removal step by step over AOL Instant Messenger, and I hadn't taken a computer class in my life yet. I learned because the people I cared about needed help. And every time I fixed something, I understood something new about how computers actually worked, from the inside out. It was fun. Not a curriculum. Just people, problems, and the curious need to figure it out.

That instinct kept showing up everywhere. In high school, a teacher assumed I was an ESL student because I was brown and never spoke in class. I used that assumption to slip out at lunch with the other ESL students and walk to the library, with my bootable Ubuntu CD, and use it for unfiltered internet access to my friends while everyone else ate in the cafeteria I had been avoiding for months.

It was always the same instinct. Nobody is giving this to me, so I'm going to figure it out myself. That's how I first learned networking, operating systems, troubleshooting, and Linux administration. Not from a class. From need. The degree came later. The instinct came first.

Still Playing on the Internet

That instinct never stopped. It just expanded.

The girl fixing computers over AIM from a music forum is the same engineer who builds production systems now. The girl helping friends evade bans is the same woman who eventually published machine learning research. The girl who booted Linux off a CD in a school library is the same one who still looks at every locked door and thinks, "okay, so how does this open?"

My GitHub profile says "Playing on the internet" I was kind of joking when I wrote it, but tbh it's probably the realest thing I've ever written as a bio. I've been online since I was like 11, and the play became the skill, and the skill became the career, and the career became the life.

None of it started in a classroom or a bootcamp or a lecture hall. It started because a community of people from the WORLD wide web made me feel like I belonged somewhere for the first time in my life. And when you belong somewhere, you build there. You contribute. You learn and grow and share.

That's how diversity changed my life. Not a program or a panel about representation. A message board full of Black and brown people from Chicago, Jamaica, Suriname, Germany, DC, and a small suburb in the south. People who never once made me feel like I was too much or not enough. They just needed someone who could fix their computer and chill with, and I wanted to help because they were my people. That was the whole pipeline.

Vibe with Code: Plan First, Build Second

Ava Barron — Sun, 29 Mar 2026 03:18:42 +0000

The most expensive mistake engineers make with AI isn't the code. It's skipping the plan.

Software engineering has never been about writing code first. It's about understanding the problem, exploring approaches, analyzing tradeoffs, then building. But when AI enters the workflow, all of that disappears. We collapse the process into one prompt, the AI fills in every blank on its own, and we call it productivity.

Rate limiting? The AI picks something. Auth strategy? It picks something. Pagination? It picks something.

Not necessarily what your system actually needs. But the code compiled, so it must be right, right?

Vibe coding works with structure

That structure is plan mode.

Engineers keep dming me asking how I build apps with AI that don't fall apart. I plan and use agentic teams that review each other's work. It's not one AI doing everything solo. It's a whole pipeline. This is how I get quality output without babysitting every line. This weekend, I decided I would take the time to walk through my actual process.

This is Part 1: the planning phase. The part most people skip, and the most expensive part to skip.

Plan mode is bringing your engineering discipline into the AI workflow. Same rigor as a design review or an architecture proposal, just applied to how you direct the AI. The tool changed. The engineering didn't.

The path: brain dump your idea → AI generates a full plan → you review it like a design doc → iterate until the architecture is tight. Same starting mess. Completely different result.

If you know spec-kit: GitHub's spec-kit automates this planning scaffold with /specify, /plan, and /tasks before implementation. This article shows what that discipline looks like under the hood and where your engineering judgment still decides what the gates check and what standards they enforce. If you're already using spec-kit, skip to Iterating on the plan

Start With the Brain Dump

Before you plan, brain dump. Everything in your head: features, vibes, who it's for, random research you found at 2am, all of it. No filter. The mess is the raw material.

What I actually typed into Claude Code, in plan mode so I could show the whole process:

That's it. Messy. Incomplete. "idk what else" is literally in there. And that's the point. You're not trying to be polished yet. You're getting the idea out of your head and into a format the AI can work with.

The key move: This happens in plan mode. You're not just brain dumping into a notes app. You're telling the AI "take this and map it out." Brain dump and plan request in one shot.

The Initial Plan Drops

The AI doesn't just say "cool app idea." It comes back with a full Technical Design Document, the kind of artifact a senior engineer hands you in an architecture review.

It started like this…

# Tech Stack
| Layer       | Choice             | Why                                                    |
|-------------|--------------------|--------------------------------------------------------|
| Backend     | Node.js + Fastify  | Native JSON Schema validation, fast, clean plugin model|
| ORM + DB    | Prisma + PostgreSQL| Type-safe, great migration UX                          |
| Frontend    | Next.js App Router | SSR for public pages, client-side for app shell        |
| Auth        | Clerk              | OAuth + magic links out of box                         |
| Charts      | Recharts           | Composable, works well in React.                       |

Plus a full file/folder structure, database schema with entity relationships, API endpoints, and an agentic build team. 4 agents across 3 phases:

What just happened: One prompt in plan mode > a full engineering spec. Tech stack, schema, APIs, build team, dependency graph. Without this step, the AI is making every decision for you. With it, you have something to review and update before a single line of code exists.

Stop

Now here's the part that matters more than anything else in this entire article.

After generating the TDD, the AI is ready to go. "Let's execute step 1." The plan is sitting right there. The momentum is pulling you forward. Every instinct you have is saying let's gooooo!

Do. Not. Touch. That. Enter. Key.

This is the moment. This is the whole game right here. The TDD looks impressive: tech stack tables, dependency graphs, four agents ready to build. It's giving senior architect energy. And that's exactly why you need to stop and read it!!!

The move: Copy the whole plan. Paste it into a Google Doc. Mark it up like it's a real design review. It is one. Do something. You're the engineering lead now. That TDD is a proposal, not a mandate. Read it like a HLD from a junior engineer. Respect the effort, but question every decision in it.

I read mine and caught something on the first pass, Clerk costs money. I'm just showing the process here. I want this free to build but still production safe.

Still in plan mode.

Tech stack decision changed before a single line of code was written. Say "yeah go" here and two days later you're ripping auth out of every route handler. Instead, one prompt. Zero code rewritten. Because there was no code yet. That's the whole point.

Call out your constraints early. Want everything free and open-source? Say that now. Already committed to Vercel or AWS? Tell the AI so the architecture accounts for it. Know you want Postgres over Mongo? Flag it. The earlier these constraints live in the plan, the less you refactor later.

Iterating on the plan

You don't review once and ship the plan. You iterate. Each pass applies a different engineering lens: cost, security, architecture, standards.

This is where your actual engineering knowledge is important. The AI gave you the ingredients and a recipe. Your job is to taste it before you serve it. Nobody's grandma ever followed a recipe without adjusting the seasoning first.

My plan went through 7 iterations before I let a single line of code get written.

It went like this…

1. The Auth Swap

I immediately caught the plan said to use Clerk. Clerk costs money. I wanted this to be a free build. Stayed in plan mode, asked the AI for alternatives, landed on Better Auth. Free, self-hosted, same OAuth and magic link support. One prompt. Zero code rewritten. Because there was no code yet.

2. Adding Gate Agents

The initial plan had 4 builder agents but no reviewers. It had phases but nothing between "build it" and "ship it."

I added review agents, CI, Security, UX and docs to run between each phase.

They run as blocking gates between build phases. Next phase doesn't start until they sign off. Think of it like requiring approvals on a PR before it merges, but automated into the build plan itself.

3. Give your plan a degree

If you already know the best practices for your stack, tell it exactly how you want to update the plan.

But if you're working in a stack where you have some gaps, feed it engineering books on the design. Best practices, books from authors of the language, data structures and algos, and systems design books on your stack.

I copied my architecture into a different chat and asked what books I should be following for a TypeScript web app with this structure. I got back with Effective TypeScript, Clean Architecture, Designing Data-Intensive Applications, and a few others.

Pasted those recommendations back into plan mode. Now the AI isn't following generic best practices. It's following specific books that apply to what you're building.

Now the plan has an engineering degree.

5. User Review Pauses

I added structured checkpoints after each build phase for me to test. I updated the plan again so that it also gives me a full tutorial on how to test the features it built after each phase. Now when the agentic team pauses and asks me to review, I'm not guessing what to check. The testing guide is right there for me to follow step by step.

6. Extracting the rules

At this phase the engs rules were embedded in the plan document. I originally pasted a contributing guide I made into the plan. Then I asked plan mode to extract it out of the planning doc and into the repo.

7. DRYing the Plan Itself

Last pass for now, I applied the same engineering principles to the plan that I apply to code. And actually you can even make this easier by just asking the plan to do this.

The Transformation

Here's what reviewing and iterating on the plan actually produces.

Remember it started as a messy brain dump, the "idk what else" prompt. Same app idea. But look at the difference between what the AI first handed me versus what came out after I actually engineered it.

Production Gaps

Before:

After:

Every single line in that "after" would have been a production bug or a 2am refactor. Missing indexes on a leaderboard query? That's a slow query that gets slower every day. No timezone strategy? Your streak breaks at midnight for every user not in your time zone. All caught before a single line of code existed.

Engineering Standards

Before:

(nothing tbh)

After:

One file. Single source of truth. Every agent follows it.

The plan went from zero engineering standards to a CONTRIBUTING.md backed by five books. Now it's building against a spec that would pass a real code review.

The Build Pipeline

Before: 4 agents across 3 phases. No reviewers. No gates. No standards. Build it. Ship it. Hope it works?

After: 12 builder agents + 4 gate reviewers (CI, Security, UX, Docs) across 4 phases with blocking gates. Every agent reads CONTRIBUTING.md first. User review pause after every gate with copy-paste testing guides.

Same starting point. Completely different destination. The brain dump didn't change. The engineering did. That's what happens when you treat the plan like a real design review instead of a formality to skip past.

Try It Tonight

Open your AI coding tool. Claude Code, Cursor, Copilot, whatever you use. Start a planning session. Dump your app idea. The messy version, the one with "idk" still in it. Add: "map this out E2E with an agentic team."

Read what comes back like an engineering lead. Copy it into a Google Doc and mark it up like it's a real design review, because it is one. When you read that plan, look for one thing first: the riskiest assumption. That's your first iteration. Question it, look for gaps, add books, etc.

Ask plan mode to review its own plan. Keep going until the plan is something you would stake production traffic on.

Or if brain-dumping isn't your style, write the TDD yourself first and hand it to the AI. "Here's my design doc. Build me an agentic team around this plan." Same destination, different starting point. The point is, have a real plan.

Up next: Your plan is done. Now we build. The next article covers speccing features collaboratively with the AI, the build → review → you check → iterate loop, and what "ship-ready" actually means when your whole team is AI agents.

Everything referenced in this article, from tools to books to research:

References

Tools

Claude Code — AI coding tool with plan mode
GitHub Spec Kit — Open-source toolkit for spec-driven development (/specify, /plan, /tasks)
Better Auth — Free, self-hosted authentication
Fastify — Fast Node.js web framework with native JSON Schema validation
Prisma — Type-safe ORM for Node.js and TypeScript
PgBouncer — PostgreSQL connection pooler
date-fns-tz — Timezone support for date-fns
Recharts — Composable charting library for React

Books Referenced

Effective TypeScript — Dan Vanderkam (O'Reilly, 2nd Edition)
Clean Architecture — Robert C. Martin
Designing Data-Intensive Applications — Martin Kleppmann (O'Reilly)
A Philosophy of Software Design — John Ousterhout (2nd Edition)
System Design Interview — Alex Xu (Volume 1 & 2)
Building Micro-Frontends — Luca Mezzalira (O'Reilly)

Research

Counting Blessings Versus Burdens — Emmons & McCullough, 2003