Gamers Forem

How to Prepare a Legacy Codebase for AI-Assisted Refactoring

137Foundry — Sat, 09 May 2026 11:09:29 +0000

Jumping into a legacy codebase with an AI coding assistant and no preparation produces predictably mixed results. The AI generates plausible-looking refactors that miss critical business logic embedded in unexpected places. You spend more time verifying output than the AI saved you in generation time. And the refactored code, while cleaner-looking, may have subtle behavioral changes that surface in production six weeks later.

The difference between this outcome and a productive AI-assisted modernization session is preparation. Specifically: giving the AI the context it needs to reason correctly about your specific codebase rather than reasoning from generic patterns.

This guide covers the preparation steps that make AI-assisted legacy refactoring significantly safer and more productive.

Step 1: Establish Scope and Document It

Before any AI interaction, define the boundary of what you are working on. Legacy codebases have a way of expanding scope because everything touches everything. Resist this.

Choose a specific module, class, or set of related functions as your working scope. Write a plain-language description of what that scope is responsible for:

Scope: the discount calculation module (discount.py, approximately 400 lines)
This module is responsible for: calculating the final price a customer pays
after applying applicable discounts, promotions, and loyalty tier benefits.

It is NOT responsible for: fetching customer tier data (done by customer_service.py),
validating promo codes (done by promo_validator.py), or applying tax (done post-discount
by tax_calculator.py).

The most important business constraint: discounts do not stack additively.
A customer with a 20% loyalty discount and a 15% promo code gets 20% off, 
not 35% off. This is intentional and must be preserved in any refactoring.

This description becomes the context header you paste before every AI prompt related to this module. It costs you twenty minutes to write; it saves you from explaining the same context to the AI repeatedly and catching errors that stem from the AI not knowing the "discounts don't stack" rule.

Step 2: Audit Dependencies Before Touching Anything

AI coding assistants will generate refactored code that changes function signatures, return types, or module interfaces without knowing what depends on them. Before you start refactoring, you need a dependency map.

For Python codebases, tools like Python's built-in ast module and import analysis scripts can generate call graphs. For JavaScript, ESLint and module analysis tools serve a similar purpose. GitHub advanced search can help you find all internal references to a specific function across a large repository.

The AI can help with this phase, but its output should be treated as a starting point:

Identify all the places this function is called in the following files.
For each call site, note:
1. The file and line number
2. How the return value is used (stored, compared, iterated over, etc.)
3. Whether the caller passes keyword arguments or positional arguments

[target function] [relevant surrounding files]

Review the AI's output carefully. Dynamic call patterns (calling functions stored in dictionaries, factory patterns, monkey-patching) will not appear in AI dependency analysis. These need manual identification.

The dependency map serves a critical purpose: before you change a function signature or return type, you know what you need to update. Without it, you are refactoring blind.

Step 3: Create a Test Baseline

Legacy code with no tests is the most dangerous to refactor because you have no automated way to verify that behavior is preserved. Before any refactoring, use AI to generate an initial test suite for the module you are working on.

This is one of the highest-value uses of AI assistance in legacy modernization. Even imperfect AI-generated tests are faster to produce than writing them from scratch, and they provide a safety net that makes subsequent refactoring significantly lower-risk.

Important: AI-generated tests tend to cover the happy path and obvious error cases well, and miss edge cases that emerged from production incidents. After getting the AI-generated test suite, review your issue tracker, Git blame history, and incident reports for the module. Add tests for any bugs that were fixed in the module's history - those are the edge cases most likely to be reintroduced by refactoring.

Once your test baseline is in place, configure your CI pipeline to run these tests on every commit. This gives you immediate feedback when a refactoring breaks behavior.

Step 4: Identify and Document the Critical Paths

Not all code in a legacy system is equally risky to modify. The critical paths are the execution flows that:

Handle money or anything irreversible (payments, emails sent, database deletes)
Run under high load or in performance-sensitive paths
Have known security relevance (authentication, authorization, input validation)
Have produced incidents or bugs in the past

These are the paths where AI-generated refactors need the most careful human review. Document them explicitly before starting:

Critical paths in discount.py:
1. Lines 145-190: Final discount application to cart total - this writes to the order record
2. Lines 210-230: Promo code validation bypass for internal employee accounts - security-relevant
3. Lines 280-310: Bulk discount calculation - runs for every item in large orders, performance-sensitive

When AI-generated refactors touch lines in this list, they get extra review. When they do not, you can move faster. This simple classification reduces the time you spend being careful about everything and focuses attention where it matters.

Photo by Bernice Chan on Pexels

Step 5: Set Up a Safe Experimentation Environment

Before merging any AI-assisted refactoring, you need a way to run the original and refactored code side-by-side and compare behavior. The ideal setup:

A feature branch where AI-assisted changes are isolated
Your test baseline running against both the original and the refactored code
If the module has external side effects (database writes, external API calls), a way to stub those out for comparison testing

Martin Fowler's branch-by-abstraction pattern is useful for large-scale refactoring: introduce a seam that lets you run old and new implementations in parallel and compare results before fully switching.

For simpler modules, a straightforward A/B test in a staging environment - routing a portion of traffic to the refactored implementation - gives you confidence before full deployment.

Putting It Together

The preparation sequence - scope definition, dependency audit, test baseline, critical path identification, safe environment setup - takes time. On a module of moderate complexity, expect to spend a day on preparation before writing a line of refactored code.

That investment pays back quickly. With context documents, a test baseline, and a dependency map in hand, each AI-assisted refactoring session produces output that is faster to review, safer to merge, and less likely to produce production incidents.

For the full framework on running these sessions - including prompting patterns for the refactoring phase itself - the guide on using AI coding assistants for legacy code modernization covers the end-to-end process.

137Foundry works with engineering teams on legacy modernization assessments and implementation. The 137Foundry AI automation services include preparation consulting for teams starting this process for the first time.

Prettier and ESLint are useful tools for establishing consistent code style as a baseline before starting structural refactoring - style differences in a diff make behavioral changes harder to spot. OWASP provides useful checklists for security-critical code review that apply directly to the critical path review step.

Legacy modernization done well is not fast. But with the right preparation, AI assistance makes it substantially less expensive than it used to be.

Stop Paying for Invoice Software. This Free Tool Runs Right in Your Browser.

Tharindu Dulshan Fernando — Sat, 09 May 2026 11:07:50 +0000

No subscriptions. No accounts. No data sent to anyone. Just open it and start invoicing. Link : https://invoicegeny.com/

If you run a small business, freelance, or do any kind of client work, invoicing is one of those necessary evils. You need professional-looking invoices, but the tools that create them either cost money every month, require you to create an account, or lock your data behind a login.

Invoicegeny is a free alternative that works differently. It runs entirely in your web browser. No sign-up, no subscription, no data ever leaving your device. Open it, set it up once, and start sending invoices in minutes.

Your Data Stays on Your Device

This is the biggest difference from every other invoicing tool.

Apps like FreshBooks, Wave, or QuickBooks store your business data on their servers. That means your client list, your pricing, your revenue, all of it lives somewhere you don’t fully control. If they change their pricing, get acquired, or shut down, you have a problem.

Invoicegeny stores everything in your browser’s local storage, the same place your browser saves your preferences and history. Nothing is sent to any server. Nothing is stored in the cloud. Your data is yours, period.

Set It Up Once, Use It Forever

The first thing you do is fill in your Seller Profile. This is your business info: name, logo, address, email, phone, tax ID, default tax rate, service charge, and bank account details. You fill this out once. Every invoice you create pulls from this profile automatically.

You can save multiple bank accounts and pick the right one per invoice with a single click. Currency is fully configurable — USD, EUR, GBP, LKR, and dozens more are supported out of the box.

Customers and Products - Managed, Not Re-Typed

One of the most tedious parts of manual invoicing is re-entering the same customer details and prices over and over.

Invoicegeny has a proper customer list and product catalogue. When you create an invoice, you search for the customer by name, phone, or email, it finds them instantly. Same with products: search, click, and the item appears on the invoice with the right price already filled in.

Adding the same product twice? It just bumps the quantity. No duplicate lines. If a customer or product doesn’t exist yet, you can add them right from the invoice creation screen,no need to go to a separate page first.

Create an Invoice in Under a

Minute

Once your profile, customers, and products are set up, creating an invoice is straightforward: pick a customer, search and add products, choose a payment method (Cash, Card, or Bank Transfer), set a due date, add any notes, and click “Save & Download PDF”.

A professionally formatted PDF downloads to your computer instantly, with your logo, your business details, the itemised list, tax, service charge, and total. Ready to send to your client.

Invoice numbers are assigned automatically in sequence (INV-0001, INV-0002…) so you never have to think about it.

The PDF Looks Professional

A lot of free invoice tools produce PDFs that look like they were made in 2003. This one doesn’t.

The generated PDF includes your logo in the top left corner, your business name and contact details next to it, “INVOICE” prominently on the right with the invoice number and dates, a clean items table with alternating row shading, an itemised totals section showing subtotal, tax, service charge, and the final amount, payment details at the bottom, and a footer.

It’s the kind of invoice that makes you look established and professional, even if you’re a team of one.

Track the Status of Every Invoice

Your invoices list shows every invoice you’ve created with its current status: Draft, Sent, Paid, or Overdue. You can update the status with one click. It’s a simple but effective way to know at a glance what’s been paid and what you still need to chase.

Press enter or click to view image in full size.

Who Is This For?

This tool is a great fit if you are a freelancer (designer, developer, photographer, writer, consultant) who invoices clients directly, a sole trader or small business, someone who values privacy and doesn’t want their business data on third-party servers, someone tired of paying a monthly fee for a feature they only use occasionally, or operating in any country — multi-currency support is built in.

Completely Free. Forever.

There’s no free tier with limits. No premium plan. No credit card required. The tool has no server costs because it has no server. It’s free to use because there’s genuinely nothing to charge for.

Open the app, fill in your seller profile, add a couple of customers and products, create your first invoice, and download the PDF. The whole setup takes about five minutes. After that, invoicing takes under a minute per client.

To try you can visit → https://invoicegeny.com/

The AI Hype Crisis

Tim Green — Sat, 09 May 2026 11:00:00 +0000

In June 2024, Goldman Sachs published a research note that rattled Silicon Valley's most cherished assumptions. The report posed what it called the “$600 billion question”: would the staggering investment in artificial intelligence infrastructure ever generate proportional returns? The note featured analysis from MIT economist Daron Acemoglu, who had recently calculated that AI would produce no more than a 0.93 to 1.16 percent increase in US GDP over the next decade, a figure dramatically lower than the techno-utopian projections circulating through investor presentations and conference keynotes. “Much of what we hear from the industry now is exaggeration,” Acemoglu stated plainly. Two months later, he was awarded the 2024 Nobel Memorial Prize in Economic Sciences, alongside his MIT colleague Simon Johnson and University of Chicago economist James Robinson, for research on the relationship between political institutions and economic growth.

That gap between what AI is promised to deliver and what it actually does is no longer an abstract concern for economists and technologists. It is reshaping public attitudes toward technology at a speed that should alarm anyone who cares about the long-term relationship between innovation and democratic society. When governments deploy algorithmic systems to deny healthcare coverage or detect welfare fraud, when corporations invest billions in tools that fail 95 percent of the time, and when the public is told repeatedly that superintelligence is just around the corner while chatbots still fabricate legal citations, something fundamental breaks in the social contract around technological progress.

The question is not whether AI is useful. It plainly is, in specific, well-defined applications. The question is what happens when an entire civilisation makes strategic decisions based on capabilities that do not yet exist and may never materialise in the form being sold.

The Great Correction Arrives

By late 2025, the AI industry had entered what Gartner's analysts formally classified as the “Trough of Disillusionment.” Generative AI, which had been perched at the Peak of Inflated Expectations just one year earlier, had slid into the territory where early adopters report performance issues, low return on investment, and a growing sense that the technology's capabilities had been systematically overstated. The positioning reflected difficulties organisations face when attempting to move generative AI from pilot projects to production systems. Integration with existing infrastructure presented technical obstacles, while concerns about data security caused some companies to limit deployment entirely.

The numbers told a damning story. According to MIT's “The GenAI Divide: State of AI in Business 2025” report, published in July 2025 and based on 52 executive interviews, surveys of 153 leaders, and analysis of 300 public AI deployments, 95 percent of generative AI pilot projects delivered no measurable profit-and-loss impact. American enterprises had spent an estimated $40 billion on artificial intelligence systems in 2024, yet the vast majority saw zero measurable bottom-line returns. Only five percent of integrated systems created significant value.

The study's authors, from MIT's NANDA initiative, identified what they termed the “GenAI Divide”: a widening split between high adoption and low transformation. Companies were enthusiastically purchasing and deploying AI tools, but almost none were achieving the business results that had been promised. “The 95% failure rate for enterprise AI solutions represents the clearest manifestation of the GenAI Divide,” the report stated. The core barrier, the authors concluded, was not infrastructure, regulation, or talent. It was that most generative AI systems “do not retain feedback, adapt to context, or improve over time,” making them fundamentally ill-suited for the enterprise environments into which they were being thrust.

This was not an outlier finding. A 2024 NTT DATA analysis concluded that between 70 and 85 percent of generative AI deployment efforts were failing to meet their desired return on investment. The Autodesk State of Design & Make 2025 report found that sentiment toward AI had dropped significantly year over year, with just 69 percent of business leaders saying AI would enhance their industry, representing a 12 percent decline from the previous year. Only 40 percent of leaders said they were approaching or had achieved their AI goals, a 16-point decrease that represented a 29 percent drop. S&P Global data revealed that 42 percent of companies scrapped most of their AI initiatives in 2025, up sharply from 17 percent the year before.

The infrastructure spending, meanwhile, continued accelerating even as returns failed to materialise. Meta, Microsoft, Amazon, and Google collectively committed over $250 billion to AI infrastructure during 2025. Amazon alone planned $125 billion in capital expenditure, up from $77 billion in 2024, a 62 percent increase. Goldman Sachs CEO David Solomon publicly acknowledged that he expected “a lot of capital that was deployed that doesn't deliver returns.” Amazon founder Jeff Bezos called the environment “kind of an industrial bubble.” Even OpenAI CEO Sam Altman conceded that “people will overinvest and lose money.”

Trust in Freefall

The gap between AI's promises and its performance is not occurring in a vacuum. It is landing on a public already growing sceptical of the technology industry's claims, and it is accelerating a decline in trust that carries profound implications for democratic governance.

The 2025 Edelman Trust Barometer, based on 30-minute online interviews conducted between October and November 2024, revealed a stark picture. Globally, only 49 percent of respondents trusted artificial intelligence as a technology. In the United States, that figure dropped to just 32 percent. Three times as many Americans rejected the growing use of AI (49 percent) as embraced it (17 percent). In the United Kingdom, trust stood at just 36 percent. In Germany, 39 percent. The Chinese public, by contrast, reported 72 percent trust in AI, a 40-point gap that reflects not just different regulatory environments but fundamentally different cultural relationships with technology and state authority.

These figures represent a significant deterioration. A decade ago, 73 percent of Americans trusted technology companies. By 2025, that number had fallen to 63 percent. Technology, which was the most trusted sector in 90 percent of the countries Edelman studies eight years ago, now held that position in only half. The barometer also found that 59 percent of global employees feared job displacement due to automation, and nearly one in two were sceptical of business use of artificial intelligence.

The Pew Research Center's findings painted an even more granular picture of public anxiety. In an April 2025 report examining how the US public and AI experts view artificial intelligence, Pew found that 50 percent of American adults said they were more concerned than excited about the increased use of AI in daily life, up from 37 percent in 2021. More than half (57 percent) rated the societal risks of AI as high, compared with only 25 percent who said the benefits were high. Over half of US adults (53 percent) believed AI did more harm than good in protecting personal privacy, and 53 percent said AI would worsen people's ability to think creatively.

Perhaps most revealing was the chasm between expert optimism and public unease. While 56 percent of AI experts believed AI would have a positive effect on the United States over the next 20 years, only 17 percent of the general public agreed. While 47 percent of experts said they were more excited than concerned, only 11 percent of ordinary citizens felt the same. And despite their divergent levels of optimism, both groups shared a common scepticism about institutional competence: roughly 60 percent of both experts and the public said they lacked confidence that US companies would develop AI responsibly.

The Stanford HAI AI Index 2025 Report reinforced these trends globally. Across 26 nations surveyed by Ipsos, confidence that AI companies protect personal data fell from 50 percent in 2023 to 47 percent in 2024. Fewer people believed AI systems were unbiased and free from discrimination compared to the previous year. While 18 of 26 nations saw an increase in the proportion of people who believed AI products offered more benefits than drawbacks, the optimism was concentrated in countries like China (83 percent), Indonesia (80 percent), and Thailand (77 percent), while the United States (39 percent), Canada (40 percent), and the Netherlands (36 percent) remained deeply sceptical.

When Algorithms Replace Judgement

The erosion of public trust in AI would be concerning enough if it were merely a matter of consumer sentiment. But the stakes become existential when governments and corporations use overestimated AI capabilities to make decisions that fundamentally alter people's lives, and when those decisions carry consequences that cannot be undone.

Consider healthcare. In November 2023, a class action lawsuit was filed against UnitedHealth Group and its subsidiary, alleging that the company illegally used an AI algorithm called nH Predict to deny rehabilitation care to seriously ill elderly patients enrolled in Medicare Advantage plans. The algorithm, developed by a company called Senior Metrics and later acquired by UnitedHealth's Optum subsidiary in 2020, was designed to predict how long patients would need post-acute care. According to the lawsuit, UnitedHealth deployed the algorithm knowing it had a 90 percent error rate on appeals, meaning that nine out of ten times a human reviewed the AI's denial, they overturned it. UnitedHealth also allegedly knew that only 0.2 percent of denied patients would file appeals, making the error rate commercially inconsequential for the insurer despite being medically devastating for patients.

The human cost was documented in court filings. Gene Lokken, a 91-year-old Wisconsin resident named in the lawsuit, fractured his leg and ankle in May 2022. After his doctor approved physical therapy, UnitedHealth paid for only 19 days before the algorithm determined he was safe to go home. His doctors appealed, noting his muscles were “paralysed and weak,” but the insurer denied further coverage. His family paid approximately $150,000 over the following year until he died in July 2023. In February 2025, a federal court allowed the case to proceed, denying UnitedHealth's attempt to dismiss the claims and waiving the exhaustion of administrative remedies requirement, noting that patients faced irreparable harm.

The STAT investigative series “Denied by AI,” which broke the UnitedHealth story, was a 2024 Pulitzer Prize finalist in investigative reporting. A US Senate report released in October 2024 found that UnitedHealthcare's prior authorisation denial rate for post-acute care had jumped to 22.7 percent in 2022 from 10.9 percent in 2020. The healthcare AI problem extends far beyond a single insurer. ECRI, a patient safety organisation, ranked insufficient governance of artificial intelligence as the number two patient safety threat in 2025, warning that medical errors generated by AI could compromise patient safety through misdiagnoses and inappropriate treatment decisions. Yet only about 16 percent of hospital executives surveyed said they had a systemwide governance policy for AI use and data access.

The pattern repeats across domains where algorithmic systems are deployed to process vulnerable populations. In the Netherlands, the childcare benefits scandal stands as perhaps the most devastating example of what happens when governments trust flawed algorithms with life-altering decisions. The Dutch Tax and Customs Administration deployed a machine learning model to detect welfare fraud that illegally used dual nationality as a risk characteristic. The system falsely accused over 20,000 parents of fraud, resulting in benefits termination and forced repayments. Families were driven into bankruptcy. Children were removed from their homes. Mental health crises proliferated. Seventy percent of those affected had a migration background, and fifty percent were single-person households, mostly mothers. In January 2021, the Dutch government was forced to resign after a parliamentary investigation concluded that the government had violated the foundational principles of the rule of law.

The related SyRI (System Risk Indication) system, which cross-referenced citizens' employment, benefits, and tax data to flag “unlikely citizen profiles,” was deployed exclusively in neighbourhoods with high numbers of low-income households and disproportionately many residents from immigrant backgrounds. In February 2020, the Hague court ordered SyRI's immediate halt, ruling it violated Article 8 of the European Convention on Human Rights. Amnesty International described the system's targeting criteria as “xenophobic machines.” Yet investigations by Lighthouse Reports later confirmed that similar algorithmic surveillance practices continued under slightly adapted systems, even after the ban, with the government having “silently continued to deploy a slightly adapted SyRI in some of the country's most vulnerable neighbourhoods.”

The Stochastic Parrot Problem

Understanding why AI hype is so dangerous requires understanding what these systems actually do, as opposed to what their makers claim they do.

Emily Bender, a linguistics professor at the University of Washington who was included in the inaugural TIME100 AI list of most influential people in artificial intelligence in 2023, co-authored a now-famous paper arguing that large language models are fundamentally “stochastic parrots.” They do not understand language in any meaningful sense. They draw on training data to predict which sequence of tokens is most likely to follow a given prompt. The result is an illusion of comprehension, a pattern-matching exercise that produces outputs resembling intelligent thought without any of the underlying cognition.

In 2025, Bender and sociologist Alex Hanna, director of research at the Distributed AI Research Institute and a former Google employee, published “The AI Con: How to Fight Big Tech's Hype and Create the Future We Want.” The book argues that AI hype serves as a mask for Big Tech's drive for profit, with the breathless promotion of AI capabilities benefiting technology companies far more than users or society. “Who benefits from this technology, who is harmed, and what recourse do they have?” Bender and Hanna ask, framing these as the essential questions that the hype deliberately obscures. Library Journal called the book “a thorough, witty, and accessible argument against AI that meets the moment.”

The stochastic parrot problem has real-world consequences that compound the trust deficit. When AI systems fabricate information with perfect confidence, they undermine the epistemic foundations that societies rely on for decision-making. Legal scholar Damien Charlotin, who tracks AI hallucinations in court filings through his database, had documented at least 206 instances of lawyers submitting AI-generated fabricated case citations by mid-2025. Stanford University's RegLab found that even premium legal AI tools hallucinated at alarming rates: Westlaw's AI-Assisted Research produced hallucinated or incorrect information 33 percent of the time, providing accurate responses to only 42 percent of queries. LexisNexis's Lexis+ AI hallucinated 17 percent of the time. A 2025 study published in Nature Machine Intelligence found that large language models cannot reliably distinguish between belief and knowledge, or between opinions and facts, noting that “failure to make such distinctions can mislead diagnoses, distort judicial judgements and amplify misinformation.”

If the tools marketed as the most reliable in their field fabricate information roughly one-fifth to one-third of the time, what does this mean for the countless lower-stakes applications where AI outputs are accepted without verification?

The AI Washing Economy

The gap between marketing claims and actual capabilities has grown so pronounced that regulators have begun treating AI exaggeration as a form of securities fraud.

In March 2024, the US Securities and Exchange Commission brought its first “AI washing” enforcement actions, simultaneously charging two investment advisory firms, Delphia and Global Predictions, with making false and misleading statements about their use of AI. Delphia paid $225,000 and Global Predictions paid $175,000 in civil penalties. These firms had not been entirely without AI capabilities, but they had overstated what those systems could do, crossing the line from marketing enthusiasm into regulatory violation.

The enforcement actions escalated rapidly. In January 2025, the SEC charged Presto Automation, a formerly Nasdaq-listed company, in the first AI washing action against a public company. Presto had claimed its AI voice system eliminated the need for human drive-through order-taking at fast food restaurants, but the SEC alleged the vast majority of orders still required human intervention and that the AI speech recognition technology was owned and operated by a third party. In April 2025, the SEC and Department of Justice charged the founder of Nate Inc. with fraudulently raising over $42 million by claiming the company's shopping app used AI to process transactions, when in reality manual workers completed the purchases. The claimed automation rate was above 90 percent; the actual rate was essentially zero.

Securities class actions targeting alleged AI misrepresentations increased by 100 percent between 2023 and 2024. In February 2025, the SEC announced the creation of a dedicated Cyber and Emerging Technologies Unit, tasked with combating technology-related misconduct, and flagged AI washing as a top examination priority.

The pattern is instructive. When a technology is overhyped, the incentive to exaggerate capabilities becomes irresistible. Companies that accurately describe their modest AI implementations risk being punished by investors who have been conditioned to expect transformative breakthroughs. The honest actors are penalised while the exaggerators attract capital, creating a market dynamic that systematically rewards deception.

Echoes of Previous Bubbles

The AI hype cycle is not without historical precedent, and the parallels offer both warnings and qualified reassurance.

During the dot-com era, telecommunications companies laid more than 80 million miles of fibre optic cables across the United States, driven by wildly inflated claims about internet traffic growth. Companies like Global Crossing, Level 3, and Qwest raced to build massive networks. The result was catastrophic overcapacity: even four years after the bubble burst, 85 to 95 percent of the fibre laid remained unused, earning the nickname “dark fibre.” The Nasdaq composite rose nearly 400 percent between 1995 and March 2000, then crashed 78 percent by October 2002.

The parallels to today's AI infrastructure buildout are unmistakable. Meta CEO Mark Zuckerberg announced plans for an AI data centre “so large it could cover a significant part of Manhattan.” The Stargate Project aims to develop a $500 billion nationwide network of AI data centres. Goldman Sachs analysts found that hyperscaler companies had taken on $121 billion in debt over the past year, representing a more than 300 percent increase from typical industry debt levels. AI-related stocks had accounted for 75 percent of S&P 500 returns, 80 percent of earnings growth, and 90 percent of capital spending growth since ChatGPT launched in November 2022.

Yet there are important differences. Unlike many dot-com companies that had no revenue, major AI players are generating substantial income. Microsoft's Azure cloud service grew 39 percent year over year to an $86 billion run rate. OpenAI projects $20 billion in annualised revenue. The Nasdaq's forward price-to-earnings ratio was approximately 26 times in November 2023, compared to approximately 60 times at the dot-com peak.

The more useful lesson from the dot-com era is not about whether the bubble will burst, but about what happens to public trust and institutional decision-making in the aftermath. The internet survived the dot-com crash and eventually fulfilled many of its early promises. But the crash destroyed trillions in wealth, wiped out retirement savings, and created a lasting scepticism toward technology claims that took years to overcome. The institutions and individuals who made decisions based on dot-com hype, from pension funds that invested in companies with no path to profitability to governments that restructured services around technologies that did not yet work, bore costs that were never fully recovered.

Algorithmic Bias and the Feedback Loop of Injustice

Perhaps the most consequential long-term risk of the AI hype gap is its intersection with systemic inequality. When policymakers deploy AI systems in criminal justice, welfare administration, and public services based on inflated claims of accuracy and objectivity, the consequences fall disproportionately on communities that are already marginalised.

Predictive policing offers a stark illustration. The Chicago Police Department's “Strategic Subject List,” implemented in 2012 to identify individuals at higher risk of gun violence, disproportionately targeted young Black and Latino men, leading to intensified surveillance and police interactions in those communities. The system created a feedback loop: more police dispatched to certain neighbourhoods resulted in more recorded crime, which the algorithm interpreted as confirmation that those neighbourhoods were indeed high-risk, which led to even more policing. The NAACP has called on state legislators to evaluate and regulate the use of predictive policing, noting mounting evidence that these tools increase racial biases and citing the lack of transparency inherent in proprietary algorithms that do not allow for public scrutiny.

The COMPAS recidivism prediction tool, widely used in US criminal justice, was found to produce biased predictions against Black defendants compared to white defendants, trained on historical data saturated with racial bias. An audit by the LAPD inspector general found “significant inconsistencies” in how officers entered data into a predictive policing programme, further fuelling biased predictions. These are not edge cases or implementation failures. They are the predictable consequences of deploying pattern-recognition systems trained on data that reflects centuries of structural discrimination.

In welfare administration, the pattern is equally troubling. The Dutch childcare benefits scandal demonstrated how algorithmic systems can automate inequality at scale. The municipality of Rotterdam used a discriminatory algorithm to profile residents and “predict” social welfare fraud for three years, disproportionately targeting young single mothers with limited knowledge of Dutch. In the United Kingdom, the Department for Work and Pensions admitted, in documents released under the Freedom of Information Act, to finding bias in an AI tool used to detect fraud in universal credit claims. The tool's initial iteration correctly matched conditions only 35 percent of the time, and by the DWP's own admission, “chronic fatigue was translated into chronic renal failure” and “partially amputation of foot was translated into partially sighted.”

These failures share a common thread. The AI systems were deployed based on claims of objectivity and accuracy that did not withstand scrutiny. Policymakers, influenced by industry hype about AI's capabilities, trusted algorithmic outputs over human judgement, and the people who paid the price were those least equipped to challenge the decisions being made about their lives.

What Sustained Disillusionment Means for Innovation

The long-term consequences of the AI hype gap extend beyond immediate harms to individual victims. They threaten to reshape the relationship between society and technological innovation in ways that could prove difficult to reverse.

First, there is the problem of misallocated resources. The MIT study found that more than half of generative AI budgets were devoted to sales and marketing tools, despite evidence that the best returns came from back-office automation, eliminating business process outsourcing, cutting external agency costs, and streamlining operations. When organisations chase the use cases that sound most impressive rather than those most likely to deliver value, they waste capital that could have funded genuinely productive innovation. The study also revealed a striking shadow economy: while only 40 percent of companies had official large language model subscriptions, 90 percent of workers surveyed reported daily use of personal AI tools for job tasks, suggesting that the gap between corporate AI strategy and actual AI utility is even wider than the headline figures suggest.

Second, the trust deficit creates regulatory feedback loops that can stifle beneficial applications. As public concern about AI grows, so does political pressure for restrictive regulation. The 2025 Stanford HAI report found that references to AI in draft legislation across 75 countries increased by 21.3 percent, continuing a ninefold increase since 2016. In the United States, 73.7 percent of local policymakers agreed that AI should be regulated, up from 55.7 percent in 2022. This regulatory momentum is a direct response to the trust deficit, and while some regulation is necessary and overdue, poorly designed rules driven by public fear rather than technical understanding risk constraining beneficial applications alongside harmful ones. Colorado became the first US state to enact legislation addressing algorithmic bias in 2024, with California and New York following with their own targeted measures.

Third, the hype cycle creates a talent and attention problem. When AI is presented as a solution to every conceivable challenge, researchers and engineers are pulled toward fashionable applications rather than areas of genuine need. Acemoglu has argued that “we currently have the wrong direction for AI. We're using it too much for automation and not enough for providing expertise and information to workers.” The hype incentivises building systems that replace human judgement rather than augmenting it, directing talent and investment away from applications that could produce the greatest social benefit.

Finally, and perhaps most critically, the erosion of public trust in AI threatens to become self-reinforcing. Each failed deployment, each exaggerated claim exposed, each algorithmic system found to be biased or inaccurate further deepens public scepticism. Meredith Whittaker, president of Signal, has warned about the security and privacy risks of granting AI agents extensive access to sensitive data, describing a future where the “magic genie bot” becomes a nightmare if security and privacy are not prioritised. When public trust in AI erodes, even beneficial and well-designed systems face adoption resistance, creating a vicious cycle where good technology is tainted by association with bad marketing.

Rebuilding on Honest Foundations

The AI hype gap is not merely a marketing problem or an investment risk. It is a structural challenge to the relationship between technological innovation and public trust that has been building for years and is now reaching a critical inflection point.

The 2025 Edelman Trust Barometer found that the most powerful drivers of AI enthusiasm are trust and information, with hesitation rooted more in unfamiliarity than negative experiences. This finding suggests a path that does not require abandoning AI, but demands abandoning the hype. As people use AI more and experience its ability to help them learn, work, and solve problems, their confidence rises. The obstacle is not the technology itself but the inflated expectations that set users up for disappointment.

Gartner's placement of generative AI in the Trough of Disillusionment is, paradoxically, encouraging. As the firm's analysts note, the trough does not represent failure. It represents the transition from wild experimentation to rigorous engineering, from breathless promises to honest assessment of what works and what does not. The companies and institutions that emerge successfully from this phase will be those that measured their claims against reality rather than against their competitors' marketing materials.

The lesson from previous technology cycles is clear but routinely ignored. The dot-com bubble popped, but the internet did not disappear. What disappeared were the companies and institutions that confused hype with strategy. The same pattern will likely repeat with AI. The technology will mature, find its genuine applications, and deliver real value. But the path from here to there runs through a period of reckoning that demands honesty about what AI can and cannot do, transparency about the limitations of algorithmic decision-making, and accountability for the real harms caused by deploying immature systems in high-stakes contexts.

As Bender and Hanna urge, the starting point must be asking basic but important questions: who benefits, who is harmed, and what recourse do they have? As Acemoglu wrote in his analysis for “Economic Policy” in 2024, “Generative AI has the potential to fundamentally change the process of scientific discovery, research and development, innovation, new product and material testing.” The potential is real. But potential is not performance, and treating it as such has consequences that a $600 billion question only begins to capture.

References and Sources

Acemoglu, D. (2024). “The Simple Macroeconomics of AI.” Economic Policy. Massachusetts Institute of Technology. https://economics.mit.edu/sites/default/files/2024-04/The%20Simple%20Macroeconomics%20of%20AI.pdf
Amnesty International. (2021). “Xenophobic Machines: Dutch Child Benefit Scandal.” Retrieved from https://www.amnesty.org/en/latest/news/2021/10/xenophobic-machines-dutch-child-benefit-scandal/
Bender, E. M. & Hanna, A. (2025). The AI Con: How to Fight Big Tech's Hype and Create the Future We Want. Penguin/HarperCollins.
CBS News. (2023). “UnitedHealth uses faulty AI to deny elderly patients medically necessary coverage, lawsuit claims.” Retrieved from https://www.cbsnews.com/news/unitedhealth-lawsuit-ai-deny-claims-medicare-advantage-health-insurance-denials/
Challapally, A., Pease, C., Raskar, R. & Chari, P. (2025). “The GenAI Divide: State of AI in Business 2025.” MIT NANDA Initiative. As reported by Fortune, 18 August 2025. https://fortune.com/2025/08/18/mit-report-95-percent-generative-ai-pilots-at-companies-failing-cfo/
Edelman. (2025). “2025 Edelman Trust Barometer.” Retrieved from https://www.edelman.com/trust/2025/trust-barometer
Edelman. (2025). “Flash Poll: Trust and Artificial Intelligence at a Crossroads.” Retrieved from https://www.edelman.com/trust/2025/trust-barometer/flash-poll-trust-artifical-intelligence
Edelman. (2025). “The AI Trust Imperative: Navigating the Future with Confidence.” Retrieved from https://www.edelman.com/trust/2025/trust-barometer/report-tech-sector
Gartner. (2025). “Hype Cycle for Artificial Intelligence, 2025.” Retrieved from https://www.gartner.com/en/articles/hype-cycle-for-artificial-intelligence
Goldman Sachs. (2024). “Top of Mind: AI: in a bubble?” Goldman Sachs Research. Retrieved from https://www.goldmansachs.com/insights/top-of-mind/ai-in-a-bubble
Healthcare Finance News. (2025). “Class action lawsuit against UnitedHealth's AI claim denials advances.” Retrieved from https://www.healthcarefinancenews.com/news/class-action-lawsuit-against-unitedhealths-ai-claim-denials-advances
Lighthouse Reports. (2023). “The Algorithm Addiction.” Retrieved from https://www.lighthousereports.com/investigation/the-algorithm-addiction/
Magesh, V., Surani, F., Dahl, M., Suzgun, M., Manning, C. D. & Ho, D. E. (2025). “Hallucination-Free? Assessing the Reliability of Leading AI Legal Research Tools.” Journal of Empirical Legal Studies, 0:1-27. https://doi.org/10.1111/jels.12413
MIT Technology Review. (2025). “The great AI hype correction of 2025.” Retrieved from https://www.technologyreview.com/2025/12/15/1129174/the-great-ai-hype-correction-of-2025/
NAACP. (2024). “Artificial Intelligence in Predictive Policing Issue Brief.” Retrieved from https://naacp.org/resources/artificial-intelligence-predictive-policing-issue-brief
Nature Machine Intelligence. (2025). “Language models cannot reliably distinguish belief from knowledge and fact.” https://doi.org/10.1038/s42256-025-01113-8
Novara Media. (2025). “How Labour Is Using Biased AI to Determine Benefit Claims.” Retrieved from https://novaramedia.com/2025/04/15/how-the-labour-party-is-using-biased-ai-to-determine-benefit-claims/
NTT DATA. (2024). “Between 70-85% of GenAI deployment efforts are failing to meet their desired ROI.” Retrieved from https://www.nttdata.com/global/en/insights/focus/2024/between-70-85p-of-genai-deployment-efforts-are-failing
Pew Research Center. (2025). “How the US Public and AI Experts View Artificial Intelligence.” Retrieved from https://www.pewresearch.org/internet/2025/04/03/how-the-us-public-and-ai-experts-view-artificial-intelligence/
Radiologybusiness.com. (2025). “'Insufficient governance of AI' is the No. 2 patient safety threat in 2025.” Retrieved from https://radiologybusiness.com/topics/artificial-intelligence/insufficient-governance-ai-no-2-patient-safety-threat-2025
SEC. (2024). “SEC Charges Two Investment Advisers with Making False and Misleading Statements About Their Use of Artificial Intelligence.” Press Release 2024-36. Retrieved from https://www.sec.gov/newsroom/press-releases/2024-36
Stanford HAI. (2025). “The 2025 AI Index Report.” Stanford University Human-Centered Artificial Intelligence. Retrieved from https://hai.stanford.edu/ai-index/2025-ai-index-report
STAT News. (2023). “UnitedHealth faces class action lawsuit over algorithmic care denials in Medicare Advantage plans.” Retrieved from https://www.statnews.com/2023/11/14/unitedhealth-class-action-lawsuit-algorithm-medicare-advantage/
The Dutch Childcare Benefits Scandal. Wikipedia. Retrieved from https://en.wikipedia.org/wiki/Dutch_childcare_benefits_scandal
Washington Post. (2024). “Big Tech is spending billions on AI. Some on Wall Street see a bubble.” Retrieved from https://www.washingtonpost.com/technology/2024/07/24/ai-bubble-big-tech-stocks-goldman-sachs/

Tim Green
UK-based Systems Theorist & Independent Technology Writer

Tim explores the intersections of artificial intelligence, decentralised cognition, and posthuman ethics. His work, published at smarterarticles.co.uk, challenges dominant narratives of technological progress while proposing interdisciplinary frameworks for collective intelligence and digital stewardship.

His writing has been featured on Ground News and shared by independent researchers across both academic and technological communities.

ORCID: 0009-0002-0156-9795
Email: tim@smarterarticles.co.uk

Orbis: Turn Any GitHub Repository Into an Interactive 3D Dependency Graph

Nilofer 🚀 — Sat, 09 May 2026 10:58:10 +0000

Understanding a large codebase is hard. You clone it, start reading files, and quickly lose track of how everything connects. Which modules are most depended on? Where are the circular dependencies? What would break if you refactored this file?

Orbis answers these questions visually. Paste a GitHub repository URL, and Orbis clones it, parses the ASTs across Python, JavaScript, TypeScript, Go, Rust, and Java, detects architectural patterns, and renders the entire codebase as a navigable 3D force-directed graph. Click any module to inspect its dependencies, metrics, and exported symbols. Ask the built-in AI assistant questions like "which module should I refactor first?" and get answers grounded in the actual code structure.

Features

3D force-directed graph - Nodes sized by lines of code, colored by type, with animated directional particles on edges.

Multi-language AST parsing - Python, JavaScript/TypeScript, Go, Rust, and Java via tree-sitter.

AI chat assistant - Ask Claude questions about the analyzed codebase. Questions like "Which modules have circular dependencies?" or "Where should I add feature X?" are answered with full architectural context.

Architectural insights - Auto-detected issues including god modules, high coupling, and circular dependencies, each with severity ratings.

Focus Mode - Dim unconnected nodes to trace dependency paths clearly.

Shareable URLs - ?repo=https://github.com/... auto-triggers analysis on load, making it easy to share a specific codebase view.

Recent history - Last 5 repos stored locally for quick re-analysis.

Demo mode — Load a pre-analyzed snapshot without a GitHub clone.

Tech Stack

Backend: FastAPI + Server-Sent Events (SSE)
AST Parsing: tree-sitter (Python, JS/TS, Go, Rust, Java)
AI Integration: Claude Opus 4.6 via Anthropic API
3D Rendering: 3d-force-graph + Three.js
Frontend: Vanilla JS SPA - no build step

Quick Start

1. Clone and install

cd orbis
python -m venv venv
source venv/bin/activate   # Windows: venv\Scripts\activate
pip install -r requirements.txt

2. Set up environment

cp .env.example .env
# Edit .env and add your ANTHROPIC_API_KEY for the AI chat feature

Get an API key at console.anthropic.com. The AI chat feature requires ANTHROPIC_API_KEY in your environment. It degrades gracefully, if the key is missing, the chat panel shows an error message rather than breaking the rest of the app.

3. Run

uvicorn main:app --host 0.0.0.0 --port 8001

Open http://localhost:8001.

Docker

docker build -t orbis .
docker run -p 8001:8001 -e ANTHROPIC_API_KEY=sk-ant-... orbis

Usage

Once running, the workflow is straightforward:

Enter a public GitHub repository URL - for example https://github.com/expressjs/express
Optionally specify a branch
Click Analyze - Orbis clones the repo, parses ASTs, and builds the graph in roughly 5–30 seconds
Explore the 3D graph - click a node to open its detail drawer, scroll to zoom, drag to rotate
Use Focus Mode to highlight a node's direct connections
Use layer filter chips to show or hide architectural layers
Ask the AI assistant questions about the codebase in the chat panel

Keyboard Shortcuts

R: Reset camera
P: Pause/resume rotation
F: Toggle Focus Mode
/: Focus search box
Esc: Close detail drawer / exit Focus Mode

Architecture

The project has four files at its core - a FastAPI backend, a single-file AST parser, and a vanilla JS frontend with no build step:

main.py           FastAPI backend — SSE streaming for /analyze, /chat
neo_parser.py     Multi-language AST parser (tree-sitter)
static/
  index.html      Single-page frontend (3d-force-graph + Three.js)
save_analysis.py  Utility: pre-generate demo data from a repo

The backend streams analysis progress to the frontend via Server-Sent Events, The backend streams analysis progress to the frontend via Server-Sent Events while cloning and analyzing the repo.

API Endpoints

Output Schema

/analyze emits SSE events and completes with a complete event containing:

{
  "schema_version": "2.0",
  "architecture_type": "MVC",
  "languages": { "python": 42 },
  "summary": "Codebase contains 42 modules...",
  "nodes": [{
    "id": "requests/auth",
    "label": "auth.py",
    "type": "utility",
    "language": "python",
    "lines_of_code": 315,
    "complexity": "medium",
    "exported_symbols": ["AuthBase", "HTTPBasicAuth"],
    "internal_dependencies": ["requests/compat"],
    "external_dependencies": [],
    "metrics": { "functions_total": 12, "classes": 4 }
  }],
  "edges": [{ "from": "requests/api", "to": "requests/auth", "type": "import" }],
  "insights": [{
    "type": "high_coupling",
    "severity": "high",
    "title": "High fan-in on requests/models",
    "description": "14 modules import this file directly.",
    "affected_nodes": ["requests/models"],
    "recommendation": "Consider splitting into smaller focused modules."
  }]
}

Each node carries its lines of code, complexity rating, exported symbols, and both internal and external dependencies. The insights block surfaces architectural issues automatically, high coupling, circular dependencies, and god modules - each with a severity rating and a specific recommendation.

Supported Languages

Python - .py
JavaScript/TypeScript - .js, .mjs, .cjs, .jsx, .ts, .tsx
Go - .go
Rust - .rs
Java - .java

AI Chat

The chat assistant uses Claude Opus 4.6 and receives the full architectural graph as context - node list, dependencies, insights, and summary. It can answer questions like:

"What does the auth module depend on?"
"Why are there circular dependencies between X and Y?"
"Which module should I refactor first?"
"Where would I add a caching layer?"

The assistant's answers are grounded in the actual parsed structure of the codebase - not generic advice. Requires ANTHROPIC_API_KEY in your environment.

Development

# Run with auto-reload
uvicorn main:app --reload --port 8001

# Re-generate demo data
python save_analysis.py

How I Built This Using NEO

This project was built using NEO. NEO is a fully autonomous AI engineering agent that can write code and build solutions for AI/ML tasks including AI model evals, prompt optimization and end to end AI pipeline development.

The idea was a tool that turns any GitHub repository into an interactive 3D graph, something a developer could paste a URL into and immediately understand the architecture without reading a single file. The requirements included multi-language AST parsing, automatic architectural issue detection, an AI assistant grounded in the actual code structure, and a frontend that required no build step.

NEO built the full stack from that description: the FastAPI backend with SSE streaming for real-time analysis progress, the multi-language AST parser in neo_parser.py covering Python, JavaScript, TypeScript, Go, Rust, and Java via tree-sitter, the 3D force-directed graph frontend in vanilla JS, the Claude Opus 4.6 chat assistant with full architectural context, the insights engine detecting god modules, high coupling, and circular dependencies with severity ratings, and the demo mode with pre-generated analysis data.

How You Can Use and Extend This With NEO

Use it to onboard onto an unfamiliar codebase.
Instead of spending hours reading files to understand how a project is structured, paste the repo URL into Orbis and get an immediate visual map of every module, its dependencies, and the architectural issues that already exist. The AI assistant can then answer specific questions about the structure without you having to trace imports manually.

Use it during code review to understand structural impact.
When reviewing a large pull request, run Orbis on the repo and use the insights panel to see whether high coupling, circular dependencies, or god modules exist in the areas being changed. The AI assistant can answer specific questions about how the affected modules connect to the rest of the codebase.

Use it to plan a refactor.
Ask the AI assistant "which module should I refactor first?" or "where would I add a caching layer?" and get answers grounded in the actual dependency graph. The focus mode lets you isolate a specific module and trace exactly what depends on it before touching anything.

Extend it with additional language parsers.
neo_parser.py already handles five languages via tree-sitter. Adding a new language - Ruby, C++, Swift - follows the same parser pattern and surfaces automatically in the language filter chips and the supported languages list without touching the frontend or the API.

Final Notes

Orbis makes codebase architecture something you can see and navigate rather than something you have to reconstruct in your head. A 3D dependency graph, multi-language AST parsing, automatic architectural issue detection, and an AI assistant that knows the actual structure - all from a single repo URL.

The code is at https://github.com/dakshjain-1616/Orbit-dependency-visualised
You can also build with NEO in your IDE using the VS Code extension or Cursor.
You can use NEO MCP with Claude Code: https://heyneo.com/claude-code

🚀 Building AgentForge: AMD AI Agent Platform on Bolt.new

Michael G. Inso — Sat, 09 May 2026 10:55:21 +0000

🔧 What Was Built

Core Platform
- Bolt Database schema with agents, workflows, tasks, and workflow runs
- Row‑level security policies for data safety
- Real‑time subscriptions support
Frontend (React + Vite + TypeScript)
- Landing Page with AMD branding and feature highlights
- Dashboard showing GPU metrics (utilization, VRAM, temperature, power)
- Agents Page to manage models (Llama 3.2, DeepSeek Coder, Qwen 2.5/VL, Mistral 7B)
- Workflows Page for multi‑agent orchestration pipelines
- Task Monitor with real‑time execution feeds and performance tracking
Design
- AMD‑inspired dark theme with red accents (#e8001d)
- GPU‑centric UI reflecting AMD Instinct MI300X compute
- Smooth animations, glassmorphism effects, responsive layout

✨ Features

CRUD operations for agents and workflows
Real‑time task execution monitoring
GPU performance metrics display
Search and filtering across pages
Modal workflows for creating/editing entities
Live status indicators and animations

🚢 Enhancements

We added:

Edge Functions for AI inference
Drag‑and‑drop workflow builder UI
Advanced filtering and sorting
Export/reporting capabilities
User authentication with Bolt Database Auth

🌍 Why It Matters

AgentForge is more than a demo — it’s a blueprint for the future of AI agents. By combining modular workflows, real‑time monitoring, and AMD’s compute power, we’re enabling the next generation of high‑performance applications.

🔗 Live Demo

👉 Check out the published app here: AgentForge on Bolt.new

Closing

This project embodies the hackathon spirit: rapid iteration, collaboration, and building something that’s both functional and inspiring. Excited to see how the community pushes agentic workflows forward!

A Self-Monetizing API in 20 Lines of Code

MPP TestKit — Sat, 09 May 2026 10:53:15 +0000

This is a hands-on tutorial. By the end you'll have a running pay-per-request API server, a client that pays automatically, and a test suite that covers the full payment flow - all on devnet, completely free.

The Problem With How We Monetize APIs Today

If you've ever tried to sell access to an API you built, you know the drill:

Sign up for Stripe
Build a subscription checkout flow
Issue API keys on payment confirmation
Store keys in a database
Validate keys on every request
Build a usage dashboard
Handle expired cards, failed payments, refunds
Write the billing docs

By the time you've done all that, you've built a billing product. That wasn't the thing you wanted to build.

The worst part: none of this scales to small amounts. Charging $0.001 per API call with Stripe isn't viable - the processing fee alone exceeds the charge. So you're forced into subscriptions, bundles, and credit packs. Your pricing model becomes a product decision instead of just... pricing.

There's a cleaner way to do this. It's been in the HTTP spec since 1999. It just never had the infrastructure to work.

HTTP 402: The Status Code That Was Waiting for Blockchains

402 Payment Required

This status code has been reserved in HTTP since the original 1.1 spec. The idea: server tells the client "pay first, then retry." The client pays, retries with proof, gets the resource.

The problem was always how. How does the server specify the amount? In what form? How does the client pay programmatically? How does the server verify payment without a central authority?

Blockchains answer all of those questions. Solana specifically:

Specifies amount in SOL (or any token)
Accepts payment via a signed transaction
Provides on-chain verification with no intermediary
Confirms transactions in ~2 seconds
Charges fractions of a cent in fees

MPP Testkit is the SDK that wires this up. Let's build something with it.

What We're Building

A Node.js API server with:

/api/ping - free endpoint, no payment
/api/weather - costs 0.001 SOL per call
/api/forecast - costs 0.005 SOL per call (premium tier)

And a client script that:

Hits the paid endpoints automatically
Handles the wallet, airdrop, and payment without any manual steps
Logs every step of the flow

Total code: about 20 lines for the server, 10 for the client.

Setup

mkdir my-paid-api && cd my-paid-api
npm init -y
npm install express mpp-test-sdk

Create two files: server.js and client.js.

The Server

// server.js
import express from "express";
import { createTestServer } from "mpp-test-sdk";

const app = express();
const mpp = createTestServer();

// Free - no payment needed
app.get("/api/ping", (req, res) => {
  res.json({ status: "ok", ts: Date.now() });
});

// 0.001 SOL per call
app.get("/api/weather",
  mpp.charge({ amount: "0.001" }),
  (req, res) => {
    res.json({
      city: "San Francisco",
      temp: 62,
      condition: "Partly cloudy",
      paid: true,
    });
  }
);

// 0.005 SOL per call - premium tier
app.get("/api/forecast",
  mpp.charge({ amount: "0.005" }),
  (req, res) => {
    res.json({
      city: "San Francisco",
      forecast: [
        { day: "Mon", high: 65, low: 54 },
        { day: "Tue", high: 68, low: 57 },
        { day: "Wed", high: 61, low: 52 },
      ],
      model: "v2-premium",
      paid: true,
    });
  }
);

app.listen(3001, () => {
  console.log("Server running on :3001");
  console.log("Payment recipient:", mpp.recipientAddress);
});

Start it:

node server.js
# Server running on :3001
# Payment recipient: 7xKmPq2rNbMd...

That's the server. mpp.charge() is Express middleware. It returns a 402 if no valid payment receipt is present, verifies on-chain if one is, and calls next() if everything checks out.

The Client

// client.js
import { createTestClient } from "mpp-test-sdk";

const client = await createTestClient({
  network: "devnet",
  onStep: ({ type, message }) => console.log(`  [${type}] ${message}`),
});

console.log("\n- Hitting /api/ping (free)");
const ping = await client.fetch("http://localhost:3001/api/ping");
console.log(await ping.json());

console.log("\n- Hitting /api/weather (0.001 SOL)");
const weather = await client.fetch("http://localhost:3001/api/weather");
console.log(await weather.json());

console.log("\n- Hitting /api/forecast (0.005 SOL)");
const forecast = await client.fetch("http://localhost:3001/api/forecast");
console.log(await forecast.json());

Run it:

node client.js

- Hitting /api/ping (free)
{ status: 'ok', ts: 1715123456789 }

- Hitting /api/weather (0.001 SOL)
  [wallet-created] Keypair generated: 3xMn9...Wr4k
  [funded] Airdropped 2 SOL on devnet
  [request] GET http://localhost:3001/api/weather
  [payment] 402 received · paying 0.001 SOL
  [payment] tx confirmed: 5xKm7...Pq2r
  [retry] Retrying with Payment-Receipt header
  [success] 200 OK
{ city: 'San Francisco', temp: 62, condition: 'Partly cloudy', paid: true }

- Hitting /api/forecast (0.005 SOL)
  [request] GET http://localhost:3001/api/forecast
  [payment] 402 received · paying 0.005 SOL
  [payment] tx confirmed: 8xNp3...Qr1s
  [retry] Retrying with Payment-Receipt header
  [success] 200 OK
{ city: 'San Francisco', forecast: [...], model: 'v2-premium', paid: true }

Notice: the wallet and airdrop only happen once. The second paid call reuses the same wallet - no second airdrop. The client is stateful, the calls are not.

What Just Happened Under the Hood

When the client hit /api/weather:

Client sent GET /api/weather - no special headers
Server returned 402 Payment Required with header:

   Payment-Request: solana; amount="0.001"; recipient="7xKmPq2r..."

SDK parsed the header, built a Solana transaction for 0.001 SOL to 7xKmPq2r...
SDK signed and submitted the transaction to devnet
SDK waited for confirmation (~2 seconds)
Client retried with header:

   Payment-Receipt: solana; signature="5xKm7...Pq2r"

Server verified on-chain: transaction exists, recipient matches, amount ≥ 0.001 SOL
Server called next(), handler returned 200

Your handler code saw none of this. It just received a request and returned JSON.

Writing Tests for Your Paid Endpoints

This is where MPP Testkit really shines. Integration testing paid APIs usually means mocking the payment layer, which means your tests don't actually test the payment logic.

With MPP Testkit on devnet, you test the real flow for free:

// server.test.js
import { createTestClient } from "mpp-test-sdk";
import { describe, test, expect, beforeAll, afterAll } from "vitest";

let client;
let server;

beforeAll(async () => {
  // Start the server
  server = await import("./server.js");

  // Create a test client - wallet + airdrop happen here once
  client = await createTestClient({ network: "devnet" });
});

afterAll(() => server.close());

describe("Free endpoints", () => {
  test("GET /api/ping returns 200 without payment", async () => {
    const res = await client.fetch("http://localhost:3001/api/ping");
    expect(res.status).toBe(200);
    const body = await res.json();
    expect(body).toHaveProperty("status", "ok");
  });
});

describe("Paid endpoints", () => {
  test("GET /api/weather: pays 0.001 SOL, returns weather data", async () => {
    const res = await client.fetch("http://localhost:3001/api/weather");
    expect(res.status).toBe(200);
    const body = await res.json();
    expect(body).toHaveProperty("temp");
    expect(body.paid).toBe(true);
  });

  test("GET /api/forecast: pays 0.005 SOL, returns 3-day forecast", async () => {
    const res = await client.fetch("http://localhost:3001/api/forecast");
    expect(res.status).toBe(200);
    const body = await res.json();
    expect(body.forecast).toHaveLength(3);
  });

  test("Direct request without payment returns 402", async () => {
    const res = await fetch("http://localhost:3001/api/weather");
    expect(res.status).toBe(402);
    const header = res.headers.get("Payment-Request");
    expect(header).toMatch(/solana/);
    expect(header).toMatch(/amount="0.001"/);
  });

  test("Request with invalid receipt returns 403", async () => {
    const res = await fetch("http://localhost:3001/api/weather", {
      headers: { "Payment-Receipt": "solana; signature=fakesig123" },
    });
    expect(res.status).toBe(403);
  });
});

Run with:

npx vitest

These are real integration tests. No mocks. No stubs. The payment flow runs against devnet on every test run. If your receipt verification logic breaks, the test catches it - because it actually verifies.

Handling Errors Gracefully

Real code needs error handling. The SDK throws typed errors:

import {
  mppFetch,
  MppFaucetError,
  MppPaymentError,
  MppTimeoutError,
} from "mpp-test-sdk";

async function fetchWithFallback(url) {
  try {
    return await mppFetch(url);
  } catch (err) {
    if (err instanceof MppFaucetError) {
      // Devnet faucet rate-limited - common in CI with many parallel runs
      console.warn("Faucet unavailable, retrying in 60s...");
      await sleep(60_000);
      return mppFetch(url); // retry once
    }

    if (err instanceof MppPaymentError) {
      // Transaction rejected - log and rethrow
      console.error(`Payment rejected: ${err.url} → ${err.status}`);
      throw err;
    }

    if (err instanceof MppTimeoutError) {
      // Flow took too long - Solana can be slow under load
      console.error(`Timed out after ${err.timeoutMs}ms`);
      throw err;
    }

    throw err;
  }
}

Taking It to Production (Mainnet)

When you're ready to charge real SOL:

Server side - pin a stable recipient wallet:

const mpp = createTestServer({
  secretKey: process.env.SERVER_SECRET_KEY, // base64 or JSON array
  network: "mainnet",
});

Client side - provide a funded wallet:

const client = await createTestClient({
  network: "mainnet",
  secretKey: process.env.CLIENT_SECRET_KEY, // pre-funded with real SOL
});

The protocol is identical. The only difference is network: "mainnet" and no auto-airdrop. Your application code doesn't change.

The Creator Economy Angle

I want to zoom out for a second, because this is bigger than just APIs.

If you're a developer who creates things - libraries, datasets, AI models, tools - the standard monetization paths are:

Open source - free, you get nothing
SaaS - build a subscription billing system (Stripe, auth, database, dashboard)
One-time license - Gumroad, Paddle, etc. - purchase gate, license key management
Usage-based - Stripe metered billing - still requires subscription, monthly invoicing

All of these require you to build infrastructure around your actual product.

HTTP 402 with Solana adds a fifth option: embed payment in the protocol itself.

Your dataset endpoint charges $0.0001 per query. Your AI model charges $0.01 per inference. Your code analysis tool charges $0.005 per file. No subscription. No free tier decision. No pricing page. The price is in the API response.

Consumers - including AI agents - just pay and use. Your server accumulates SOL. You withdraw to your wallet.

The entire billing system is the blockchain.

Why This Matters for AI Agents Right Now

We're at an inflection point: AI agents are being deployed that autonomously call tools, APIs, and services. The problem is that every one of those tools currently requires a human to sign up, get an API key, and manage billing.

That doesn't scale. An agent that spins up 50 tool-calling sessions needs 50 sets of credentials managed by a human. Or one set of credentials shared across everything - which is a security disaster.

HTTP 402 with Solana gives agents a payment identity without a human in the loop:

Agent generates an ephemeral keypair on first run
Agent funds wallet from its operator's SOL balance
Agent hits any 402-gated endpoint and pays automatically
Operator monitors spending via on-chain transactions

No API keys. No credentials database. No revocation system. The wallet is the identity. The payment is the access token.

The Auton demo shows this working end-to-end - an agent that generates its own wallet, gets funded, navigates a 402 gate, pays, and retrieves premium data. Every step streams live to the browser. Watch it once and the architecture becomes obvious.

Quick Reference

Install

npm install mpp-test-sdk       # TypeScript/JavaScript
pip install mpp-test-sdk       # Python
go get github.com/mpptestkit/mpp-test-sdk-go  # Go

Minimal server

import { createTestServer } from "mpp-test-sdk";
const mpp = createTestServer();
app.get("/paid", mpp.charge({ amount: "0.001" }), handler);

Minimal client

import { mppFetch } from "mpp-test-sdk";
const res = await mppFetch("https://your-api.com/paid");

Networks

Network	Auto-funded	Cost
`devnet`	Yes (2 SOL)	Free
`testnet`	Yes (2 SOL)	Free
`mainnet`	No	Real SOL

Error types

Error	Cause
`MppFaucetError`	Devnet/testnet faucet rate-limited
`MppPaymentError`	On-chain transaction rejected
`MppTimeoutError`	Full flow exceeded timeout
`MppNetworkError`	Mainnet attempted without funded wallet

What's Next

Once you have the basics running:

Add multiple price tiers - mpp.charge({ amount: "0.01" }) on premium endpoints, mpp.charge({ amount: "0.001" }) on standard
Use the lifecycle events - stream payment status to your frontend in real-time (the playground does this)
Integrate with your existing auth - 402 and API keys aren't mutually exclusive; use 402 for metered access, API keys for identity
Move to mainnet - same code, swap network: "devnet" to network: "mainnet", provide funded wallets

The interactive playground is the fastest way to see the full flow before you build anything. It runs against a live server - no setup, no install.

Why I Shipped Two Artifact Mechanisms In My VS Code Extension — Not One

Thomas Landgraf — Sat, 09 May 2026 10:51:18 +0000

A specification is more than text. It comes with a wireframe, the regulatory PDF it answers to, the API contract it has to honour, the stakeholder slide deck someone negotiated against. For a long time, none of that lived in my spec tree. The Markdown files were git-tracked; the evidence behind them rotted in Confluence, in shared drives, in pasted-and-lost screenshots in chat.

This week I shipped a fix in v0.9.7 of the VS Code extension I maintain. The shape of the fix is the part I want to write about, because the obvious version of it would have been wrong.

Full disclosure: I'm the creator of SPECLAN, a VS Code extension that manages product specifications as Markdown files with YAML frontmatter — Git-native, one file per requirement, organized in a hierarchical tree. The pattern (Markdown + YAML + Git) works without the tool; SPECLAN is just where I observed and engineered around the design problem below.

The obvious version: one artifact mechanism, governance everywhere

Specs travel in a lifecycle: draft → review → approved → in-development → under-test → released → deprecated. Once a spec is approved, the team has agreed on its content; the implementation gets built, tested, and shipped against that agreement. The natural next thought: artifact attachments should follow the same discipline. If you can't silently rewrite a released requirement's body, you also can't silently swap out the API contract attached to it. So: one universal artifact mechanism, Change Request governance everywhere.

I sketched that. I didn't ship it. Two days into testing, I realized the obvious version forced ceremony onto material that had no business going through a review cycle.

The thing the obvious version got wrong

Consider the artifacts a project actually accumulates over a year:

The login-flow-mockup.png attached to a specific feature. Owned by that feature. Means nothing without it.
The api-contract.json attached to a specific requirement. Verified against that requirement. Drift from it is a real bug.
architecture/system-overview.png. Referenced by half the specs. Owned by no spec.
brand-guidelines.pdf. Cited by every customer-facing surface. Owned by no spec.
regulatory/pet-handling-compliance.md. Read whenever a new compliance-touching feature is drafted. Owned by no spec.
meeting-notes/2026-04-22-kickoff.md. Reference material for context. Owned by no spec.

The first two are evidence pinned to a specific entity, with a specific lifecycle, where governance is the whole point. The other four are reference material — shared across many specs, owned by none, not bound to any specification's release cycle.

If I force-march the second class through a Change Request workflow, every architecture-diagram update needs a 4-stage review against… what spec? It doesn't belong to one. The reviewer would be approving a change with no parent entity to compare against. The ceremony has no anchor.

So I shipped two mechanisms with deliberately different governance:

Axis	Spec Artifacts	Project Artifacts
Hierarchy	Flat — top-level files only	Full nested filetree
Change Request governance	Mandatory on locked specs	None — direct file ops always
Filename sanitation	Enforced at every Add path	Whatever the filesystem accepts
Scope	Pinned to one spec entity	Project-wide reference, owned by no one
Visual surface	Section at the bottom of a spec page	Third entry in the project tree

The split falls out of one observation: locking applies to entities with status; project folders don't have status. A spec has a status. A project folder doesn't. There is no "released project" to gate changes against, so a unified governance mechanism would have no anchor for one of the two cases.

How Spec Artifacts work

Every feature, requirement, or change request gets its own artifacts/ folder right next to its .md file:

speclan/features/F-2419-login-flow/
├── F-2419-login-flow.md
├── artifacts/
│   ├── login-mockup.png
│   ├── api-response-schema.json
│   └── stakeholder-approval.pdf
└── change-requests/

In the WYSIWYG editor, an Artifacts section appears at the bottom of the spec page. Drag-drop or pick to add. Click to open in the registered default viewer. Image artifacts (PNG, JPEG, GIF, WebP, SVG) get an extra trick: they can be embedded inline in the spec body as illustrations, diagrams, or mockups — not as separate attachment rows. The on-disk artifact stays a plain ![alt](artifacts/file.png) markdown link, so the spec is portable to any markdown viewer.

The Change Request gate kicks in on locked specs. The dispatch table:

Parent spec status	Add / Remove behavior
`draft`	`review`
`in-development`	`under-test`
`deprecated`	Add/remove disabled

On a locked spec, dropping in an artifact doesn't overwrite the canonical file. The system creates a Change Request in draft status and stages your file under a CR-suffixed disk name. The CR flows through the standard draft → review → approved → in-development → under-test → released lifecycle. When you click Merge, the staged file becomes canonical.

The reason for this discipline isn't audit hygiene — it's artifact / implementation drift. A spec in released is one whose word the implementation team has built against. The API contract attached to it is the contract the build was verified against. If that contract silently shifts, the implementation no longer matches the evidence and nobody knows. The CR-staging mechanism prevents the silent shift; an approved CR doubles as a signal into the implementation flow — same trigger releases the new evidence and tells the implementation it needs to update.

How Project Artifacts work

A single project-wide directory at speclan/artifacts/. Folders nest to any depth. Drop files in via the picker, drag from your OS file manager, or organize subfolders directly through the filesystem — the on-disk filetree is the source of truth, the editor's tree view auto-refreshes via a filesystem watcher.

No CR governance. No filename sanitation. No status check. Direct file ops always.

This isn't laziness; it's the second half of the design choice. Reference material doesn't have a release cycle of its own. An architecture diagram updates when the architecture updates. A brand-guidelines PDF updates when marketing pushes a new revision. The project's own lifecycle drives those changes — there is no spec entity with a status that owns them, so there's nothing to gate against.

The two mechanisms compose: a spec body can link to a project artifact via plain relative markdown ([brand guidelines](../../../artifacts/brand-guidelines.pdf)). The linkage is plain markdown — SPECLAN doesn't track it as a referential relationship, doesn't auto-stage it under a CR, and doesn't validate the path. They share one thing: a consistent icon vocabulary. A .pdf artifact gets the same icon in the spec's Artifacts section as it does in the project tree. Different governance, same visual language.

What the extension does NOT do with artifact bytes

One boundary worth being explicit about, because the question gets asked: SPECLAN does not read, parse, summarise, or interpret the bytes of your artifacts. None of the AI features (clarification assistants, code-walking inference, change-request merging) consume artifact contents. The file is stored, referenced, surfaced in the UI, governed through CRs, and kept in sync on rename — that's the whole interaction the extension has with it.

What the extension does is make sure the implementation agent — Claude Code, Codex, Cursor, whatever you hand the spec to — can find the artifacts and decide for itself how to read them. Markdown, JSON, source code, and most images are read natively by modern coding agents. PDFs, DOCX, PPTX usually need a skill attached to the agent or a pre-extraction step into a sibling Markdown artifact before the implementation hand-off.

This is deliberate. Bundling PDF/DOCX parsers into the extension would (a) bloat it, (b) lock users into one extraction pipeline, and (c) silently expose binary content to AI providers users may not have authorised for that scope. Artifacts are evidence the implementation agent can find — not pre-digested input the AI has already consumed.

The one-click bridge to implementation

While the architecture work was the headline of this release, the quality-of-life win that ships with it is a button the extension has needed since v0.9.0: Quick Impl. A pill-shaped button in the editor topbar, visible on Features, Requirements, and Change Requests, that turns an approved spec into a paste-ready implementation prompt with a single click.

The prompt is structured to read the spec from its relative path, ask the user which implementation technique to use, set the spec's status to in-development for the duration of the work, and bookend the lifecycle by flipping to under-test when development is complete. It's a single-spec, fire-and-forget hand-off — the explicit alternative to the planfile-based workflow for "I have one approved feature and just want to ship it now."

What this changed about my own workflow

For a year I'd been treating the spec body as the only thing that lived in git. The wireframes lived in Figma; the contracts lived in OpenAPI files in another repo; the regulatory references lived in shared-drive PDFs that I emailed myself when I needed them. The day I started attaching them all to the spec tree under v0.9.7, I noticed how much friction the previous pattern carried that I'd just become numb to.

The deliberate split — governed Spec Artifacts, ungoverned Project Artifacts — is the kind of design choice that's obvious in hindsight but easy to get wrong upfront. A less careful version would have shipped one universal artifact mechanism with CR governance everywhere, and users (myself included) would have spent months filing bugs about why the architecture diagram needs a 4-stage review cycle to update. Two mechanisms with different governance is what falls out of taking the entity-lifecycle abstraction seriously.

If you're building tooling that touches a spec lifecycle, the practical lesson generalizes: governance is determined by what the parent entity needs, not by what's most uniform. A unified mechanism is satisfying from the architect's seat. From the user's seat, it forces ceremony on material that has none.

For the SPECLAN-specific tour, the release notes and the Artifacts help page walk through the user surfaces in detail. And if you're curious which of today's frontier models writes specs you'd actually trust to carry real artifacts, speclan.net/compare parks 13 models' output on the same brief side-by-side.

What's the cleanest split you've made between governed and ungoverned state in tooling you've shipped? Curious whether the "what does the parent entity need" lens lands the same way elsewhere.

18 installs, 0 signups. What Chrome extension onboarding actually looks like.

HelixLabs-dev — Sat, 09 May 2026 10:50:27 +0000

Two weeks ago I launched FocusForge which is my second Chrome extension. AI powered focus tool with time tracking, site blocking, grayscale mode, and a Nuclear Option that locks every distracting site for up to 8 hours with zero bypass.

18 installs from organic Chrome Store search. 0 signups. 0 revenue.
Here's what that taught me.

The free tier problem. AGAIN

Prompt Helix, my first extension, launched with unlimited free usage. Nobody upgraded because nobody needed to. Fixed that in v1.0.2 with a 25 query daily limit.

FocusForge launched with AI coaching and Nuclear Option locked behind a paywall. Core features — time tracking, site blocking, grayscale mode, daily reports — all free with no account needed.

Same mistake. Different product.

People install it, get real value from the free features, and have zero reason to create an account or upgrade. If the free tier is complete enough to solve the problem, the paid tier is invisible.

The return behaviour problem.

The conversion trigger only works if people come back to hit it. Someone who installs FocusForge, opens it twice, and forgets it exists will never see an upgrade prompt regardless of how well designed it is.

This is the problem I haven't solved yet. The first session has to be compelling enough that they think about it the next day without being reminded. For FocusForge that means the first time someone sets a time limit and gets blocked from a site has to feel genuinely useful — not annoying, not intrusive, actually helpful.

I don't know if that's happening yet. With 0 signups I have no data on what the first session actually looks like for real users.
What I'm building next to fix this.

A proper onboarding sequence. Right now someone installs FocusForge and sees the popup with no guidance on what to do first. The first session needs to walk them through setting their first time limit, show them their first daily report, and give them a reason to come back tomorrow.
The re-engagement email is the other piece but I don't have the email infrastructure set up yet. That's the next technical task.

The honest builder lesson.

Every metric problem in a Chrome extension eventually traces back to one of three things. Not enough installs, not enough return visits, or not enough upgrade triggers. I've been focused on installs through promotion. The return visit and upgrade trigger problems are what actually need solving now.

If you've built a Chrome extension and solved the day 1 to day 7 retention problem I'd genuinely love to know what worked.

Chrome Store: chromewebstore.google.com/detail/focusforge/hdkabchfflgnnonnhffkcmhgbenfoaci

helixlabs.studio

Building Your First n8n Workflow in 30 Minutes: A Hands-On Tutorial

TrackStack — Sat, 09 May 2026 10:48:32 +0000

— Build a real, working n8n workflow from scratch in ~30 minutes. We'll fetch the Bitcoin price every weekday at 9 AM, branch on whether it's above $100k, and notify either by email or Slack. Free tier only, no prior experience required. By the end you'll understand triggers, nodes, expressions, and conditional logic — the foundation everything else builds on.

I've onboarded a few colleagues to n8n over the past year. The pattern is the same every time: they start with the official "Schedule + NASA solar flares" tutorial, build something that works, then have no idea how to apply it to their actual job. The missing piece is a workflow that uses a real-world API and demonstrates why you'd use each node type — not just how.

Here's that workflow.

Five concepts you need before clicking anything

Internalize these. They'll save you hours of confusion later.

Workflow — a collection of connected nodes that automates a process. One workflow = one automation.
Node — a single step. Each does one thing: trigger, fetch, transform, send.
Trigger node — the first node. Decides when the workflow runs.
Execution — one full run of the workflow, top to bottom. n8n logs every execution for debugging.
Expression — JavaScript-flavored snippets in {{ }} that reference data from previous nodes.

When something breaks, ask yourself: which node failed, what data did it receive, what did it try to do with that data? Almost every problem maps to those three questions.

What we're building

Schedule (every weekday 9 AM)
        ↓
HTTP Request (fetch BTC price from CoinGecko)
        ↓
Edit Fields (extract price as a clean number)
        ↓
   If (price > 100,000?)
   ┌────┴────┐
   true     false
    ↓         ↓
  Email    Slack
(celebrate) (notify)

Six nodes, two branches, one schedule. Real API, real notifications, every concept a beginner needs.

Setup

Two paths to start:

n8n Cloud — sign up at n8n.io, 14-day free trial, no credit card. After trial, paid plans from €24/month for 2,500 executions.
Self-hosted — free forever, runs on your own server with Docker. Requires basic Linux comfort. Full production setup walkthrough in our n8n self-hosting guide.

For this tutorial, Cloud is faster — every step works identically on self-hosted. After signup, click Create Workflow in the upper-right. You'll see an empty canvas with one button: Add first step.

Step 1: Schedule trigger

Click Add first step.
Search Schedule and pick Schedule Trigger.
Trigger Interval: Days
Days Between Triggers: 1
Trigger at Hour: 9am
Optionally: under Trigger on Weekdays, select Mon–Fri only.

Critical detail: the Schedule trigger only fires when the workflow is published. While building, run the workflow manually with the Execute Workflow button at the bottom of the canvas.

Step 2: HTTP Request — fetch BTC price

The HTTP Request node is the most powerful node in n8n. It calls any public API, even ones without dedicated integrations.

Click + on the right of the Schedule trigger.
Search HTTP Request, select it.
URL: https://api.coingecko.com/api/v3/simple/price?ids=bitcoin&vs_currencies=usd
Authentication: None (CoinGecko allows unauthenticated calls).
Method: GET
Click Execute step.

You should see output like:

{
  "bitcoin": {
    "usd": 105432
  }
}

That's the live BTC price. Close the node panel — we'll use this data next.

Pro tip that saves debugging hours: Execute step runs only that single node, with sample data, without firing the entire workflow. Use it on every new node before connecting the next one. This catches 80% of mistakes early, when they're easy to fix.

Step 3: Edit Fields — clean up the data shape

The CoinGecko response nests the price inside bitcoin.usd. To make later steps cleaner, let's promote it to a top-level price field.

Click + on the HTTP Request node.
Search Edit Fields (also called "Set" in some versions).
Under Fields to Set, click Add Field.
Name: price
Value: toggle the = icon to red (this enables expression mode).
Drag bitcoin.usd from the left panel into the value field. The expression becomes {{ $json.bitcoin.usd }}.
Click Execute step.

Output should now be:

{
  "price": 105432
}

Expressions are how you reference data from previous nodes. Anything inside {{ }} is JavaScript. $json means "data the previous node returned." You don't need to memorize syntax — drag fields from the left panel and n8n writes the expression for you.

Step 4: If node — conditional branching

The If node creates two branches. We'll route based on whether BTC is above $100k.

Click + on the Edit Fields node.
Search If, select it.
Under Conditions:
- Value 1: drag price from the left panel → {{ $json.price }}
- Operation: Number > Larger
- Value 2: 100000
Click Execute step to verify.

The If node now exposes two output connectors: true (top) and false (bottom).

Common gotcha: make sure Operation is set to Number, not String. String comparison treats "5" > "100000" as true (alphabetic order), which silently breaks your logic. This bites everyone at least once.

Step 5: Action nodes (email + Slack)

Email on the "true" branch

Click + labeled true on the If node.
Search Send Email, select it.
Click Create new credential → configure SMTP. Gmail needs an app-specific password; most ESPs accept standard SMTP creds.
To Email: your address.
Subject: BTC just hit $100k!
Text (expression mode): BTC is currently at ${{ $json.price }} — celebration time!
Click Execute step to send a test email.

Slack on the "false" branch

Back on the canvas. Click + labeled false on the If node.
Search Slack, select it.
Click Create new credential → OAuth2 flow connects your workspace.
Resource: Message, Operation: Send.
Pick a channel (e.g., #general).
Text (expression mode): BTC is at ${{ $json.price }} — still under $100k.
Click Execute step.

If both test sends worked, the workflow is functionally complete. Save it now — Cmd/Ctrl + S or click Save at the top right. n8n doesn't auto-save while you build.

Step 6: Test, then publish

Two final steps separate "kinda works" from "actually runs reliably."

Run the full workflow once manually. Click Execute Workflow at the bottom. Every node turns green on success or red on failure. If anything fails, click the failed node — n8n shows the exact error and the input data that triggered it.

Publish. Toggle Publish at the top of the editor to active. Now the Schedule trigger fires every weekday at 9 AM automatically.

To verify it actually fires, open Executions in the left sidebar. After 9 AM tomorrow, you'll see a fresh execution logged. Click into any execution to see what data flowed through each node — invaluable for debugging.

Six gotchas that bite everyone

Forgetting to publish. Most common reason "the schedule isn't firing." If the toggle isn't on Published, the trigger is dormant.
String vs Number in If nodes. "5" > "10" returns true alphabetically. Always pick the right operation type.
Hardcoding what should be an expression. Typing the literal text $json.price into a regular field doesn't work. Toggle the = icon to red first.
Polling APIs every minute on n8n Cloud. A 1-minute schedule = 43,200 executions/month, which exceeds most paid plan limits. Use webhooks where possible.
Not testing each node individually. Click Execute step on every new node before connecting the next. Prevents 80% of debugging pain.
No backup of N8N_ENCRYPTION_KEY (self-hosted). Lose this and every saved credential is unrecoverable. Back it up to a password manager the moment you generate it.

What to build next

You now know the foundation. Three productive next steps:

Replace the Schedule trigger with a Webhook trigger to react to events from external systems instead of polling. Big efficiency gain. New to webhooks? Read this practical webhook primer including testing.
Add an error-handling node that fires when any step fails. Without it, silent failures will burn you eventually. The pattern: every critical workflow ends with a "Send Email/Slack on Error" branch.
Build something for your actual job. Pick one repetitive task you do every week (compiling stats, posting reports, syncing data) and rebuild it as an n8n workflow. The fastest way to learn is to solve a real problem.

If you're comparing n8n with other automation platforms before committing more time, here's our Zapier vs Make 2026 breakdown covering trade-offs across hosted alternatives.

The most useful first workflow for SMBs

The pattern that pays back fastest: form submission → CRM record → notification. New lead fills a form, data lands in CRM with proper tagging, your team gets notified instantly. Eliminates manual data entry, reduces lead response time from hours to seconds, and uses every concept from this tutorial.

Build this version once and you'll see why n8n's learning curve is worth it.

Originally published on TrackStack — practical write-ups on automation, tracking, and infrastructure for SMBs. If you got stuck on any step, drop a comment with what broke and I'll help debug.

I Gave My Newsletter a Voice (Literally)

Andrea Liliana Griffiths — Sat, 09 May 2026 10:48:10 +0000

I Gave My Newsletter a Voice (Literally)

My newsletter site has a chat widget now. You type a question, it searches through every issue I've ever written, and gives you an answer with sources.

That took an evening. Cool, but not interesting enough to write about.

What made me write this: I added a microphone button next to the text input. Click it, and you're in a real-time voice conversation with an AI agent that knows my content. You talk, it listens, it talks back. Not a recording. Not text-to-speech over a chat response. An actual voice conversation.

The stack behind it is LiveKit, and I want to walk through how it works because it's simpler than I expected.

What LiveKit Actually Does

LiveKit is real-time communication infrastructure. Think "Zoom but programmable." It handles all the WebRTC complexity — rooms, audio routing, codecs, latency optimization — so you don't have to.

The part that matters for AI voice agents: LiveKit has an agent framework. You write a Python worker that connects to their cloud service and waits. When a user joins a room, LiveKit dispatches your agent into that room. The agent listens to the user's microphone, processes speech, thinks, and talks back. All in real time.

The latency is wild. It feels like talking to someone, not waiting for a computer.

The Architecture

Three pieces:

The API — A FastAPI server that handles text chat (RAG search over my newsletter content) and generates LiveKit room tokens when someone clicks the mic button.

The voice agent — A Python worker running LiveKit's agent SDK. It connects outbound to LiveKit Cloud and waits for rooms. When someone joins, it gets dispatched. Inside the agent: voice activity detection (Silero VAD), speech-to-text (Azure Speech Services), an LLM (GPT-4.1-mini via GitHub Models), and text-to-speech (Azure Speech Services). Azure handles both ends of the voice pipeline — turning your speech into text the LLM can understand, then turning the LLM's response back into natural-sounding speech. Before every response, it searches my knowledge base for relevant context — same RAG pipeline the text chat uses.

The frontend — An Astro component with a mic button. Clicking it loads the LiveKit client SDK, requests a room token from my API, and connects to the room via WebRTC. The agent joins, and they're talking.

Both the API and the voice agent run in a single Railway container. A bash script starts both processes — if either dies, the container exits and Railway restarts it.

The RAG Part

Every time the user says something, the agent:

Transcribes the speech — Azure Speech Services converts your voice to text in real time
Embeds the transcript using GitHub Models API (text-embedding-3-small, 1536 dimensions)
Searches a SQLite vector database (sqlite-vec) for the most relevant newsletter chunks
Rebuilds the system prompt with fresh context
Generates a response (GPT-4.1-mini via GitHub Models)
Speaks it back — Azure Speech Services (en-US-JennyNeural voice) converts the text response to natural-sounding speech

This happens per utterance. The agent's knowledge stays current with whatever the user is asking about, not stuck on whatever the first question was.

The hybrid retrieval trick: Vector search alone can't answer "what's the latest issue?" because semantic similarity doesn't understand ordering. The solution: at startup, the agent queries the database for all newsletter issue URLs, extracts the numbers, and injects a content index into every system prompt:

Available newsletter issues: issue-1, issue-2, ..., issue-20
The latest/most recent issue is issue-20
Total issues: 20

Now the LLM gets both semantic context from vector search and structural metadata it can't learn from embeddings. Ask "what's the latest issue?" and it knows. Ask "tell me about GitHub Copilot" and vector search finds the right chunks. Hybrid retrieval.

Why Azure Speech Services?

The voice pipeline has two critical pieces where quality matters:

Speech-to-text accuracy. If the transcription is wrong, the whole conversation breaks. Azure Speech Services gives me high-accuracy transcription with low latency — critical for real-time voice. It handles accents, background noise, and technical terminology better than the alternatives I tested.

Natural-sounding TTS. Azure's neural voices sound human. Not robotic, not uncanny valley. The "en-US-JennyNeural" voice I use for the agent has natural pacing, intonation, and emotion. When the agent says "Let me search my knowledge base for that," it sounds like a person helping you, not a computer reading text.

Streaming support. Both Azure STT and TTS support streaming. The agent starts transcribing as you speak (no waiting for you to finish), and starts speaking as soon as the first chunk of TTS audio is ready (no waiting for the full LLM response). This cuts perceived latency in half.

LiveKit integrates with Azure Speech Services out of the box via their plugins (livekit-plugins-azure). Configuration is straightforward — set your Azure subscription key and region, pick a voice, done.

What Surprised Me

LiveKit agents are workers, not servers. They don't listen on a port. They connect outbound to LiveKit Cloud and get dispatched into rooms. This threw me at first — I kept trying to think of it as another HTTP service. It's not. It's a background worker that happens to handle real-time audio.

The voice pipeline has real latency requirements. Text chat can take 2-3 seconds and nobody cares. Voice? If there's a 2-second gap after someone finishes talking, it feels broken. LiveKit's streaming architecture handles this — the TTS starts speaking before the full LLM response is complete.

sqlite-vec is underrated. I'm running vector search in SQLite. No Pinecone, no Weaviate, no managed vector database. For a knowledge base of ~130 newsletter chunks (all 20 issues, articles, and GitHub blog posts), this is more than enough. The query takes single-digit milliseconds. Embeddings come from GitHub Models API during ingestion — free during preview, high quality (text-embedding-3-small, 1536 dims), and no local model loading headaches.

Debugging production is different. The voice agent worked locally but failed silently in Railway. The agent would listen, transcribe perfectly, but always respond with "I don't have that information." Turned out the embeddings API was returning 400 errors because an old environment variable (LIVEBRAIN_EMBEDDING_MODEL) was still set to a local model name (all-MiniLM-L6-v2) that the API didn't recognize. The fix: delete the variable and let it default to text-embedding-3-small. Real-time logging made this visible — without print() statements showing chunk retrieval counts and similarities, I would have been guessing for hours.

What's Next

I'm extracting the reusable parts of this into an open-source framework. The idea: point it at a YAML file with your content sources, run an ingestion script, and you get a voice agent that knows your stuff. Newsletter, documentation, blog — whatever you feed it.

It's not ready yet. The mainbranch-agent version works, but the generic framework needs cleanup before anyone else can use it. I'll open-source it when it's actually good, not when it's "minimum viable."

If you want to see it in action, go to mainbranch.dev and click the chat bubble. The mic button is right there.

U.S. Cyber Trust Mark: what IoT firmware teams should prepare

Marco — Sat, 09 May 2026 10:47:26 +0000

IoT security labels are turning cybersecurity from an internal engineering topic into a visible product requirement.

This is an English DEV.to draft based on a Silicon LogiX technical article. The canonical source is linked at the end.

Why it matters

The U.S. Cyber Trust Mark is voluntary, but it can influence buyers, retailers and procurement teams.

For firmware teams, the important part is not the label itself. It is the discipline required to earn and maintain trust.

Architecture notes

Products need updateable firmware, protected credentials, secure configuration and documented support periods.
A public registry or QR-linked label makes lifecycle information easier to compare.
The requirements overlap with broader global trends such as the EU Cyber Resilience Act.
Security evidence becomes part of the product package, not only an internal checklist.

Practical checklist

[ ] Document supported lifetime, update policy and vulnerability disclosure process.
[ ] Implement signed firmware updates and rollback protection.
[ ] Remove default passwords and protect commissioning flows.
[ ] Track software components and known vulnerabilities.
[ ] Prepare test evidence that non-security stakeholders can understand.

Common mistakes

Treating the label as a marketing task after development is finished.
Shipping products that cannot be patched in the field.
Documenting security claims that the firmware architecture cannot support.

Final takeaway

Security labels raise the bar because they make product lifecycle promises visible. Firmware architecture has to be ready before certification conversations begin.

Canonical source: U.S. Cyber Trust Mark: what IoT firmware teams should prepare

If you build embedded, IoT or firmware products and want a second pair of eyes on architecture, update strategy or security, Silicon LogiX can help turn prototypes into maintainable systems.

QUIC in embedded systems: when it makes sense over TCP and UDP

Marco — Sat, 09 May 2026 10:47:25 +0000

QUIC is often described as a replacement for TCP or UDP. For embedded products, the useful question is narrower: when does it improve the system?

This is an English DEV.to draft based on a Silicon LogiX technical article. The canonical source is linked at the end.

Why it matters

QUIC runs over UDP but provides secure, reliable streams with faster connection setup and better multiplexing behavior.

It can be valuable for devices that interact with modern HTTP/3 services, cloud APIs or dashboards with many parallel requests.

Architecture notes

QUIC integrates TLS 1.3 into the transport model instead of layering TLS over TCP.
Stream multiplexing avoids some head-of-line blocking problems seen with TCP-based HTTP/2.
Connection migration can help mobile or changing-network scenarios, though not every embedded device needs it.
The cost is stack complexity, memory usage, diagnostics and firewall/NAT behavior.

Practical checklist

[ ] Use QUIC when connection setup latency or multiplexing changes user-visible behavior.
[ ] Stay with TCP when simplicity, tooling and compatibility are more important.
[ ] Use raw UDP only when the application can own reliability and security correctly.
[ ] Measure RAM, CPU and handshake behavior on target hardware.
[ ] Plan how field technicians will diagnose QUIC failures.

Common mistakes

Choosing QUIC because it is newer, not because it solves a product problem.
Ignoring network environments that block or degrade UDP.
Underestimating observability and debugging cost.

Final takeaway

QUIC is a useful tool for specific embedded networking problems, not a universal upgrade over TCP and UDP.

Canonical source: QUIC in embedded systems: when it makes sense over TCP and UDP

If you build embedded, IoT or firmware products and want a second pair of eyes on architecture, update strategy or security, Silicon LogiX can help turn prototypes into maintainable systems.

Gamers Forem

How to Prepare a Legacy Codebase for AI-Assisted Refactoring

Step 1: Establish Scope and Document It

Step 2: Audit Dependencies Before Touching Anything

Step 3: Create a Test Baseline

Step 4: Identify and Document the Critical Paths

Step 5: Set Up a Safe Experimentation Environment

Putting It Together

Stop Paying for Invoice Software. This Free Tool Runs Right in Your Browser.

Your Data Stays on Your Device

Set It Up Once, Use It Forever

Customers and Products - Managed, Not Re-Typed

Create an Invoice in Under a

The PDF Looks Professional

Track the Status of Every Invoice

Who Is This For?

Completely Free. Forever.

The AI Hype Crisis

The Great Correction Arrives

Trust in Freefall

When Algorithms Replace Judgement

The Stochastic Parrot Problem

The AI Washing Economy

Echoes of Previous Bubbles

Algorithmic Bias and the Feedback Loop of Injustice

What Sustained Disillusionment Means for Innovation

Rebuilding on Honest Foundations

References and Sources

Orbis: Turn Any GitHub Repository Into an Interactive 3D Dependency Graph

Features

Tech Stack

Quick Start

Docker

Usage

Keyboard Shortcuts

Architecture

API Endpoints

Output Schema

Supported Languages

AI Chat

Development

How I Built This Using NEO

How You Can Use and Extend This With NEO

Final Notes

🚀 Building AgentForge: AMD AI Agent Platform on Bolt.new

🔧 What Was Built

✨ Features

🚢 Enhancements

🌍 Why It Matters

🔗 Live Demo

Closing

A Self-Monetizing API in 20 Lines of Code

The Problem With How We Monetize APIs Today

HTTP 402: The Status Code That Was Waiting for Blockchains

What We're Building

Setup

The Server

The Client

What Just Happened Under the Hood

Writing Tests for Your Paid Endpoints

Handling Errors Gracefully

Taking It to Production (Mainnet)

The Creator Economy Angle

Why This Matters for AI Agents Right Now

Quick Reference

Install

Minimal server

Minimal client

Networks

Error types

What's Next

Links

Why I Shipped Two Artifact Mechanisms In My VS Code Extension — Not One

The obvious version: one artifact mechanism, governance everywhere

The thing the obvious version got wrong

How Spec Artifacts work

How Project Artifacts work

What the extension does NOT do with artifact bytes

The one-click bridge to implementation

What this changed about my own workflow