How NOT to Use Claude Code
I got into a prestigious worldwide hackathon - and failed to produce a working demo. Here are the lessons on what NOT to do.
One Tuesday in April, I got a notification - my application was accepted into the Anthropic Claude and Cerebral Valley Opus 4.7 Hackathon. A 2.4% acceptance rate - only 500 participants worldwide out of over 20,000 applicants. I was one of less than 100 US citizens participating.
Cue excitement. Then, the countdown began. What follows is an account of how I failed to create a simple hackathon demo despite having the world’s greatest technology at my fingertips.
Note: All of us had to use Opus 4.7 and build during the same week. I ran into problems nobody else seemed to have encountered.
I submitted my hackathon project with only seconds to spare - and waited with guilt, because I didn’t know if my code even worked. This was after days of attempting to debug with Opus 4.7 on high to xhigh effort, turning on advisor mode, running subagents and routines and loops that were meant to ensure what got built was what I asked for.
Instead, I kept fighting the system’s drift from my intent.
It was a simple implementation - take the Cowork skills I had already defined and tested for months, wire them up to a UI and UX flow, and I should have a working demo ready to go.
What happened was an anti-pattern I did not expect to run into - from not being able to parse good vs bad engineering advice as a non-SWE, to the double-edged sword of having an ADHD mind that can contain entire visions but terrible working memory.
It All Started on Day One
I was an experienced builder when I joined the hackathon - I knew about commands, how to clear and reset context, how to setup permissions for safer auto-builds. I successfully shipped smaller projects like my professional AI chatbot at www.muxin-ai.chat and was part of a selective community of AI Builders (ABC) that you had to apply to get into. So I knew what I was doing.
Or so I thought.
The first thing I did in the codebase wasn’t building the product - it was to setup the scaffolding and apply the best practices I learned from Boris and other builders to make the repo ready to go. I asked Perplexity to do the research on what that entailed, copied over a list of its proposed commands, scripts, loops and routines, and asked Claude Code to build this underlying OS layer to help keep the product build on track.
What I didn’t know was how the lack of AI judgement came to bite me later: Perplexity did what I asked it to do. But it shouldn’t have.
I gave it the context that I was solo-building for a hackathon. But instead of evaluating that scenario and carefully giving me what I actually needed, it gave me a production-ready hardening system that was way too over-engineered. I didn’t know the difference. I assumed that giving it the hackathon context must mean it produced the recommendations I needed, and didn’t evaluate its outputs with other models to sanity check.
Oops. To be fair, I was under a crunch - but the real fail was I didn’t know any better.
AI’s great at doing what you tell it to - it doesn’t mean it has judgement. Different models could have handled this request differently and pushed back. But knowing that was a potential failure mode didn’t cross my mind. I had gotten too used to ‘getting answers’ from AI that I forgot it was a prediction machine.
Claude Code dutifully followed Perplexity’s recommendations - the literal instruction-following of Opus 4.7 turned out to be a weakness instead of a strength in this case. I spent the next few days running into issues I could not have foreseen.
Example - I wanted our execution subagents to deliver what was defined in the acceptance criteria. The agents would do just enough work to check the boxes, but miss the real goal. I’d complain that the data wasn’t syncing to the profile - it would fix only that tiny piece instead of the underlying intent, which is that data should have been wired up coherently across the UX. Everything that was running the scaffolding OS just created more documentation, bureaucracy, drift and context poisoning.
For days on end, I ended up having to fight the very scaffolding I had asked Claude to build and follow, not realizing at the time that it was the very reason the code kept derailing from what I asked for.
The Neurodivergent ADHD Double Bind
This is how I want to work while I build - let me describe what it is that I want, clarify any ambiguity, review the final output and give feedback. As a PM, I knew what the software development cycle was. I knew how important the planning and PRD definition stages were now that AI writes the code, and how important it is to be in the loop on product decisions and design so that those steps inherited my human judgement.
But my brain is special - with ADHD, it feels like everything is ON with higher intensity. You can see more things all at once, more vividly and intensely: Often times I can just see the end result without going through a linear sequence to get there. I just ‘land’ at the end.
The problem is, as an ADHD builder you can easily over-scope: AI agents do best if you just feed it one step at a time and start simple. But ADHD doesn’t see a simple first step - it sees the entire whole, all at once. There’s no built-in mechanism or scaffolding for AI agents to hold all of that at once.
You can solve for this by intentionally using Plan Mode or similar settings to force a planning stage, or crafting your PRD - but as a non-SWE, you often don’t know when to use it. What if what you’re asking for is actually quite simple to implement, and you’re causing unnecessary bloat and context poisoning by overdoing it? You don’t really know how ‘large’ your request is and how much process is needed. Being overly spec’d can be just as harmful as under-speccing, and you’re forced to judge as the user whether or not what you’re asking for is considered ‘reasonable’. If you’re not a SWE, you just don’t have the instincts for it.
Then there’s the memory issue - not agent memory, but the “human with ADHD can’t remember things if it isn’t written down somewhere and has a clear path to follow up on” kind of memory issue. While building, I would notice something that needs to get implemented. Instead of relying on my absent working memory, I would ask Claude Code to work on this.
Bad move. Before long, my hot-running brain is asking Claude to do 20 different tasks, and it struggles to complete 1 properly.
There’s no automated inbox for holding things in a backlog for me to offload my own brain and a process to sort it all, prioritize and sequence it (you know, grooming?) And because I know about context window limits - and I was under a time crunch - I tried to run tasks in parallel by spinning up multiple sessions at a time, each running a different set of similar tasks. Then I end up spending hours debugging git sync issues and conflicts on worktrees and branches.
Btw, if anyone knows of an auto-Git plugin that magically handles these things, please DM me.
One more complication - I love Wispr Flow and used it during the build. It’s a fast way to get your thoughts out in writing. But it became a fault amplifier with my ADHD brain - instead of being forced to slow down because I had to type things out, I’d dump Claude with one transcript at a time, each with several tasks to untangle at once.
What I Did After
For a day and a half after the hackathon ended, I did a post-mortem: Retracing my git history, recounting my steps, running adversarial code reviews on my demo’s codebase to understand where everything went wrong. I have now shared that story and my theory.
But I still have a problem: What do I do now? How am I going to get better at building?
What I came up with was a cleaner repo starter kit/plugin that took the lessons from all my failures and introspection and turned it into a reusable packet. I stripped away the overbuilt components from my hackathon scaffolding and only kept the ones that were well designed (the ones I built from experience; nothing from Perplexity’s original recommendations made it in).
I designed for my ADHD brain instead of forcing myself to adapt to a workflow that was never going to feel intuitive to me: I will always see the complete end vision first. I will always have working memory problems. So I built my own inbox and router system, to ensure that there’s a translation between my thoughts and the AI development workflow. I threw out anything that was already working in other plugins (Superpowers and AQE are explicitly mentioned) so that I can benefit from the expertise of professional SWEs, and I built for the gaps that remained for users like me.
Why ADHD Brains Should Shine with AI
I see a convergence across multiple themes - AI is making software easier to build, so having ideas become more important. Real insights often involve having systems-thinking across multiple disconnected domains, and ADHD brains are great at both systems-thinking and coming up with ideas. There’s never been a better time to be a founder, and ADHD correlates very highly with entrepreneurship.
But if brains like mine can’t work with the tools available, we’re still stuck being unable to bring our visions to life. Which is a huge shame to society - people with ADHD are deeply empathetic, mission driven, justice-oriented, and intuitive. We need more of us to build solutions that the rest of the world needs.
I am still testing out my starter repo kit, but once I’m able to fix my hackathon codebase with it I’ll be ready to share. I really wanted to launch the product I was building towards in the hackathon - Intently, an AI personal knowledge system that automatically organizes your day to align with your goals and projects. I strongly suspect those with ADHD will find it valuable - God knows we have way too many projects and ideas to juggle.
Keep in touch with me on X @heymoosh or Muxin Li on LinkedIn: https://www.linkedin.com/in/muxinli/