The power behind AI: Your brain
Learn how tailoring AI to your thinking style can unlock surprising progress. This story shows how a neurodivergent creator used vibe coding to build practical tools and find renewed inspiration. Nency Yera is a Revenue Strategy professional at Microsoft who discovered vibe coding three months ago and hasn’t stopped building since. I have ADHD and no coding background. Until three months ago, the idea of building software made me want to close my laptop and walk away. Every time I tried to learn something technical, the same thing happened. Launch a tutorial. Stare at wall of text. Brain opens 47 tabs, panics, and quietly exits. Then that voice shows up: This isn’t for people like you. I believed that voice for a long time. I don’t anymore. Because it turns out that my brain was never the problem; my brain was the power source. The wall I work in Revenue Strategy at Microsoft. My job is operational excellence, not code. But I had a problem I couldn’t fix with spreadsheets: critical knowledge that leaders need to run their business was buried in slide decks and documents nobody could find. I could see the solution in my head. I just couldn’t build it. The traditional path to learning—tutorials, documentation, courses? Linear steps. Walls of text. Built for brains that work differently than mine. My brain needs fast feedback. Not a 40-page document. It needs someone to say, Here. One step. Try it. Good. Now the next one. The unlock So I decided to open GitHub Copilot in Visual Studio Code and do something I’d never done with any tool before. I told it exactly how my brain works. “I have ADHD. Give me one step at a time. Use plain language. Wait for me before moving on. No jargon.” And it took this information in. A supportive, low‑jargon VS Code guide introduces a noncoder to the basics of building with AI. When I said, “I’m confused,” it broke things into smaller pieces. When I said, “Too many words,” it switched to bullet points. When I prompted, “Explain this like I’m brand new,” it did. No judgment. No rush. I broke things constantly. Red squiggly lines everywhere. But instead of panicking, I’d prompt, “Something’s broken. Help me fix it,” and Copilot walked me through it. Every mistake became a lesson I remembered because I learned it by doing. I saved those preferences in a file called copilot-instructions.md. Now, with every conversation, Copilot already has the context it needs about how I think and process. That was the unlock. It turned a generic tool into a collaborator that adapts to me. Then I made VS Code feel like mine. Dark theme. Rainbow-colored indentation so every line popped. Extensions that showed errors right where they happen instead of hiding them in some log I’d never find. Suddenly, my screen looked like something I wanted to stare at. It stopped being scary. It started being fun. What I built In the first week, I built a website that organizes 205 performance metrics into one searchable hub. Prep that used to take leaders hours now takes minutes. Then I built a dashboard that helps leaders track how teams adopt AI-powered tools across every operating unit. It’s deployed globally. What used to require hours of manual data gathering now runs on its own. After that, I built newsletter templates that turn meeting transcripts into polished executive recaps sent to all levels of leadership. What previously took 45 minutes of writing now takes seconds. And I built a cheat sheet that translates every scary technical term into plain English, because “commit” should just mean “save,” and “repo” should just mean “project folder.” None of this required a computer science degree. It required what I already had: knowledge of the problem, ideas for the solution, and a brain that wouldn’t stop until the fix worked. The leader who made it possible I have to be honest. I didn’t do this alone. I have a leader who saw what was possible before I did. He ran live demos in team meetings. Created space to experiment. Never once said, “That’s not your job.” Instead, he said, “What do you want to build next?” Not every neurodivergent person has that. And they should. Because when a leader gives someone permission to explore and learn at their own pace, what comes back is extraordinary. People with neurodivergent brains don’t think in straight lines. We think in webs. In patterns. In creative leaps that don’t make sense to others until we build the thing and say, “See? This is what I meant.” Vibe coding finally lets us show our ideas instead of just describing them. Your brain might work like mine If you’ve ever closed a laptop in frustration or told yourself, “I’m not technical enough,” I want you to know something. The problem was never your brain. The tools just weren’t ready for you yet. They are now. You don’t need to learn to code. You need VS Code (a free app), GitHub Copilot (the AI inside it), and five minutes to tell it how you think. My first working page took 20 minutes. Start with the Vibe Coding Cheat Sheet. Customize your setup so it feels like yours. Then describe what you want to build, and watch it happen. As noted on the cheat sheet, you don't need to be a coder to build cool things. AI without your brain is just an empty tool. Your expertise, your ideas, your way of thinking? That’s the power behind everything AI can do. And what you build, when someone finally gives you the tools and trusts you to run with them, will surprise everyone. Especially yourself.Why I’m telling my team to stop asking permission and start building
Learn all about vibe coding, no experience required, and get inspired by real-world success. Alfredo Ramirez is Vice President of Revenue Strategy at Microsoft, where his team runs sales planning, performance management, and commercial transformation across the Microsoft global sales organization. Many of the most impactful tools my team uses today weren’t built by engineers. They were instead built by operations leads, program managers, planning analysts, and business process owners, people who had never written a line of code in their lives. And they built these tools in hours, not months. What is vibe coding, and why should leaders care? I’ve sponsored projects where, by the time we saw the first working version, we’d realized that the original ask should have been different. Requirements evolve, tradeoffs are real, and building reliable software takes thoughtful iteration. The challenges were always the same: feedback loops were slow, and the cost of change was high. Vibe coding collapses that cycle. You describe, in plain language, what you want to build, and the AI generates working software. But I want to be clear about what this means. It’s not magic, and it’s not Describe it once, and the AI builds it. Vibe coding requires structured thinking: that is, framing the problem clearly, knowing what good looks like, and iterating not just the output but also the approach when it’s broken. The process is closer to negotiation than dictation. What you don’t need is a programming background. We’ve been told that tools like GitHub Copilot are for developers, that business users won’t learn interfaces like Visual Studio Code, that this world belongs to engineers. I’ve found the opposite. What you actually need is deep knowledge of your domain: your problem, your data, your business rules, and what a useful solution looks like to you. Your team already has what vibe coding runs on: domain expertise, institutional knowledge, judgment about what matters. The work is the thinking. AI handles the implementation. How I got here I’m a former engineer who spent years with my hands on a keyboard before moving into strategy and leadership at Microsoft. When new AI capabilities emerged, I didn’t just read about them; I started experimenting with tiny helper tools, built using GitHub Copilot. Then I hit a real business problem and decided to see what vibe coding could do at scale. The result wasn’t just a working solution, it was a realization: the bottleneck had always been access to the tools, not technical skills. So I stopped experimenting alone. I ran live demos in my team meetings, showing people their own data, their own processes, and their own pain points being solved in real time with GitHub Copilot and VS Code. The conversation went from What is AI, and how do we do this? to What should we build next? People stopped asking for tools and started building them. What my team built A non-developer trimmed incident response time from an hour to minutes. This colleague who manages support escalations was spending an hour or more, per incident, manually navigating databases, reading case details, and drafting executive summaries. He’d never written code. He vibe coded a Python script that queries our data systems, formats results into a structured prompt, and returns ready-to-send executive summaries. When the AI suggested a heavyweight Azure deployment, he pushed back and asked, Is there another way? and got three simpler alternatives. Every incident now gets the same rigorous analysis, regardless of who processes it. The barrier wasn’t technical difficulty; it was the perception that it would be technically difficult. One team delivered significant results in a fraction of the usual time. Two members of our partner experience team, both first-time VS Code users, vibe coded a full interactive prototype for a co-sell experience between Microsoft sellers and partner sellers. They fed in requirement docs, meeting transcripts, partner feedback, and design principles. GitHub Copilot synthesized it all into a coherent spec and interactive HTML demo. When stakeholders saw it, they could react to real artifacts instead of printed concepts. One senior leader said it plainly, “You did more in 10 days than we’ve been able to do in 10 months.” The prototype has since been handed to engineering for production build-out. The people closest to the problem could finally show, not just tell. A team member adapted the tools to her brain and then used that adaptation to build for everyone else. One colleague had never written code. When she started using VS Code and GitHub Copilot, she shaped the tool to match how her brain works: how she takes in information, how she stays focused and moves through complexity. It became an extension of her thinking, rather than something she had to contort herself to use. This made what came next possible. She noticed that leaders had no good way to prepare for high-stakes review meetings: the metrics kept changing, definitions were scattered, context was buried. And no one had filed a ticket for this. She fed her existing prep materials into VS Code and built an interactive hub that organizes metrics by how leaders think when preparing for reviews. The hub reduces noise, surfaces what matters, and links directly to source reports. The design choices she made for herself (clarity, structure, reduced cognitive load) turned out to be exactly what leaders needed. That’s what happens when the person building the tool is also the person who understands the problem. What I’ve learned watching this unfold These aren’t experiments. They’re real business processes running in production, saving measurable hours. And they’re built by people whose job titles say nothing about software development. When I introduced this across our organization, I heard the same concerns that many leaders hear: Will AI take my job? What I’ve seen is the opposite. People feel ownership over their work in a way they didn’t before, because they’re solving problems they’ve been working around for years. AI didn’t replace them; it gave them the means to finally act on the expertise they’ve always had. Every one of my team members who built something useful also failed multiple times along the way. They hit loops where the AI got stuck. They got suggestions that were too complex. They learned to ask: Is there a simpler way to do this? and Let’s reset and try again. Make it safe to try. This doesn’t require additional budget, new initiatives, or engineering capacity. The people who know the work best can start building today. Show your team what’s possible with their own data, their own problems, in real time. Leaders are much more likely to engage when they see transformation happening than they are when reading about it on a slide. If you still believe that these tools are only for engineers, you could be leaving some of your best problem-solvers on the sidelines. Give your people the tools and permission, and then get out of the way. Learn how to get started with vibe coding on AI Skills Navigator.
