Share your best AI workflow. We could show it to 2M+ people.

I built an episode with the wrong voice. It was not a bad take; it was the voice of a different project entirely—a narrator I had cloned for another series months earlier. Nothing in my files identified which voice belonged to which show, so the assistant picked the one it had seen most recently. I did not catch the mistake until the mix. That is what working with agents on anything long actually costs you: not bad output, but amnesia. Every session starts cold, so settled decisions get reopened, undocumented rules get broken, and the same argument returns every week wearing a different hat. I run several short-form historical and science-fiction series at once, and they all survive on one file each. It is not documentation or a spec. It is what film crews have used for a century: a series bible combined with a daily production report, pointed at an agent instead of a hundred people. I use one Markdown file, read at the start of every session and updated when the session closes rather than when it opens. Four sections do the work: Step-by-step: 1. Closed canon: Each decision includes its reason. Mine says the opening shot is never a contemplative establishing shot. It opens mid-action, with the text hook on screen by the first second, and the beautiful wide shot comes second as the breather. I write the reason next to the decision because the plan for the current episode came back with that wide shot opening the sequence, and I had to reorder it again. The decision alone stops nothing; the reason keeps the rejected version from returning. 2. Rejected list: I record what was already tried and exactly why it was dropped. The wrong voice lives here now as one line: never reuse assets across projects without confirming. This is half the value of the document, and it is the half almost nobody writes. 3. State table: I track each item, its known defects, and the decision already made about it. Mine currently reads: lips at 62.5 to 63.5 seconds, native voice at 64.1 to 65.6, voice moved forward and the original position ducked. A defect written down with its fix is an instruction. A defect nobody records is work you pay for twice. 4. Next three actions: I list concrete next steps, each naming the file it touches. Never “keep going.” Step-by-step: 1. Create `HANDOFF.md` at the root of the project before any real work starts. 2. Write the goal, deadline, and delivery constraints. Anything external that forces your hand goes here instead of staying in your head. 3. Add every consequential decision to the canon, along with its reason and what broke with the alternative. 4. Whenever something is tried and rejected, add a row to the rejected table. It takes fifteen seconds and can save an afternoon. 5. Maintain a state table of the real items, including their defects and agreed fixes. 6. Close every session by updating only three things: the state, the new rejections, and the next three actions. 7. Open every session with: “Read `HANDOFF.md` in full before proposing anything. The canon and rejected list are not up for discussion. Verify the real state against the files, then tell me where we are in two lines.” The discipline that makes this work is updating the file when you close a session, not when you open one. At the end of a session, you still remember why you made the decisions. The next morning, you do not—and neither does the agent. The template is at the bottom. It costs nothing and it is a text file.

I used to open calls by asking people to remind me where we left off. The notes existed, but they were scattered across transcripts that nobody reviewed. I built two scheduled tasks that work together: one files every meeting at the end of the day, and the other sends me a prep brief every morning. At the end of each day, the first task pulls the verbatim transcript of every meeting I had into a shared Notion database. I use the transcript rather than the AI summary because summaries may be useful that afternoon but are less useful three weeks later when I need the exact thing somebody said. Each meeting becomes a page with the date, client, and attendees stored as real relations rather than text, so everything is filterable later. My business partner has access to the same database, so neither of us has to recap our calls for the other. At 7 a.m., the second task reads my Outlook calendar, finds the email thread or threads tied to each meeting, reads the associated transcripts in Notion, and writes a short prep brief for each one: what we said last time, what I owe them, and what is still open. The part that took the most thought was deciding what should not be filed in the main database. Personal meetings are skipped by keyword. Small internal meetings are screened for topics such as pay, hiring, legal matters, or client-confidential material. Those meetings are routed to a separate database with different permissions. When a meeting is ambiguous, it defaults to the restricted database. Failing toward privacy is the right default when a robot is making the decision. Step-by-step: 1. I turned on Zoom AI Companion so every meeting produces a transcript, then connected Zoom, Notion, and Outlook. 2. I built a Notion database for meeting notes with Date, Client, and Attendees as relation properties connected to existing Clients and People databases. These relations make the notes findable later. 3. I wrote the end-of-day task to pull each transcript verbatim, create a page, match the client by keyword against my client list, and add attendees based on the transcript speakers. 4. I filtered the speaker list because notetaker bots appear as attendees. I removed Fireflies, Otter, Fathom, and the other notetaker bots, and automatically created a person page for anyone who was genuinely new. 5. I deduplicated meetings using the title and date. If a page already existed as a placeholder, I updated it in place instead of creating a second one. 6. I added a skip list for personal meetings and a confidentiality screen that routes sensitive internal meetings to a separate, permission-restricted database. When the classification is unclear, it defaults to restricted. 7. I wrote the morning task to read that day’s calendar, search email and transcripts for each attendee and company, and produce one short brief per meeting covering the last contact, open commitments, and what I owe them. 8. I scheduled both tasks: the filing task for the end of the day and the briefing task for early morning.

I fed Claude my sweat-test data, and it formulated a DIY high-carb cycling mix tuned to my sweat chemistry. It also scaled the batch to match my available supplies and generated print-ready labels and batch sheets. Step-by-step: 1. I provided Claude with my sweat-test data. 2. I used Claude to formulate a DIY high-carb cycling mix tuned to my sweat chemistry. 3. I had Claude scale the batch to match my available supplies. 4. I had Claude generate print-ready labels and batch sheets.

I asked Claude to build me an artifact that works as my own personal book tracker. It includes separate sections for books I want to read, books I’m currently reading, and books I’ve read. I also asked Claude to collect specific data points about each book and create an insights tab that can gather information about my likes and dislikes over time, then make future recommendations. I personally dislike Goodreads’ UI and don’t use its social media features, so I wanted a personalized alternative housed within Claude alongside all my other workflows—a one-stop shop. Step-by-step: 1. I asked Claude to build an artifact for tracking my books. 2. I organized the tracker into books I want to read, books I’m currently reading, and books I’ve read. 3. I specified the data points I wanted to collect for each book. 4. I asked Claude to add an insights tab to gather data about my likes and dislikes. 5. I set it up to use those insights for future recommendations and keep the entire workflow within Claude.

I used AI to develop a simple daily care plan for my above-ground pool. I copied the links to the pool I bought online and asked which chemicals would be best and whether I should make any upgrades right away. Then I asked AI to create a daily routine to keep the pool sparkling throughout the summer. When the water started looking cloudy, I took pictures of the water tests I was running and shared them so AI could help me get the pool back where it needed to be. Step-by-step: 1. I copied the online links for the above-ground pool I bought. 2. I asked AI which chemicals would be best for the pool and whether I should make any upgrades. 3. I asked AI to create a daily pool-care routine for the summer months. 4. When the water became cloudy, I took pictures of the tests I was running on the water. 5. I shared the pictures with AI to get guidance on bringing the water back to the right condition.

I kept struggling to stay consistent with social media for my own projects. Writing captions, choosing hashtags, designing graphics, and scheduling content across platforms was taking hours every week—time I would rather spend building. So I built AutoKonnekt. You give it one sentence or a website URL, and it generates a full month of on-brand social posts, including captions, hashtags, and AI-generated images. It then schedules them across Instagram, Facebook, LinkedIn, TikTok, Pinterest, X, and Threads. The hardest part was getting the AI to sound like a specific brand’s voice instead of producing generic marketing copy. That took a lot of iteration on the prompting side. It’s live now with a free plan if anyone wants to try it: https://autokonnekt.com I’d love to hear what the community thinks. For those of you managing social media manually, which part takes the most time? I’m trying to figure out what to build next. Step-by-step: 1. I enter one sentence describing the project or provide a website URL. 2. AutoKonnekt generates a month of on-brand social posts with captions, hashtags, and AI-generated images. 3. I use the generated content across Instagram, Facebook, LinkedIn, TikTok, Pinterest, X, and Threads. 4. AutoKonnekt schedules the posts across those platforms. 5. I iterate on the prompting to make the content sound like the specific brand instead of generic marketing copy.

I run operations for my husband’s residential architecture firm, and I have no coding background. After every site visit, dozens of photos landed in Google Drive with names like `IMG_8834.JPG`. Renaming and filing them took about an hour per visit—when it happened at all. Otherwise, the photos sat unnamed and difficult to find, creating a professional liability gap because they document site conditions on a specific date, as well as lost portfolio material and a hole in the firm’s permanent project archive. I solved this by building a Claude skill: a saved set of instructions that runs the same way every time with one command. I trained it to examine each photo through the lens of a residential architect, describe what the image actually shows using our professional vocabulary, and rename the file in a consistent format. For example, `IMG_8834.JPG` becomes `2026-07-17_03_side-elevation-porch-brick-piers.JPG`—searchable, legible, and ready to file. Because it’s a skill rather than a one-off chat, it’s a file I can hand to anyone in the office. Everyone runs the same process and gets consistent output. Step-by-step: 1. I gathered the raw photos into one “unsorted” folder in Google Drive. 2. In Claude’s desktop app, I used Cowork mode, which handles actual files, and connected only that folder—not my whole Drive. The skill can only see and touch what I connect, so I use the narrowest folder that does the job. 3. I created a skill that tells Claude to read each photo, identify what it shows using my industry’s vocabulary, and rename each file in my standard `date_sequence_description` format. I wrote mine for residential architecture, but the approach can also work for real estate, inspections, insurance, and other field work. 4. I ran the skill with one command, and Claude worked through the folder photo by photo. 5. I had the renamed photos filed into a dated site-visit folder so they were ready to reference by number in reports. 6. I handed the skill file to teammates so they could run it on their own machines and get the same result. One caveat for anyone using this on business files: check your client confidentiality obligations and your AI vendor’s data policy before pointing any tool at project files. We did. I wrote up the full build, including how to decide when something should be a skill versus a regular Claude conversation, at The 2040 Studio: https://the2040studio.substack.com/p/every-img_8834jpg-is-snitching-on

Create an immersive 3D website for artists with an AI avatar that welcomes visitors, answers questions about the artist and artwork in real time, and presents the work throughout the virtual gallery. Step-by-step: 1. Build or download a 3D environment using Claude Code or another suitable development tool. 2. Upload the artworks into the 3D environment. 3. Create a digital avatar, optionally using Adobe Mixamo (free), and import it into the scene. 4. Connect the avatar to an AI language model so it can interact naturally with visitors and answer questions about the artist and the artwork. 5. Give the avatar the ability to point to, manipulate, or present artworks during conversations. 6. Write a detailed artist biography and a description of each artwork. Use this content as the AI avatar’s knowledge base so it can provide accurate, engaging responses. 7. Use open-source voice technologies through Pinokio to enable realistic speech synthesis and voice interaction. 8. Arrange the artworks throughout the 3D environment and optionally display videos on the gallery walls. 9. Configure the audio system so multiple videos do not play sound simultaneously. Audio should activate only when a visitor approaches or interacts with a specific artwork or video. 10. Configure collision detection so the avatar cannot walk through walls or other obstacles. For example, stop the avatar whenever it encounters an obstacle higher than approximately 60 cm (24 inches). 11. Optimize the experience for the web and deploy the website using FileZilla and OVH hosting. 12. Pay special attention to iPhone and iPad compatibility. Apple devices are more sensitive to large assets and memory usage, so it may be necessary to create separate optimized versions for iOS and Android, using compressed models, textures, and videos to ensure smooth performance.

After a sales call, the conversation is only part of the work. Someone still needs to write the notes, update the CRM, remember the next step, prepare the follow-up email, and make sure the deal does not disappear between meetings. I wanted that entire post-call process to happen automatically. I created an Awish workflow that starts when a sales call ends. It analyzes the conversation, extracts the important sales information, updates the CRM, creates the next actions, drafts a personalized follow-up email, and sends the team a short summary. The workflow looks for the information I would normally write down myself: what the prospect needs, the objections they raised, their timeline, agreed next steps, and anything that could affect the deal. Customer-facing actions stay under my control. The workflow prepares the follow-up, but I can review important messages before they are sent. Step-by-step: 1. I tell Awish what I want to happen after every sales call: analyze the conversation, update the CRM, prepare the follow-up, and notify the team. 2. Awish understands the request, plans the workflow, and determines which applications are needed. 3. I connect my meeting platform, HubSpot, Gmail, and Slack to the automation. 4. When a call ends, the workflow analyzes the transcript and extracts the prospect’s needs, objections, timeline, decisions, and agreed next steps. 5. It creates or updates the contact and deal in HubSpot and adds any follow-up tasks that came out of the conversation. 6. It drafts a personalized Gmail follow-up based on what was actually discussed instead of using a generic sales template. 7. It sends a short Slack summary to the team with the deal status, important points, and next action. Instead of a sales call ending as a transcript or a page of notes, it immediately becomes structured CRM data, clear next actions, and a follow-up that is ready to review. The useful shift for me is that the workflow is not replacing the sales conversation. It is handling everything that normally gets forgotten or delayed after the call.

I built an interactive AI recommender for Medium publications and packaged it as a Gemini Gem. Medium writers who want their articles to be discovered can submit their pieces to a publication, which is like a digital magazine focused on a specific topic. However, there are hundreds of publications, so it can be difficult to find the right one for a particular article. A key resource is "Medium's Huge List of Publications Accepting Submissions." It contains basic information about each publication, but the list is difficult to navigate because of its size. My solution was to organize that information and use it as the source for an AI recommender. I packaged the system as a Gem because the interface is cleaner, and users do not need to see the sources I used. Step-by-step: 1. I asked Gemini to compile and format basic information for each publication, including its topic, size by number of followers, and a short description. 2. I consolidated that information in a Google Sheet. 3. I used the spreadsheet as a source for a Google Notebook (formerly NotebookLM). 4. I added instructions for the AI, like the following: "You are an expert guiding the user to find the ideal publications for their articles in Medium. Ask the user to write down what their interests, topics, etc., are; whether they are beginner writers; whether they want to start with a small publication (less than 1,000 followers), mid-size (a few thousand), or only the biggest (tens or hundreds of thousands). Ask them for any other personal information and details about their writing, and take that into account." 5. I packaged the system as a Gemini Gem instead of distributing it as a Notebook so users could access it through a cleaner interface without seeing the sources. It can be accessed at the following link: https://gemini.google.com/gem/1HDPzcE6Jls76V4I2tFZhIn-SbeeDe-_-?usp=sharing

I used ChatGPT + Button to understand my dog’s blood work in language I could follow. Every couple of weeks, I uploaded all of my dog’s blood work PDF files and provided the information verbally that wasn’t included on the forms. It helped me understand which markers were important and compare the results from week to week, including where values were changing. That gave me a better foundation for conversations during veterinary appointments. During a difficult time, it also gave me peace of mind in a way nothing else could. It feels strange to say that, but it’s true. Step-by-step: 1. I uploaded all of my dog’s blood work PDF files to ChatGPT + Button every couple of weeks. 2. I provided the relevant information verbally when it wasn’t included on the forms. 3. I used it to identify which markers were important. 4. I compared the results from week to week and reviewed where the values were changing. 5. I used that understanding to have better conversations with the veterinarian.

A finished video can be wrong in ways you cannot see—not because of the edit, but because of the delivery file itself. That is what gets work sent back, and it is rarely the craft. I built a delivery check for this. I give it a finished file, tell it where the file is going and what kind of piece it is, and it measures the things that cause rejections: sample rate, mono audio, integrated loudness against the destination target, true peak, dynamic range against a band rather than a single number, A/V drift, whether the shots cut together, and whether the file can stream before it has finished downloading. Most of those checks are for sound, because most of what gets sent back is sound. Picture problems are visible on a screen. A file that is 2 dB too quiet or peaks at -0.7 dBFS can look perfect and still come back. For everything it can fix, the checker gives me the exact `ffmpeg` command, with the numbers already calculated for that file. It does not merely describe the fix, and it does not hand me a corrected file. That was the decision that mattered. A fixer is a black box. You never learn that you had a problem, so you make it again the following week. Then, when your editing tool adds an “optimize on export” button, you have nothing. An inspector that explains the problem in one sentence and gives you the command teaches you the standard once and remains useful when the tools change. Three things determined whether I would actually use it, and none of them are checks. “Two severities, never one.” Something either bounces, or it needs your eyes. A tool that only says “bad” gets ignored on the third run, because half of what it flags is a decision you made on purpose. Sample rate, mono, and true peak bounce without argument, and they get a command. Loudness and dynamic range need to be reviewed first. My dynamic-range check says in plain words that the result is often deliberate and should be fixed at the source rather than in the master. “A check that refuses to give a verdict.” On vertical video, the platform interface covers the bottom 26 percent and the top 12 percent. I flag high-contrast elements in those zones but deliberately do not fail them, because the detector cannot tell a caption from a bright patch of sky. The report explains that limitation. A check admitting what it cannot know is what makes the checks that do commit worth trusting. “The thresholds are mine; the code only applies them.” They live in a table: destination crossed with content. Social wants -14 LUFS, a festival master wants -18 with a wider tolerance because festivals provide a band rather than a number, and broadcast wants -23. A scripted short is allowed to be denser than a screencast. That table is the whole product. For example, to catch shots that do not cut together, I measure the luminance range across the piece. The first version used average brightness per frame and kept flagging legitimate night photography. A fade to black has nothing bright in it; a night scene does—a streetlight, a moon, or a face. Changing the discriminant to the brightest pixel in the frame instead of the average eliminated the false positives. That took ten minutes of thinking, and no amount of better code would have found it. Step-by-step: 1. I wrote down what had actually gotten my work sent back over twenty years before writing any code. I captured the scars rather than making a spec sheet; that list became the product. 2. I gave every check a severity: it bounces, or look before you send. Anything I could not confidently put in one bucket became informational, with no verdict at all. 3. I made every check return four things: the measured value, pass or fail, why it matters in one plain sentence, and, where possible, the command that fixes it. 4. I put the thresholds in a profile table instead of hardcoding one standard, because -14 LUFS is right for social and wrong for a festival. 5. I added a parameter for whether the file is my own master or a copy pulled from a platform. On a downloaded copy, half the container checks measure someone else’s transcode rather than my work, so they are skipped and the report explains why. 6. When two fixes would collide, I output only one command. If loudness already needs a gain change, the limiter goes inside that command instead of being offered separately; otherwise, I would run two instructions that fight each other. 7. I tuned the checker against real files until the false positives stopped. Ignoring the top and bottom five percent of frames eliminated the ones caused by a single stray frame. 8. I made the output a report. I read it, decide, and run the command myself. The functions are an afternoon of work, and anyone can copy them. What is not written down is the list of what to check, at what threshold, and why.

This mobile app organizes a field service technician’s entire workday in one place. It records departure and arrival times, on-site work, parts purchases, reports, return travel, and mileage. The app automatically identifies missing details, saves unfinished jobs, and allows them to be edited later. Filters make it easy to find a task by store, job number, date, or month. Data can be safely exported, transferred to another device, and downloaded as Excel or PDF files. Step-by-step: 1. Record the technician’s departure and arrival times. 2. Log on-site work, parts purchases, reports, return travel, and mileage. 3. Review the app’s indicators for missing details and complete any unfinished information. 4. Save unfinished jobs and edit them later when needed. 5. Use filters to find tasks by store, job number, date, or month. 6. Export the data safely, transfer it to another device, or download it as an Excel or PDF file.

San Diego County is enormous, and its startup scene is growing rapidly. I wanted a better way to see where companies are located, especially because many of them host networking events and there was no central map or repository. I told Claude what I wanted: an alphabetical directory with an industry selector and a way for people to add their own companies. I also asked it to keep the project as simple as possible, use as few tokens as possible, and wait for my approval before taking any action. Claude helped me design the map, create the Google Form for submissions, set up the Google Sheets workflow for hosting and approving companies, and use Netlify to host the main file. It also guided me through linking the map to a page on my own website: https://sdaimap.michelabood.com/. Claude warned me about the legal issues involved in scraping a list wholesale from other sites, so the map is designed to be populated by people submitting their own companies. I just published it, and 10 companies have already been listed, with more on the way. I have also received great comments on LinkedIn. Now I can see at a glance how far I need to go to find a specific company. I also had Claude create a step-by-step guide, which I am happy to share if people want it. Step-by-step: 1. I described the map I wanted to Claude, including an alphabetical directory, an industry selector, and a way for people to add their own companies. 2. I asked Claude to keep the project as simple as possible, use as few tokens as possible, and wait for my approval before taking any action. 3. I used Claude to design the map and create the Google Form for company submissions. 4. I used Google Sheets to host and approve the submitted companies. 5. I followed Claude's guidance to host the main file on Netlify. 6. I linked the map to a page on my own website: https://sdaimap.michelabood.com/. 7. I avoided scraping a wholesale list from other sites because of the legal issues Claude identified. 8. I published the map and began collecting company listings from people directly.

I developed a platform that helps users learn dimensional modeling and create entity-relationship (ER) diagrams through a drag-and-drop interface tailored to specific use cases. I noticed that many people struggle with visualization and face a significant gap between understanding database concepts and creating tables. This can make it difficult to work independently or determine which type of table to use and when, including whether to create a dimension or fact table. Step-by-step: 1. I identified the difficulty many people have visualizing dimensional modeling concepts. 2. I created a platform focused on learning dimensional modeling and ER diagrams. 3. I built a drag-and-drop interface tailored to specific use cases. 4. I designed it to help users understand how to create tables and determine whether to use a dimension table or a fact table.

Writing event copy used to take me an hour. Now, it takes a conversation. In this video, I show how I use Claude Opus 4.7 to draft a Meetup listing for the Christchurch Artificial Intelligence Meetup in the same voice, tone, and structure as my previous events. I provide a few past examples, ask Claude to reflect on the format, and then give it the raw content for the next event. Step-by-step: 1. I provide Claude with a few examples of previous Christchurch Artificial Intelligence Meetup listings. 2. I ask Claude to reflect on the voice, tone, and structure used in those examples. 3. I hand over the raw content for the next event. 4. Claude uses the examples and format analysis to draft the new Meetup listing.

I use AI agents across roughly half of my startup, including search, security testing, development, and affiliate integrations. - Smart Shopping Deals search: It never relies on a single AI provider. I use a chain of backup providers for LLM-based search and embeddings with pgvector. If one provider fails or times out, the system silently retries with the next. A slow provider never hangs the request, and users never see the failure. In the worst case, the system falls back to plain search. - Security testing: I run the autonomous AI security agent Strix against my live preview after every deploy. It actively attacks the app the way a hacker would. - Development workflow: My real “team” is a four-layer testing rule enforced by the AI itself. Every feature has to ship with backend tests, component tests, full browser end-to-end tests, and test-data setup, all in the same commit. Claude Code doesn’t consider a feature “done” until all four exist—not just the code. - Affiliate parsing: One parser handles every affiliate network. I paste in the raw ad code from any network, and the same parser automatically extracts the banner link, image, and destination URL. No network-specific code is needed.

I created a website lead workflow that researches each company, scores the opportunity, updates my CRM, drafts a personalized reply, and notifies me on WhatsApp. I had previously built similar workflows with Claude Code, but connecting external applications was often the hardest part. I had to manage OAuth setup, credentials, APIs, and different integration requirements for every app. I also found it difficult to monitor and control completed automations from WhatsApp without building additional infrastructure. To solve this, I created Awish, a tool focused on AI-powered automation. Instead of manually designing every workflow, I describe the result I want in chat. Awish’s agents understand the request, plan the automation in the background, determine which applications and steps are required, and prepare the complete workflow for me. When a new lead submits my website form, the workflow researches the company, evaluates the lead against my criteria, assigns a score, and adds the contact and research results to my CRM. It then drafts a personalized response based on the lead’s company and needs before sending me a WhatsApp notification for review. The application connections are handled through a simple sign-in flow. I connect my personal accounts with a click instead of manually working with OAuth code, API keys, or custom authentication logic. Once the workflow is active, I can monitor it, receive updates, and manage its actions directly from WhatsApp without opening the Awish application. Step-by-step: 1. I open the Awish chat and describe the workflow I want: when someone submits my website form, research the company, score the lead, add it to my CRM, draft a personalized response, and notify me on WhatsApp. 2. Awish’s agents analyze the request and create the application and automation plan on my behalf, including the trigger, research steps, lead-scoring logic, CRM fields, response draft, and notification. 3. I review the proposed plan and sign in to the required applications with my personal accounts to connect them to the workflow. 4. Awish builds the automation so each new website submission triggers company research and collects the information needed to evaluate the opportunity. 5. The workflow scores the lead, creates or updates the CRM record, and stores the contact details, company research, and lead score in the appropriate fields. 6. It drafts a personalized response using the information submitted by the lead and the additional company research. 7. I connect WhatsApp from the Awish chat, and the workflow sends me the lead details, score, CRM update, and response draft there. 8. I review and manage the automation directly from WhatsApp without needing to open Awish or build a separate messaging integration. The result is a lead-management workflow I can create through a conversation, connect to my existing applications without manually implementing OAuth, and control from WhatsApp while the agents handle the planning and execution in the background.

I built Bubble Grotto, a skill-based arcade game for mobile devices, using AI as a development partner. The concept is deliberately simple: start with a small bubble, grow it, navigate through a cave filled with hazards, and decide when to escape. The larger the bubble becomes, the greater the potential reward—but the harder it becomes to manoeuvre safely. The aim was to create the classic “one more go” experience: controls that can be understood almost immediately, with gameplay that becomes progressively harder to master. The interesting challenge was that building a game is very different from implementing a list of features. The code can work perfectly and the game can still be no fun. Timing, movement, difficulty, visual feedback, and risk versus reward all have to feel right when somebody actually plays it. Step-by-step: 1. I used AI to discuss how the core concept should work, including bubble growth, movement, hazards, progression, scoring and rewards, and the escape mechanic. 2. Rather than designing the entire game upfront, I used AI-assisted development to turn each mechanic into working code and get it onto a real device as quickly as possible. 3. Once a mechanic existed, I tested it myself. I checked whether movement was responsive, whether the bubble grew too quickly, whether obstacles were fair, whether escaping was too easy, and whether failure made me want another attempt or simply became frustrating. 4. I brought those observations back into the AI workflow, identified the relevant behavior or code, made targeted changes, and tested again. 5. Once the core loop felt enjoyable, I refined the interface, visual feedback, progression, and presentation instead of allowing cosmetic work to hide weak gameplay. This produced a development loop of: idea → mechanic → playable build → play-test → adjust → repeat The final result is Bubble Grotto, an arcade game with simple controls but increasingly demanding skill-based gameplay. Players grow their bubble while navigating hazards and must balance risk against reward by choosing the right moment to escape. One of the most useful things I learned is that AI can dramatically accelerate game development, but it cannot replace judgment about whether something is enjoyable. AI can help create a mechanic, investigate why it behaves incorrectly, and implement changes extremely quickly. The human still has to play the game and decide: is this actually fun? That combination allowed me to move rapidly from a simple game idea to a functioning mobile game while spending far more of my time experimenting with gameplay than wrestling with implementation.

I applied for Schengen visas from India for my wife and me, using Claude to handle the process without an agent. We had two linked applications, with me as her sponsor. The biggest value came from determining which rules actually applied and making sure both files were consistent. Claude used the official checklist and reviewed dozens of recent threads about visa rejections to identify common gaps and ensure our applications addressed them. Initially, I used a generic India-wide checklist. Claude caught that mistake and found the destination’s jurisdiction-specific requirements for New Delhi. This materially changed the application and significantly reduced the paperwork. Each correction removed unnecessary work and saved me a lot of time. Claude drafted the document set, including two cover letters, a sponsorship affidavit for notarization, a self-employment letter, and a day-by-day itinerary. It then kept simplifying the documents and suggested workarounds wherever needed, drawing on the Reddit research. It also cross-checked the finalized forms and documents and flagged human errors, including a missing digit in my mobile number and a checklist box that contradicted the letter beside it. Finally, it helped with the practical details: sequencing our appointments, deciding which documents needed originals or copies, and determining what to do if counter staff asked for something that was not on the governing checklist. Both visas came through. For me, the useful part was having one system research the requirements, build the paperwork, and audit the entire application for inconsistencies before submission. Step-by-step: 1. I gave Claude the details of our two linked Schengen visa applications, including that I was sponsoring my wife. 2. I had Claude review the official checklist and dozens of recent visa-rejection threads to identify common gaps. 3. I asked it to verify the requirements for our destination and the New Delhi jurisdiction instead of relying on a generic India-wide checklist. 4. I used Claude to draft and simplify two cover letters, a sponsorship affidavit for notarization, a self-employment letter, and a day-by-day itinerary. 5. I asked it to suggest workarounds wherever needed, based on the Reddit research. 6. I had Claude cross-check the finalized forms and documents for inconsistencies and human errors, including the missing mobile-number digit and the contradictory checklist box. 7. I used its guidance to sequence our appointments, determine which documents needed originals or copies, and prepare for requests from counter staff that were not on the governing checklist. 8. I submitted the applications after the research, paperwork, and consistency checks were complete.