Metacognition is the AI Skill of the future. Always has been.
A Spiral report on the adoption and mindset of AI usage in open-source development.
Key Takeaways
84% of respondents use AI every single day, and 64% spend more than $100/month.
Brainstorming matched code writing as the #1 use case, suggesting that builders value AI as a thinking partner just as much as a code generator.
Self-reported productivity gains clustered at 2-5x, with some reporting 10x or more when working outside their core expertise.
Four builder archetypes emerged from the data: the Verifier, the Orchestrator, the Upskiller, and the Hyper Coder. Each represents a distinct pattern of incorporating AI into their work.
The skill that separated the most effective builders wasn’t their choice of tool. It was metacognition: the ability to step back, evaluate their process, and redesign their workflows around both their specific use cases and how AI agents interpret the world.
Introduction
When I first volunteered to conduct an AI-focused survey of Spiral open-source bitcoin developers, I thought I was going to get first-hand access to the most powerful AI cheat codes: the exact tools and workflows that make the smartest open-source developers wildly productive. I was ready to learn the cutting edge tricks that would 1,000x my output. Instead, I found something different. While there were certainly some techniques that were reproducible, the skill that really made people successful was metacognition, the ability to step back from their own thinking, reevaluate their process in the age of AI, and continually redesign their workflow as a result.
If you’ve been following AI even casually, you’ve noticed that things are changing every single day. This was clear in the survey responses. There were multiple times when I scheduled an interview just a week or two after a survey was submitted, and the grantee started the conversation by saying they had totally revamped their AI usage since submitting the survey. Much of what they said two weeks ago was already old news.
These conversations made it clear to me that successful use of AI was not simply using tools to become more productive. It was the ability to apply an entrepreneurial, metacognitive mindset to their process. In practice, this often meant designing prompts, workflows, and architecture around both their specific use cases and how AI agents interpret the world.
Before diving in, it’s worth noting the types of projects that Spiral team members and grantees actually work on. First and foremost, many developers write protocol-level or consensus-critical code where there is very little room for error. For example, Bitcoin Core, Lightning Development Kit, or custody systems like Fedimint. On the other end of the stack, a smaller number operate in non-engineering roles such as product design, video production, project management, and community operations. This context will shape everything that follows.
Survey Overview
50 Spiral grantees and team members responded to the survey, and I conducted follow-up interviews with eight of them to dig deeper into their workflows and use cases.
First, let’s briefly review the landscape. From the beginning, it was very clear that Spiral team members and grantees are heavily invested in AI, both with their time and with their wallets. 84% of respondents reported using AI every day, and 64% spend more than $100 per month on AI tools. 88% of respondents reported using Claude Code, making it the most popular tool by a wide margin. Perhaps unsurprisingly, given how fast AI tooling is advancing, 20% of respondents cited not knowing how to use AI effectively as a limitation. It’s my hope that this report helps bridge that gap.
Frequency and investment
84% of respondents use AI every single day. In fact, only one person in the entire survey reported not using AI at all. When it comes to spending, this group is not holding back. Over a third (36%) spend more than $200 per month on AI tools, another 28% spend between $101 and $200, and only 4% stick to free tiers.
Tools
Claude is the clear favorite at 88% adoption, with ChatGPT as a distant second at 46% and Gemini at 26%. The “Other” category (24%) includes tools like NotebookLM, Wispr Flow, Maple AI, OpenRouter, and various open-source frameworks. Goose, an open-source agent, showed up at 14%, which isn’t surprising given the Bitcoin community’s preference for self-hosted and sovereignty-preserving tools. Relatedly, 18% of respondents cited the lack of open-source alternatives as a limitation on their AI usage, suggesting that further education around the open-source AI tooling landscape would benefit the Bitcoin Free and Open-Source Software (FOSS) community.
Use cases
The breadth of how people are using AI is worth calling attention to. More than half of respondents use AI for six or more distinct tasks, and writing code and brainstorming are tied at the top at 88%. Note that writing code involves more than shipping software to production. Writing tests, debugging, and refactoring can also be considered writing code, so this statistic should not simply be taken to mean that 88% of respondents are using AI to ship production code. In fact, as we’ll see later, many developers have strict boundaries around how they use AI. Another interesting stat that stood out in the data is that brainstorming matched code writing as the most common use case, which suggests that builders may value AI as a thinking partner just as much as they value it as a code generator. This also speaks to the nature of the FOSS community, which is largely comprised of individual contributors who live all over the world. Some respondents even spoke to this directly, citing that chatting with AI helps them learn and stress-test ideas, providing some of the benefits that in-person collaboration provides.
Productivity
A few respondents attempted to quantify productivity gains across a wide variety of tasks, such as coding, debugging, testing, learning new skills, and prototyping proof-of-concepts. Self-reported productivity gains should be taken with a grain of salt, but it’s worth noting that they tended to cluster in the 2x to 5x range. Some respondents even reported 10x productivity gains or more, particularly when working on tasks outside their core expertise. One respondent described building in an afternoon what would have previously taken them months. Several others emphasized the difficulty in quantifying productivity gains, as AI often enables capability unlocks, whereby builders can do things that were previously impossible. For these use cases, going from 0 to 1 is literally impossible to quantify (you can’t divide by 0!).
Limitations
Security concerns are the most commonly cited limitation at 42%, which isn’t surprising given that many of these developers handle consensus-critical and custody code. Code quality ranks second at 32%, followed by cost at 28% and rate limiting at 24%. Interestingly, 24% of respondents report no limitations at all. Of those, 83% use AI daily and 83% spend over $100 per month, placing them among the heaviest adopters in the survey.
Four Archetypes
After reviewing the surveys and conducting interviews, a few builder archetypes began to emerge from the data.
In the below sections, we’ll review each archetype, how they viewed their working relationship with AI, and a few use cases that demonstrate step-change results that Spiral grantees or team members were able to achieve using AI. One theme to keep in mind here is risk tolerance. In other words, a respondent’s usage and boundary-setting of AI was directly influenced by the degree of risk they were willing to take. Developers who work on consensus-critical and protocol-level code set the most boundaries around their use of AI. On the other hand, those who were building products and services, such as education platforms or prototypes, where a “bug” can be patched with relatively little impact on users (nobody is losing their money), were much more willing to let AI take the driver’s seat and produce production code without as much oversight over every line of code generated.
It should be noted that individual developers often exhibited traits that span more than one archetype, but each archetype represents a more-or-less distinct way of thinking about the relationship between an individual’s work and how AI can help them. Also, these archetypes are by no means an exhaustive list of “personas”. They are simply a few that emerged from the data, and they are useful frameworks for understanding how builders evaluate and redesign their process around AI.
Let’s look at each one.
The Verifier
The security-first engineer who sets strict bounverifierdaries around what AI is and isn’t allowed to touch.
As discussed earlier, risk tolerance shapes everything. For developers working on Bitcoin Core, protocol-level implementations, or cryptographic libraries, the cost of a single AI-generated error is so high that large productivity gains simply do not justify the risks. However, that certainly did not mean these respondents were not using AI - they were! They just developed unique workflows that matched their risk tolerance and provided meaningful productivity gains in areas other than code creation, like testing, debugging, and pull request (PR) review.
Below are a few quotes from respondents, describing how they still prioritize review, even if AI helped generate the code.
I manually go through each and every line, run it and then commit it.”Cryptography developer
“I review each change made by Claude carefully, as if I were reviewing anyone else’s code.”Lightning developer
So, where do Verifiers use AI then? Well, they’ve identified plenty of lower-risk ways to leverage AI. For instance, writing tests and fuzz coverage are some of the most common use cases. Debugging is another favorite, with developers often reporting 2x to 5x speedups. PR review, research, UI code, and mechanical refactors also fall within the boundary of tasks where AI use is accepted and beneficial.
“[AI is] now also my default way to generate test cases for new code, also very easy now to add fuzzer coverage.”Lightning developer
“I use [AI] as a ‘review sidekick.’ It cannot be trusted to sign off that a PR is correct or up to codebase standards, but it can help a lot getting up to speed quickly.”Lightning developer
“Security-wise I tend to think it’s an increasingly good trade-off to avoid the risk of third parties being able to rug pull our users.”Lightning developer
The last quote above is worth elaborating on. One Lightning developer reported using AI to help replace third-party dependencies entirely. In open-source software, external dependencies are a potential attack vector. This is especially dangerous in bitcoin, where a single compromised dependency can lead to a loss of real funds. All it takes is one malicious maintainer sneaking a backdoor into a widely-used library, and every project that depends on it inherits that risk. AI meaningfully addresses this by dramatically lowering the cost to bring a dependency in-house. Before, the time and money required to rewrite a library was often prohibitively expensive. Now, with AI, it is feasible to do this in a fraction of the time. If this pattern spreads, it could reshape the attack surface of open-source projects. On one hand, fewer external dependencies mean fewer maintainers to trust and fewer supply chain attack vectors. On the other, AI-generated replacements will initially lack a key benefit of established open-source libraries: having been reviewed and hardened by hundreds to thousands of developers over time. Whether this tradeoff is net-positive will depend on several factors, including whether the original library is actively maintained by trusted parties, the security expertise of the team bringing the dependency in-house, and the risk that the external dependency poses to the project.
Builder Profile: l0rinc
Perhaps one of the most innovative examples of a Verifier is l0rinc (pronounced “Lawrence”), a Spiral grantee who spends much of his time reviewing pull requests for Bitcoin Core.
If you’ve ever done serious PR review, then the problems l0rinc faced will sound familiar. For instance, especially in Bitcoin Core, reviewing a single PR can take weeks and be mentally exhausting, and the change itself may still take years to merge. Furthermore, writing a dedicated benchmark, test, or compiler comparison for a single review could be, as l0rinc put it, “economically irrational” and too time-consuming to justify. The same was often true of other verification artifacts. It simply was not humanly possible to create all of the checks he would have preferred. Additionally, GitHub’s PR interface made things worse: important context was scattered across multiple views, much of the review content was collapsed or hidden behind extra clicks, and there was no way to quickly fact-check claims or understand technical terms inline. On top of all of this, l0rinc noted that some reviewers may fear the embarrassment of being wrong or simply be unsure whether their feedback is correct. Without a way to privately verify your thought process, reviewers either stay silent or risk looking wrong publicly.
True to the Verifier mindset, l0rinc used AI in a risk-minimized, truly innovative way to address each of these pain points.
First, he built ACKtopus, a small personal userscript that augments GitHub’s pull request interface for his own Bitcoin Core review workflow. This is a theme that is increasingly common with advanced AI: building personal (as opposed to general-purpose) applications for your specific needs. In this case, ACKtopus packages a handful of features that l0rinc repeatedly needs during his reviews: one-click expansion of collapsed review content, highlight-triggered AI tooltips for inline explanation or fact-checking, helpers that copy comment context and format it for LLM consumption, and lightweight proofreading tools directly inside the page. It even simulates likely author responses before l0rinc posts the review, allowing him to pressure-test his reasoning privately before going public.
Now is probably a good moment to pause and re-read the above. l0rinc displays a high degree of metacognition here. He clearly understands the pain points of PR review from first principles, and he used AI to create a new review environment around his own workflow, enabling him to produce better feedback, and do it faster.
If this is not impressive enough, l0rinc continues to push the limits of AI further. With this infrastructure in place, he also runs three AI models - Codex, Claude, and Gemini - simultaneously on the same PR context, cross-examining their outputs. While he reviews the PR manually, bottom-up, the AIs go top-down and handle side quests around the review. The review itself remains manual, but the models help him dig deeper by exploring reproductions, tests, benchmarks, and other verification paths in parallel. As l0rinc put it, “Every review is a code-pairing session now. I explain what I learned, the AI explains what it understood, and we call each other out when one of us is provably wrong.” This is not vibe coding for consensus-critical changes. It is a way to double and triple-check suspicions during a manual review. To further verify AI outputs, he cross-posts results between models, increasing the chances that any given model catches a mistake, regardless of whether a human or AI generated it. Having multiple AIs check each other’s work is a popular and effective strategy that we will review more towards the end of the report.
Perhaps l0rinc’s most inventive technique is a kind of air-gapped verification. More specifically, one AI summarizes code changes into a high-level prose description with no implementation specifics. Then, the context is cleared entirely, and a different AI recreates the change from that prose alone. l0rinc compares the recreation against the original, commit by commit. Having multiple implementations helps him understand the change better, and the discrepancies reveal assumptions and bugs that would have otherwise gone unnoticed. He compares it to differential fuzzing. “It recreates the change from the description and tests, then I compare the two commit by commit and look at where they differ. That reveals a lot.”
On top of this, l0rinc generates disposable benchmarks, targeted tests, and other verification artifacts that never get committed. For refactorings, he often compares the generated machine code before and after. For performance claims, he generates benchmarks, recently finding that code was about 3x faster than even the author had realized. He also uses agents to turn manual review findings into automated tests, especially in cases where CI passed even though it should have failed, so the same bug cannot slip through again. Additionally, he uses what he calls “fitness functions” to force AI convergence, instructing agents to run benchmarks, tests, and linters and not stop until all pass, preventing the AI from cheating by deleting a failing test instead of fixing the code. Here, again, we see l0rinc use his knowledge of how AI agents work and design his workflow around that, specifying that the agent must complete each task, verify completion, and not stop until that is satisfied.
This concept of single-use verification artifacts deserves special attention. l0rinc remarks, “We did not have single-use code before. This is completely new.” Before AI collapsed the cost of generating these artifacts, writing a benchmark for a single review was economically irrational. Now it is possible with relatively little effort. The thoroughness budget of software review has fundamentally changed, and properties that were previously checked only by specialized reviewers, or not checked at all, can now be verified much more easily.
As we have seen through l0rinc and others, the Verifier’s metacognitive insight is knowing which risks are worth taking, and designing their workflow around those risks. These developers have mapped exactly which code paths have severe consequences and designed their entire process to respect those boundaries.
The Orchestrator
The architect who designs entire environments for AI to operate in, from multi-agent workflows to custom agent profiles.
While the Verifier largely focuses on using AI to ensure the correctness of code, the Orchestrator designs complex workflows and environments based on how the agents themselves think. They think about what surrounds the model: the documentation it reads, the permissions it holds, the personas it adopts, and the other agents it coordinates with. Remember that builders can adopt patterns across multiple archetypes. For instance, part of l0rinc’s workflow - specifically, having agents work together to produce PR specs and implement code from those specs - would be an Orchestrator activity.
Multi-agent workflows are a hallmark of the Orchestrator archetype. In fact, 28% of all survey respondents reported using multi-agent workflows. That said, not all respondents elaborated in detail on their workflow. While simply running two chat windows side by side could be considered a multi-agent workflow, Orchestrators often have more complex infrastructure. For instance, one Bitcoin security researcher runs five parallel AI agents on a VPS, each with their own sub-agents, coordinating them all through SSH tunnels.
A related skill Orchestrators often leverage is their knowledge of how AI agents work, and they use that information to optimize their interactions with them. For example, a popular technique that builders use is meta-prompting: using AI to compose the prompts that will be fed to other AI sessions.
The reason this is so important is that agents keep all of their working knowledge in their context window - think of this as their consciousness in the given moment. Crucially, AI agents do not think like humans do. While humans have the ability to keep many things in memory but still selectively focus on a few things, agents have much more trouble filtering the signal from the noise. By conducting research and planning with one agent and then moving to a fresh agent session for implementation, you’re able to start clean, allowing the implementation agent to focus on the signal while completing the task. Orchestrators know this, and they confirmed it in their survey responses.
“Quite often I use AI to first discuss and compose the prompt that contains everything I want. Then in a new session, I launch that prompt.”Lightning developer
“I usually have one terminal window with two panes, each with Claude Code. Sometimes, I will use one pane as a meta-agent which is responsible for research, brainstorming, and planning tasks. Then I will hand the tasks over to another agent to ensure that the context window from the meta-agent is not constantly cluttered with the implementation.”Bitcoin education developer
“Meta agent orchestrates sub-agents. Input every 5-10 minutes. Context orchestration via persistent task list, skills, contracts, and git.”Bitcoin protocol developer
Documentation also plays a different role for Orchestrators than it does for most developers. In a typical project, documentation is written for human readers. Orchestrators, on the other hand, write documentation for AI agents as the primary audience. Markdown files describing architecture, constraints, common failure modes, and decisions already made become a core mechanism through which they shape agent behavior across every interaction. This ensures that, even if the developer were to start a fresh session, the agent would have the working knowledge to pick up right where they left off.
“I’ve asked Claude Code to create a memory folder and to consistently save information related to the architecture, website design, teaching methodology, etc. so that it has something permanent to reference.”Bitcoin education developer
One mining protocol developer offered a clear example of building systems around observed AI failures. For instance, they found that models routinely cut corners on implementation and then AIs falsely signal completion (”most of the AIs will create stub functions or empty files, say this thing should go here, and not implement it even though the plan said implement it”). To mitigate this, they built a multi-step pipeline. The main AI orchestrates everything, but it delegates implementation to other agents, ensuring its context window does not get bloated. For example, if there are three tasks to implement, it will spawn three separate agents to work on them in parallel. However, before any implementation begins, it will first launch an agent to evaluate how complex each task is and summarize the findings. This evaluation itself gets reviewed by another agent before implementation proceeds. Finally, once an agent finishes implementing, a separate review agent kicks in automatically to check whether the code actually matches the plan. During our interview, they told me that about 95% of the time the review passes, but 5% of the time, the review agent will catch cases where the implementation agent did not complete the plan.
If that wasn’t impressive enough, this developer’s ingenuity extended beyond multi-agent workflows. They also found that Claude’s built-in context management degrades over long sessions (haven’t we all?), so they built a custom Retrieval-Augmented Generation (RAG) knowledge base with local vector embeddings. They are also experimenting with attention-based key-value cache compression that “removes the things [AI] didn’t pay attention to and compacts it down”, running entirely on GPU. Beyond context management, they built a panel-of-experts review system using a YAML file of well-known bitcoin developers’ names, which triggers the LLM to mirror each person’s style and produce feedback from multiple perspectives. They described the approach as “incredibly effective”, helping the LLM break out of its usual patterns and channel a critical mindset that may be otherwise hard to achieve. Finally, they delegate tasks across Opus, Sonnet, and Haiku (”one of the rules is, you always must delegate to the next tier down”), with Haiku at the bottom handling cheap research, keeping the main session’s context free for higher-value, complex work where models like Opus and Sonnet shine.
Builder Profile: Stephen DeLorme
One of the most vivid examples of an Orchestrator is Stephen DeLorme, a former Spiral grantee who runs ATL BitLab, a Bitcoin hackerspace in Atlanta, and works on moneydevkit.
As the co-founder and operations lead of ATL BitLab, Stephen has a lot of busy-work on his plate: scheduling events, managing finances, curating Bitcoin development news for the ATL BitLab’s BitDevs Radio Hour, and much more. This is all in addition to his other full-time job at moneydevkit. To help manage these responsibilities, Stephen decided to build BOLTy, an autonomous OpenClaw agent that operates as a full-time employee of ATL BitLab. “I basically just said okay, this thing is BOLTy, BitLab operations and logistics technician,” Stephen explained during our interview. Every Monday morning, BOLTy pings Stephen with a status update. Throughout the week, it scrapes Bitcoin Optech and Delving Bitcoin for relevant development news. It monitors the lab’s finances, manages donations through Stripe and Strike, and picks up tickets from the Linear board overnight, as sometimes Stephen will direct BOLTy to work on coding tasks for both personal and professional projects.
You may be wondering, “Does BOLTy just have full access to all Stephen’s data?”. That would be a great question, and the answer is no! Stephen treats agent credential management like an employee onboarding problem. BOLTy has its own email, its own GitHub OAuth apps, its own API keys. It can commit code, but it cannot delete repositories, thus limiting the potential attack surface.
At moneydevkit, Stephen applied the same agentic-first thinking to video production. Specifically, he built a pipeline using Remotion React templates to create social media content for Ori, moneydevkit’s AI agent product. The project includes markdown documentation that teaches agents everything they need to know about character animation. For instance, which character groups exist (recurring casts like “the boys,” “intern chill hang,” and “the girl squad”), how to create a new story, and how to turn a script into a finished video. For voiceover, Stephen uses ElevenLabs with scripts generated by Claude. He even replaced previously manual work in After Effects by having agents handle transcoding via FFmpeg. One crucial insight that Stephen endorses is that he now writes documentation for agents, not humans. “I start to think about projects as AI native first. Don’t have anything in the project that is going to be left up to some engineer knowing something.” When a problem gets solved, the solution gets added to the agent documentation immediately, ensuring the agent gets more reliable and effective over time.
Stephen also helped launch unhuman.store, an agentic commerce platform where AI agents can purchase real-world goods using bitcoin. For example, agents can buy domain names and, most importantly, coffee. The platform uses L402 authentication, a protocol that lets agents pay for API access with Lightning payments. Stephen sees this as early infrastructure for a world where agents transact autonomously, and he was struck by how the community forming around agentic tools reminded him of earlier open-source movements: “I was kind of shocked when it was this decentralized open-source movement. It reminded me a lot of the web itself. And similar to Bitcoin, too.”
Stephen spoke to AI’s impact directly when he said, “Stuff that would take a week now takes 2 hours. Projects that would previously require contractors, vendors, or collaborators with specific skillsets can now be accomplished alone.”
Stephen’s metacognitive skill, and the Orchestrator’s more broadly, is building the agentic harness: the infrastructure around the model itself that helps it become maximally effective. For instance, agent identity systems, AI-native documentation, multi-agent delegation patterns, and Remotion React templates. The Orchestrator has internalized that the model is simply one piece of a larger puzzle, and to build truly innovative products and services, you need to look at the full picture.
The Upskiller
The learner who uses AI to rapidly acquire knowledge in any unfamiliar domain.
This report would be incomplete if it solely focused on how AI helps ship code faster. In fact, some of the most interesting and directly reproducible stories in this study aren’t about code at all. Instead, they’re about how AI helps people learn things that would have previously taken months, but now take weeks, if not days. Of course, this is not to suggest that AI replaces learning - it does not! Instead, it dramatically assists learning by both acting as an always-available expert and a tutor that can teach you how you learn best, creating custom educational material just for you. The Upskiller is the archetype of someone who knows this power exists, and they use AI to rapidly level up their skills and knowledge so they can be more effective in their work.
This archetype showed up clearly in the survey data. For instance, respondents who reported high productivity multipliers (5x, 10x, or higher) almost always attributed those gains to tasks outside their primary domain. In fact, in some cases, respondents reported that AI enabled them to dig into complex concepts that they would have never even attempted to before.
“5x progress, 10x when working outside things I already know.”Lightning developer
“It allowed me to dig into issues I could not have before, or simply would have taken too much time to dig into to make it worth my time.”Bitcoin library developer
One of the most common Upskiller patterns is using AI to learn unfamiliar programming languages. Several developers reported that AI has fundamentally changed their relationship with languages outside their core stack. Rather than spending weeks working through tutorials or shying away from building outside of their core expertise, respondents reported using AI to help them build their understanding of new languages and venture into new tech stacks.
“Especially in my transition period of learning C++, Claude reduces my debugging time by an order of magnitude.”Bitcoin protocol developer
“I wrote a dashboard where I send my nightly build results to. This uses lots of JavaScript and SQL logic that I would not be able to write without AI.”Bitcoin protocol developer
“For tech I don’t know well like Kubernetes dev ops and HTML+CSS work it’s 0 to 1, I would be stuck and frustrated if I didn’t have it to help.”Bitcoin library developer
AI also serves as a powerful onboarding tool for unfamiliar codebases, a use case that matters especially in open-source projects where documentation can be sparse and the original authors may not be available.
“Another good use case is getting up to speed with a new codebase like LDK. I can learn the codebase faster because now I can just query the AI.”Lightning developer
“I am able to move forward with tasks that have deeper technical debt quickly in a big codebase as it helps understand the culture of the codebase.”Lightning developer
One Lightning developer took codebase understanding to another level by using AI to analyze how different Lightning Network implementations interpret the same specification. The Lightning Network is defined by a set of specs called BOLTs, and when two implementations interpret a spec differently, the result can be a force closure, an involuntary shutdown of a payment channel. This Lightning developer described how they ask Claude to examine how other Lightning implementations approach a given part of the spec, then compare that against their own approach to make sure they are in sync. They also run a Lightning node and open channels to nodes on other Lightning implementations. When they hit a force closure, they pull up Claude with the exact error message and ask it to look across the other codebases to find the cause: “Now I can understand cross-compatibility issues much faster across other Lightning implementations.” Their hope is that “this leads to more cross-pollination, where Lightning engineers move and work freely across implementations using AI.”
That same Lightning developer also devised a context management technique for longer projects. At each major milestone, they instruct the AI to write a debrief file documenting the biggest takeaways, lessons learned, pitfalls, and any concerns about the overall direction of the project. Then they completely clear the context window and start a fresh session, loading the debrief into the new conversation. This is how they described their workflow to me: “I treated the AI a little bit like an entry level software engineer, and also a human being that needs to sleep.” Similar to how a brain consolidates memory during sleep, the debrief process forces the AI to distill what matters before the context resets.
As any experienced professional knows, a crucial part of personal development is having good mentors and co-workers. Unfortunately, forging these relationships can be particularly difficult in open-source communities, but some respondents reported using AI to fill that gap.
“I use Goose as my rubber duck research helper. One of the challenges of working in a non-office environment is the lack of the quick and easy, ‘hey is this even a good idea?’ feedback.”Bitcoin library developer
“Many questions I have historically asked busy, smart developers I can now ask AI, which helps me refine what I ask of other busy, smart developers.”Product manager
“Using AI chat often feels like having another coworker who’s always available to talk through ideas or answer questions, which has dramatically improved my focus and output.”Product manager
Builder Profile: Sivaram
One of the deepest examples of an Upskiller in this study was Sivaram siv2r, a Spiral grantee and cryptography engineer who focuses on cryptographic protocols like FROST Signing, ChillDKG, Schnorr adaptor signatures, and batch verification. Sivaram holds an M.Sc. in Mathematics and Computing from IIT Kharagpur. During our interview, he described how, as a student, he’d seek out math-savvy friends at the university to think through hard problems together. After graduating, he lost that resource.
“I used to go to my friend who was better at math than me and brainstorm with him, but then once I graduated I did not have such person.” Recently, Sivaram decided that he wanted to learn the technical nuances behind the post-quantum cryptographic primitives and the new protocol changes being proposed for bitcoin. Given that this is not Sivaram’s main focus for his day-to-day tasks, he did not want to continually engage his already-busy colleagues to help him learn. So, Sivaram decided to take a different approach: use AI to create an on-demand resource to help him upskill.
The main AI tool that powered Sivaram’s personal learning experience was NotebookLM. When he decided he wanted to understand the post-quantum cryptography landscape, a topic that was evolving rapidly across bitcoin dev mailing lists, he used NotebookLM’s “Deep research” feature to automatically pull in relevant discussions. “I pointed it to the dev mailing list, asked it to find the post-quantum related threads, and added those as my sources.” From there, NotebookLM was able to generate custom podcast overviews of varying levels of technical details, structured data tables listing concrete algorithms and their associated specs, and customizable quizzes to test understanding. The result was truly impressive, and Sivaram was excited by how fast he was able to catch up on the conversation: “I learned all this information in just a few days. Without it, I’d have spent several weeks minimum going through the dev mailing list and Googling every new concept I came across.”
The second tool Sivaram uses to upskill is Gemini Pro, which serves as an on-demand math mentor. He told me: “I tried asking it questions, how does this proof work? Surprisingly, it was accurate. It was able to reason well enough. It was not hallucinating.” He uses Gemini Pro’s Guided Learning mode for dedicated math and cryptography sessions, working through proofs and unfamiliar topics until he deeply understands them. But rather than letting those insights fade after the session, he exports the full conversation into his Obsidian vault using an AI chat exporter extension and then runs a custom Claude Code skill called /write-mental-model to distill the conversation into a focused markdown note capturing the core “aha moment,” complete with LaTeX equations and Excalidraw diagrams. The skill was trained on his own prior notes, so it writes in his voice and matches his format. Before this pipeline existed, writing up what he learned was a manual grind: formatting LaTeX, drawing diagrams, structuring the note. That grunt work is now eliminated. He is also integrating notebooklm-py, an open-source Python client for NotebookLM, which will let him programmatically feed his vault notes into NotebookLM for deep research on related topics, bringing his accumulated knowledge and his ability to explore new territory even closer together. Obsidian’s wikilinks, bidirectional links between related notes, give both Sivaram and his AI tools a navigable web of connected concepts to reason over, rather than a flat pile of isolated documents.
The third tool Sivaram mentioned was Claude Code, but its role has expanded far beyond writing code. Through a plugin called Superpowers, he uses a sub-agent-driven development approach: “It basically splits the task into small chunks. It will have a sub-agent instance generating code and it’ll spawn another instance that verifies this code.” He still manually verifies every line. But Claude Code now also serves as the engine that built and maintains the Obsidian vault itself. It designed the vault’s folder structure, frontmatter schemas, and template routing system. It migrates his old Notion pages into properly structured knowledge notes. A second plugin, claude-mem, gives Claude Code persistent memory across sessions, so context from one conversation carries into the next. And a custom /session-wrap-up skill generates a dense summary of each work session, capturing design decisions, debugging insights, and reasoning state as documentation that future Claude sessions can read for context. The result is that Claude Code has evolved from a coding assistant into the primary tool for building and curating Sivaram’s entire knowledge system.
Sivaram’s use of AI here is inspiring. Yet, we must be careful not to draw the wrong lessons from his story. Yes, there are certainly many tools that we can use to replicate his setup, and we’d very likely experience a meaningful productivity boost. But tools change and things move fast in this new world of AI. The metaskill that we should take here is that Sivaram designed a learning workflow that was unique to his needs. NotebookLM analyzed the sources, but Sivaram directed the search and specified the output formats that were best suited to help him learn (podcasts, quizzes, .md files, etc.).
Sivaram’s metacognitive skill, and the Upskiller’s more broadly, is that they know how they learn best, and they use AI to enhance that process. They don’t just ask AI for answers. They design learning environments that are optimized for both their learning styles and how agents interact with the world, and the results speak for themselves.
The Hyper Coder
The rapid prototyper who ships things that didn’t exist before.
Alas, we arrive at our final archetype: the Hyper Coder. This archetype is probably the least difficult to explain: anyone with access to a sufficiently advanced generative AI model has felt the power of being able to build with natural language. Perhaps paradoxically, while Hyper Coders experience the largest productivity boost, it is often impossible to quantify. Once again, they go from 0 to 1, building products and services that would literally have not existed before AI. This does not mean that Hyper Coders are non-technical. They span a wide variety of backgrounds, including designers, project managers, and developers.
When looking at the survey data, there was plenty of evidence that AI was changing what people thought was possible.
“There is literally no way I could do either of these without the use of AI. An average app I build in an afternoon would literally have taken me months to build previously so the leverage is something like 100-1000x if not greater.”Product manager
“Essentially, I am able to act as a full stack engineer, designer, and product owner. Many of the things I am able to accomplish now would have simply been impossible before AI, because I did not have the technical skills to do all of this in a reasonable amount of time.”Bitcoin education developer
Once again, this pattern isn’t limited to engineers working outside their stack. Non-developers are building software for the first time, and the experience is transforming how small teams operate.
“AI has expanded what I think I’m capable of. It encourages more experimentation and learning. On a small team, that’s extremely valuable. Previously we relied much more on designers, web devs, or volunteers to help bring ideas to life.”Product manager
One technique worth highlighting is shaping the AI’s output by injecting branding and identity into the initial prompt, giving the agent a sense of what the product is before asking it to build anything.
“I like injecting my initial prompt with some branding, naming, even logo, as I’ve noticed this helps shape the coding agent’s own conception of the product and how it comes together.”Product manager
This is a subtle but important insight about how agents work. Rather than describing features in isolation, builders are learning that giving the agent context about the product’s identity, branding, and logo will produce meaningful improvements in the result. In other words, when we realize that agents don’t know things that we don’t tell them, we begin crafting better prompts and achieving better outcomes.
Builder Profile: Christoph Ono
One impressive example of Hyper Coding came from Christoph Ono, a Spiral grantee and co-founder of the Bitcoin Design Foundation. Don’t get me wrong, Christoph is certainly technical, having begun his career as a website developer before shifting into the world of design. That said, he has been using AI to build products beyond what would have previously been possible. One of his current projects is Arke, a Bitcoin wallet for iOS. While Christoph had built a few iOS apps over a decade ago, he hadn’t touched iOS development since. In other words, he is not an iOS expert. And yet he is building a full Bitcoin wallet in Swift, using Claude integrated with Xcode, on a cutting-edge protocol. During our interview, he told me: “I’m doing very particular things with a very particular cutting edge protocol where there aren’t really any good examples. It’s not like this has been built a million times.”
Part of what makes Christoph successful is that he builds his workflow with both humans and agents in mind - tight feedback loops and small, discrete tasks. “I’ve always tried to work in very small pieces, just very narrow definitions, like okay let’s figure out what this type of system could look like. I never just tell AI to do stuff and come back a few hours later. That’s never worked for me.” This is not a fully autonomous agent approach. Every interaction is a focused conversation where Christoph provides creative direction and the AI executes within that frame.
Another reason Christoph is successful is that he understands where AI cannot replace humans. For example, when designing the display screen for an Arke wallet balance, Christoph replaced the standard asterisk-based privacy screen (the kind you see on many bitcoin or banking apps) with a smooth and peaceful AI-generated image of a Tuscan landscape. This is how he describes his decision: “When I actually replace it with this, I generated a Tuscan landscape, it feels different. It feels more private.” His decision wasn’t based on technical specs. It was based on emotion. The app shouldn’t simply make the balance hidden, it should invoke a feeling of privacy within the user. This is a fundamentally different skillset that AI does not have. Will it, through enough data and training, eventually have the ability to produce visuals that spark the desired emotions in humans? Who knows! But, for now, to successfully leverage AI for design, the builder must be connected to the human experience.
When I asked Christoph how he designs products that resonate with people, he emphasized two things. The first is that some design fundamentals are timeless: “Certain things just never change. You have human psychology, you have human behaviors, needs, desires. Typography doesn’t change. The basics of layouts and color perception.” The second is paying careful attention to how people actually behave. “I take the bus and subway. How do people consume? I see everyone just doing TikTok and YouTube reels.”
Based on Christoph’s observation of human behavior, he decided to create an AI-generated visual pipeline for Arke. Specifically, instead of having users read a bunch of introductory text (which most people skip), he decided to create AI avatars that tell people what they need to know. Think of scrolling through an onboarding TikTok-like experience! Building this pipeline wasn’t straightforward, and the tech required to do it has been changing rapidly. Early AI image generation was unusable for the kind of production quality Christoph needed. In our interview, he recalled his experience of using AI image generation in the early days: “That was in the time of seven fingers and faces morphing into hands.” For example, when designing the visuals for Saving Satoshi, he would find himself generating 70+ images of a character, and the person would still look different in each image, making it almost impossible to create multiple scenes with the same character. However, Midjourney character sheets changed that: “We got to a point where I could create character sheets, and that really allowed me to get much more specific.” With consistent characters in hand, he combined Midjourney with Argil for lip-synced video avatars and ElevenLabs for voice synthesis to bring the TikTok-style onboarding vision to life. With these tools, he is now able to produce marketing videos in a day and a half - work that would have previously required a traditional production pipeline taking weeks.
Just as we’ve seen with past Builder Profiles, Christoph exemplifies multiple archetypes at once. Here, we see him also leaning into the Orchestrator, leveraging multiple AI tools and designing his workflow around the agentic infrastructure. For example, to keep all of his AI use cases coherent across sessions, Christoph built roughly 50 markdown documentation files, asking the AI to document itself at each stage. “For every system in here, for the architecture, for network configuration guide, or the BDK integration status, I ask it to document itself.” It’s the same documentation-as-memory pattern we saw in the Orchestrator section, but applied specifically to preserving design intent and architectural decisions so the AI doesn’t lose the thread of what Arke is supposed to feel like.
During our conversation, Christoph made an observation that I encourage everyone to meditate on. Specifically, he described what he believes to be an asymmetric skill transfer. He told me: “A bunch of designers that I’ve known that never touched code, they now feel like a barrier is broken. I haven’t really heard the same of a developer saying, ‘a barrier is broken. I can design.’” In other words, coding barriers are falling faster than creative barriers. As AI commoditizes code generation, design thinking and taste may become asymmetrically more valuable.
If that isn’t enough to think on, our conversation ended with a bit of a warning for the future. Christoph described a future where the internet is inundated with apps that nobody uses: “Everybody builds average stuff faster and we have more people building average stuff.” This is tangentially related to Dead Internet Theory, which suggests that the internet will become a wasteland of AI content, crowding out anything generated by a human. How do we mitigate this? I’m not sure. That said, since everyone seems like they are going to produce AI-generated content nonetheless, you should focus on building something that solves real problems and sparks real (positive!) emotion within people.
The Metacognitive Thread
Four archetypes, one underlying practice.
The fascinating meta-finding from this report is that the builders who were making the most of AI were actually adjusting their workflow to better align with how AI “thinks.” For example, agents process information sequentially (as opposed to in parallel), have finite context windows that degrade over time, don’t always retain memory of everything between sessions, and often perform better with structured input and explicit directions. The most effective builders in this study understood these constraints, and they used that knowledge to build better agentic environments. In many ways, they had two end users: the actual human at the other end of the product or service, and the agent that they are collaborating with to build that product or service.
One helpful lens to view this through is that of Human-Computer Interaction (HCI), a multidisciplinary academic field that studies how people interact with computers. This discipline focuses on building interfaces and products that allow humans to more seamlessly and effectively interact with computers, paying specific attention to how humans interpret the world. For instance, humans have limited working memory, the ability to selectively focus their visual field while also retaining peripheral vision, and certain cognitive biases. The field of HCI builds on these premises and uses that knowledge to design better interfaces, products, and even wearable technology.
The most effective users of AI are extending HCI to agents, a practice some are calling Agentic Computer Interface (ACI). Within this framework, the focus shifts to how we design interfaces so that agents can better interact with computers. This is where many of the tools and techniques from this report come into play: agent-focused documentation that gives the AI persistent context across sessions, scoped permissions and credentials that define what the agent can and can’t touch, multi-agent delegation patterns that keep context windows focused, fitness functions that force the agent to verify its own work, and custom tooling like browser extensions and MCP servers that extend what the agent can see and do. Each of these is an ACI design decision, shaping the environment so that the agent can do its best work.
If you’re dissatisfied or still unconvinced that metacognition is the most important skill, I’ll end with this question: How do you learn how to use a tool that is being invented in real-time?
You take a step back and ask questions. How does the tool work? How can I integrate it into my workflow? What new workflows does it enable? How do I know if I’m producing anything valuable? These questions will also help you evaluate and use the next AI tool, since it’s likely that some of the tools and workflows discussed in this report will be irrelevant by the time you’re reading it. This is precisely why metacognition is the skill that matters most. While most tools are temporary, the ability to ask questions, evaluate your process, and iterate your approach will remain constant.
Three Actionable Steps
With that in mind, below are three steps that recurred across the most effective builders.
1. Name It, Then Go Meta
One small, yet effective, habit you can develop when using AI is simply naming problems when they occur.
Jesse Posner, CEO of Vora, a privacy-focused AI startup, wrote about this concept in a blog post in early 2026. When something isn’t working in an AI interaction, the most effective move is to name the problem explicitly, out loud, in the conversation, and then go meta on the interaction itself. Instead of re-prompting and hoping for better results, you debug the conversation the same way you’d debug code.
While this may sound somewhat esoteric, it’s actually a pattern we’re all very familiar with. For instance, you’ve likely been in a conversation before where there was lots of unspoken tension. Nobody explicitly named the tension, but everyone felt it. This is a deeply human experience, and that’s exactly the point. Agents do not feel the underlying emotion of the conversation. They have no conception of things that are outside of their context window.
If you understand how agents work, you can bring the unspoken into the conversation by naming it. One respondent reported using this technique to address a problem where the agent was continually “forgetting” what it had completed as it compacted its context window over time. The respondent decided to bring this issue into conversation with the agent, naming a problem that the agent would have otherwise been completely unaware of. When prompted with this information, the agent recommended saving specific workflows to markdown files so that future agents would “remember” important decisions and frameworks from past discussions, allowing it to continue replicating specific processes in future sessions.
2. Build Your Harness
Once you “Name It, Then Go Meta,” you may find, just like the example above, that the best way to improve your output with AI is to build a harness around your agent. This is ACI in practice. But what exactly is a harness?
While the term “harness” is not (yet?) a textbook academic term, it’s been gaining traction across the applied AI engineering landscape, appearing in articles from major AI providers and engineers I find on Twitter.
More specifically, a harness is everything that shapes and constrains a Large Language Model’s behavior, enabling models to become truly effective at executing tasks from inception to completion. For instance, harnesses include documentation and permissions that define what the agent can and can’t do, the tools it has access to, the personas it adopts, and the verification loops it must pass through before its work is accepted. Each of these constraints addresses a fundamental limitation of LLMs: on their own, they don’t remember between sessions, they struggle to filter signal from noise in large context windows, they have no sense of what they’re allowed to touch, and they can confidently produce nonsense when they lack the right information. Without a harness, you’re relying on an individual prompt to compensate for all of these limitations.
There are many ways to build a harness, and the right approach depends on your workflow. In the survey, documentation files were a common starting point. For example, markdown files describing architecture, constraints, and decisions already made. Builders also reported using context management strategies (clearing context at milestones, delegating research to sub-agents), scoped permissions and credentials (giving agents their own accounts with limited access), custom tooling (browser extensions, MCP servers, git hooks as guardrails), and even RAG knowledge bases that give agents searchable long-term memory.
The important takeaway here is that you should not rely on prompts alone. To truly achieve step-change results, you’ll need to pay attention to your agent’s environment.
3. Tips and Techniques
If you’re interested in specific AI workflows that you can test in your own projects, then below are a few that Spiral grantees and team members found useful. Remember, AI is changing every day, so it’s on you to decide if these are now outdated and if they work for you!
Write documentation for AI, not just for humans. Many survey respondents cited this as a very effective addition to their workflow. Create a markdown file (or multiple) in your project that describes the architecture, constraints, design themes, agent personas, known failure modes, or decisions already made. “When a problem gets solved, that gets added to the agent documentation,” as one developer explained to me.
Plan first, then implement in small pieces. We often hear stories of people “one-shotting” an AI build. What isn’t frequently discussed is the planning that goes on before implementation. If you’re working on an ambitious build, start in plan mode or a conversational discussion to get the AI to articulate what it will do before it builds anything. If your project is particularly complex, have multiple AI agents work on it together. You can do this by starting the plan implementation with one agent (Claude) and then asking it to save the plan to a markdown file and produce a prompt that you can hand to another agent (Codex), instructing the new agent to critique the plan and provide feedback. Repeat these steps until both agents agree on the implementation plan.
Set up fitness functions: “don’t stop until tests pass.” Instead of asking AI to write code and then manually checking if it did so successfully, give it a measurable exit condition. One developer mentioned this in their interview: “I instruct it to run the benchmarks, run the tests, run a linter. Don’t stop until all of these are reporting that you’re fine, and that’s how it converges.” Another developer took a more agentic approach to this, using the superpowers skill, which splits work into small chunks and spawns separate sub-agents for implementation, review, and testing, automating the verify-as-you-go loop without the developer having to manage it manually.
Use AI to explore unfamiliar codebases. Multiple respondents independently reported this as a major capability unlock. “Now I can understand cross-compatibility issues much faster across other Lightning implementations,” one developer reported. Another: “I can learn the codebase faster because now I can just query the AI, and the AI will do exactly git grep, but in a way much faster.” Point an AI agent at an unfamiliar repo and ask it questions about architecture or anything you’d like to learn about. It won’t replace deep understanding, but it dramatically compresses the onboarding period.
Cross-check with multiple models. When the stakes are high or the task is sufficiently complex, run the same task through multiple models and investigate where they agree and disagree. “I often get Codex to question what Claude did and vice versa, eternal search for truth,” one developer wrote. This can be particularly helpful if you’re running into a bug or feature that your chosen model is not making progress on. If this happens, go meta. Take a step back and explain to the AI that you are running into an issue. Describe your new plan, indicating to the agent that you want it to summarize its progress and attempt to define the problem. Instruct the agent to save the analysis to a markdown file and provide a prompt so that you can hand it off to another model. Then, go back and forth with the models until they can agree on the problems and solutions.
Manage your context windows. It’s well known that AI quality degrades over long sessions as the context window fills up. Rather than accepting the degradation, developers reported clearing context at milestones and starting fresh. As a helpful analogy, you can think of an agent’s context window as its working consciousness. If it fills up with information for a wide variety of tasks or disparate parts of a code base, it will have lots of trouble identifying the signal in the noise when it attempts to respond to one of your requests. In these situations, it can be very helpful to ask AI to create a new prompt for you with all of the relevant information you need to continue the conversation in a fresh session. This will provide your new agent with a working consciousness that is scoped to only the information you want it to be “thinking” about.
In Closing
There is a famous saying that aptly describes this moment in AI: “It’s difficult to make predictions, especially about the future.” The truth is, everything is changing incredibly fast, and the tools you learn today may be outdated in the next six months. With that said, I will make a prediction of my own! Anyone who adopts an entrepreneurial, metacognitive mindset will do just fine in the age of AI. This is true now, and will be true tomorrow. Always has been.
This report was produced by Austin Krauss, a Spiral grantee. Survey data was collected from 50 Spiral grantees and team members, and eight in-depth interviews were conducted and analyzed. All statistics reflect self-reported data from the survey respondents.
https://www.binance.com/activity/trading-competition/menaexcairdrop?ref=1013360036&utm_medium=web_share_copy